[libvirt-users] Wanted: method for qemu hook script to know if called for migration
Hi, "Before a QEMU guest is started, the qemu hook script is called" (http://libvirt.org/hooks.html)... In writing a simple bash script to prevent a VM on shared storage from being started on one host if it's already running on another, it's easy enough to check if virsh on the other host reports the particular VM as "shut off" there, and go ahead if that's the case. What's I'm having trouble coming up with is a simple method to allow a migration from the second system over to the first with that script in place. As the doc says, /etc/libvirt/hooks/qemu is "Executed when a QEMU guest is started, stopped, or migrated," so when it's simply being started, it makes sense to be sure it's not already running on the second system, and prevent the start if it's not. Works fine for me. But when a migration is requested, the script is called in the same way as when it's being started. What I need is a way, from within the script, to tell whether it's a migration context, so that then the start will be allowed, despite the VM's already being running on the second system. Any ideas how to do that? Unfortunately what's passed to the script directly is just "[vmname] start begin -" in both cases. And I don't see that a separate migrate process shows up in the process tables until after getting beyond the qemu hook script. As a feature suggestion, it would be nice if that fourth input variable, currently "-", was something like "migrate" in this instance. Thanks, Whit
On 07/25/2011 02:06 PM, Whit Blauvelt wrote:
In writing a simple bash script to prevent a VM on shared storage from being started on one host if it's already running on another,
Not to distract from your bug report, but have you considered using the new sanlock (0.9.3) or fcntl (0.9.4) lock managers, that do this automatically, without the need for using hook scripts. http://libvirt.org/locking.html
Any ideas how to do that? Unfortunately what's passed to the script directly is just "[vmname] start begin -" in both cases. And I don't see that a separate migrate process shows up in the process tables until after getting beyond the qemu hook script.
As a feature suggestion, it would be nice if that fourth input variable, currently "-", was something like "migrate" in this instance.
Yes, that is probably a bug worth fixing. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Mon, Jul 25, 2011 at 02:17:08PM -0600, Eric Blake wrote:
Not to distract from your bug report, but have you considered using the new sanlock (0.9.3) or fcntl (0.9.4) lock managers, that do this automatically, without the need for using hook scripts.
Thanks Eric. Interesting alternative. What I'm trying not to allow is starting a second instance of a VM from a raw image which is present on two hosts at the same time (using sometimes DRBD, sometimes GlusterFS). So it's not a case of two running VMs being in contention for some disk storage external to them, but of two hosts being in contention to run the same VM. The VM exists on storage mirrored between the two hosts. In trying to understand whether sanlock will work in this instance, I see at http://permalink.gmane.org/gmane.comp.emulators.libvirt/40261: sanlock will ... protect against 2 vms on the same host using the same disk (or the same VM being started twice due to error by libvirt). By implication if I have the sanlock directory on a shared filesystem, it will also prevent a VM from being started on the second host while running on the first. Will it still allow the VM to do a live migration? Or will live migration run up against the lock? Whit
On 07/25/2011 03:25 PM, Whit Blauvelt wrote:
In trying to understand whether sanlock will work in this instance, I see at http://permalink.gmane.org/gmane.comp.emulators.libvirt/40261:
sanlock will ... protect against 2 vms on the same host using the same disk (or the same VM being started twice due to error by libvirt).
By implication if I have the sanlock directory on a shared filesystem, it will also prevent a VM from being started on the second host while running on the first. Will it still allow the VM to do a live migration? Or will live migration run up against the lock?
Yes, both useful lock managers (sanlock and fcntl) work best with the use of a shared lock directory, at which point they correctly handle live migration between hosts. That is, the lock manager knows how to differentiate between read-only and read-write disk access, and the migration pattern is such that while the VM temporarily lives on two hosts at once, the migration API coordinates those two instances so that only one ever needs read-write access of a shared disk at a time. The lock manager hooks are correctly called in the right sequence to account for migration, while still preventing you from starting up the same VM twice on multiple hosts via any means other than migration. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Mon, Jul 25, 2011 at 03:32:32PM -0600, Eric Blake wrote:
Yes, both useful lock managers (sanlock and fcntl) work best with the use of a shared lock directory, at which point they correctly handle live migration between hosts.
Where would I learn how to use fcntl for this? I see code for it in the current git, but no hint on usage. Perhaps I should just be patient? Thanks, Whit
On Tue, Jul 26, 2011 at 04:15:45PM -0400, Whit Blauvelt wrote:
On Mon, Jul 25, 2011 at 03:32:32PM -0600, Eric Blake wrote:
Yes, both useful lock managers (sanlock and fcntl) work best with the use of a shared lock directory, at which point they correctly handle live migration between hosts.
Where would I learn how to use fcntl for this? I see code for it in the current git, but no hint on usage. Perhaps I should just be patient?
The fcntl lock manager isn't ready yet. I was trying to get it into the 0.9.4 release, but have missed the deadline, so it will be 0.9.5 instead. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Whit Blauvelt