Red Hat Bugzilla – Bug 618970
RFE: QEMU hooks: Add new guest startup hook prior to disk labelling
Last modified: 2011-03-24 02:53:01 EDT
Created attachment 434953 [details]
Simple patch to add a prepare hook to libvirt
Description of problem:
Since version 0.8 libvirt allows to execute hooks on startup and shutdown of a machine. This mechanism would be great if it could used to setup certain resources needed by the maschine to be run (eg. DRBD, see below). However, the "start" hook is called by libvirt pretty late, after several checks where already perfomed. For example it is not possible to setup the blockdevice needed by machine in the start-hook, since the machine refuses to start long before that hook will be called.
Because of that I suggest to ad a prepare hook which will be called before a machine is started and the checks are performed.
Consider the following szenario: the diskimage for a machine is a DRBD blockdevice. Normally the machine will be run on a primary host, but it should also be possible to migrate the machine to secondary host. Of course you could configure DRBD for primary/primary configuration, but that will be dangerous, as a machine could be started on both hosts, causing filesystem corruption.
The prefered method would be to setup the DRBD to secondary/secondary configuration. Whenever a machine is started it calls the preparehook first. That hook can then bring up the DRBD into primary configuration, so that the machine can actually run. Furthermore that hook can also check if the DRBD is already in primary state on the other side and exit with an error so that libvirt will refuse to start the machine again.
Version-Release number of selected component (if applicable):
Setup a machine on a DRBD blockdevice and bring that DRBD resource into secondary state. Starting the machine using libvirt is not possible, since the blockdevice is not accessible. Adding a start-hook script to bring the resource up does not work, since the check for the blockdevice is done prior to calling that hook.
I added a patch that will add a prepare hook to libvirt, to give you a better understanding of what would be helpful here.
That patch is already in use here and improves the experience of running a failover machine on a DRBD device considerably. The only thing we do here is to call the hookhandler early in the startup process, passing the operation "prepare" to the hookscript. Also the migrateFrom string is passed as extra parameter.
The hookscript itself then will do the following things:
a) when passed "prepare" as operation and the extra parameter is empty, it considers a normal startup of the machine. It checks the DRBD resource. If the DRBD is already primary on the other side it will exits with an error, otherwise it will try to bring the DRBD into primary state on its own side and exits normally.
b) when passed "prepare" as operation and the extra parameter is not empty (eg a migration is taking place), it will try to bring the DRBD into primary state regardless of the current state.
c) when passed "stopped" it will try to bring the DRBD into secondary state.
The patch will allow to run and migrate virtual machines with libvirt when DRBD is used. It is not longer necessary to have the DRBD resource always in primary/primary state (which can be considerbly dangerous) or using other hacks to configure the correct state prior to using libvirt/virsh.
Created attachment 486215 [details]
Updated patch for 0.8.8
Adds an early qemu hook before the VM ressources allocation, and a hook at the end of VM destruction.
Do you plan to include the proposed patch in a future release ?
We highly depend to this feature. It is used to bring up vlan virtual interfaces and bridges on-demand, when the domain is configured to attach to a bridge that does not exist yet. Regular hooks would not be usable in this case as libvirt would fail early when it finds out the required "br" is inexistant.
Hum, could you post the patch to the mailing-list ? We are entering
freeze for 0.9.0 in 3 days, but since the patch is relatively simple
it is likely we can apply it in time.
See http://libvirt.org/contact.html , the best would be to subscribe
to the email@example.com list before posting. If subscribing is
a problem then I can carry the patch but it's better if we have one of
the reporter listed as the originator for the patch,
Thanks Daniel, I sent it to the mailling-list, and also add the git patch here because my previous attachement was specific to Debian sources.
Created attachment 486580 [details]
Vanilla compatible patch sent to the ML
Previous patch was not applicable to the vanilla sources.
Done, applied upstream, documentation still need to be augmented though,