Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
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