Avi Kivity wrote:
Daniel P. Berrange wrote:
Yes indeed its a little crazy :-) As anthony mentioned if libvirt were able to be notified of changes a user makes in the monitor, there's no reason we could not allow end users to access the monitor of a VM libvirt is managing. We just need to make sure libvirt doesn't miss changes like attaching or detaching block devices, etc, because that'll cause crash/data loss later when libvirt migrates or does save/restore, etc because it'll launch QEMU with wrong args
You still have an inherent race here.
user: plug in disk libvirt: start migration, still without disk qemu: libvirt, a disk has been plugged in.
Then fix it. The race is not necessary. user: plug in a disk libvirt: lock VM against user changes incompatible with migration qemu: libvirt, lock granted libvirt: query for current disk state libvirt: start migration, knows about the disk The "libvirt, a disk has been plugged in" will be delivered but it's not important. libvirt queries the state of things after it acquires the lock and before it starts migration.
That means that to debug a problem in the field you have to locate a guest's host, and follow it around as it migrates (or disable migration).
That's right you do. Is there any way to debug a guest without disabling migration? I don't think there is at present, so of course you have to disable migration when you debug. Another reason for that "lock against migration" mentioned above. -- Jamie