[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
avi at redhat.com
Thu Apr 16 09:03:13 UTC 2009
Jamie Lokier wrote:
> 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.
Migration is supposed to be transparent. You're reducing quality of
service if you're disabling features while migrating.
>> 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.
Nothing prevents you from debugging a guest during migration. You'll
have to reconnect to the monitor, but that's it.
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
More information about the libvir-list