starting kvm guests with libvirt on virthost startup doesn't wait till all dependencies are available
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt (Ubuntu) |
Won't Fix
|
Low
|
Unassigned |
Bug Description
Hallo!
One of our kvm guests has its system on a SAN (AoE) device.
This aoe device is available about 2 minutes after startup.
The libvirt startup script tries to start the guest earlier.
The guest dies with:
qemu: could not open disk image /dev/etherd/e9.2: No such file or directory
Is it possible to test for this dependency or insert a wait command?
Thanks
Lars
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: libvirt-bin 0.7.5-5ubuntu27
ProcVersionSign
Uname: Linux 2.6.32-22-server x86_64
Architecture: amd64
Date: Thu Jun 17 08:59:01 2010
ExecutablePath: /usr/sbin/libvirtd
InstallationMedia: Ubuntu-Server 10.04 LTS "Lucid Lynx" - Release amd64 (20100427)
ProcAttrCurrent: /usr/sbin/libvirtd (enforce)
ProcEnviron: PATH=(custom, no user)
SourcePackage: libvirt
Changed in libvirt (Ubuntu): | |
status: | New → Incomplete |
Changed in libvirt (Ubuntu): | |
importance: | Undecided → Low |
Hi,
thanks for the report. I assume you have libvirt set up to start these VMs
automatically, and what you are asking is for the startup scripts to wait for
two minutes after boot before starting the VMs?
There are three ways I would consider going about this.
One is to simply mark the VMs to not start up automatically. You could start
them manually, or create another job in /etc/init/ which waits 2 minutes and
then starts the VMS.
Another is to edit /etc/init/ libvirt- bin.conf to make libvirt wait to start up
altogether. If the aoe mounts have their own upstart job which works
correctly, then you can make it depend on that, or you can simply add a
'prestart exec sleep 3m' to amke it wait 3 minutes until after boot. You
might want to talk to upstart folks for the best way to do this.
Another is to patch libvirt to add the capability to wait to auto-start VMs.
You can discuss this with upstream at <email address hidden>.
The best solution is the second one, particularly if there is an aoe upstart
job which emits a completion event when the mounts are available.