Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)

[Avi Kivity]

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.