[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor device

From: Avi Kivity
Subject: Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Date: Thu, 16 Apr 2009 12:03:13 +0300
User-agent: Thunderbird (X11/20090320)

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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]