severity 631726 wishlist merge 571063 631726 tags 631726 + confirmed upstream thanks
26.06.2011 18:56, Benoit Panizzon wrote: > Package: qemu-kvm > Version: 0.12.5+dfsg-5+squeeze2 > Severity: important > > Probably a common setup: > > Two host servers (A and B) serving multipe guest. > Images stored on common NFS server to both host servers, so migration is > possible. > > Guests are set-up for auto-start with libvirt. > > One host server has to be booted for maintenance. All guests are being > manualy migrated to host B. And we've a catch-22 scenario. In order for migrate to work, both hosts should be able to open the disk images at the same time - you start kvm on the target host the same way as you do it on the source host, specifying the same files. If source host had them locked, dest. kvm will not be able to open them. There's more than migration - there, it should be possible to release the lock on source, start incoming migration on target (with locked drives) and handle errors, but that quickly becomes too ugly. We also have stacked disk images, and there, we've similar complexities - the base image should be locked too when at least one "slave" image _exists_ (not only open), and there are cases when one need to open it while it's in use. There are other valid use cases with even more dangerous possibilities - for example, quite often I boot my kvm guest from my main drive - on my physical /dev/sda drive I've two operating systems installed (win7 and linux), and sometimes I want to boot win7 while staying in linux - kvm allows me (after some tweaking of guest side) to boot natively installed win7 just fine. Sure thing I wont be able to boot it this way if qemu will require locking (or, in this case, exclusive open which is quite something else). This has been discussed in qemu mailing list - see several threads from 2009, say, "Disk image shared and exclusive locks", "Locking block devices for concurrent access" and a few others. So far there has been nothing conclusive. I agree there's a high risk of damaging guest images when starting multiple qemu/kvm instances off the same image, and that qemu should try to be more careful by default (with an option to stop doing these checks/locks), but the problem is far more deep than you think it is. For your case there's a trivial workaround: rename the guest images (place them in a different directory, or rename the base directory, whatever) before migrating. This way, you start your incoming migration with new filenames already, and your source host wont be able to open them till you actually tell it to do so. Another possible workaround is to have a flag - eg. a file in the guest directory - which contains the name of host which is currently running (or should run) the guest - and check if that file has current hostname before starting it. Or something else of this theme, -- it can become quite creative. So, since the problem has a (relatively) easy workaround (outside of qemu/kvm) and since the underlying problem is quite deep and involves upstream who hasn't decided yet what to do with it, I'm marking this bug appropriately - with severity "wishlist" and appropriate tags. There's another similar bugreport filed against qemu-kvm which shows another possible use case - mergeing this bug with that one while at it, too. Thanks! /mjt -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
