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 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
