qemu-devel
[Top][All Lists]
Advanced

[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: Jamie Lokier
Subject: Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Date: Tue, 14 Apr 2009 19:19:08 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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




reply via email to

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