On 11/10/2011 02:06 PM, Daniel P. Berrange wrote:
On Thu, Nov 10, 2011 at 01:11:42PM -0600, Anthony Liguori wrote:
On 11/10/2011 12:42 PM, Daniel P. Berrange wrote:
On Thu, Nov 10, 2011 at 12:27:30PM -0600, Anthony Liguori wrote:
What does libvirt actually do in the monitor prior to migration
completing on the destination? The least invasive way of doing
delayed open of block devices is probably to make -incoming create a
monitor and run a main loop before the block devices (and full
device model) is initialized. Since this isolates the changes
strictly to migration, I'd feel okay doing this for 1.0 (although it
might need to be in the stable branch).
The way migration works with libvirt wrt QEMU interactions is now
as follows
1. Destination.
Run qemu -incoming ...args...
Query chardevs via monitor
Query vCPU threads via monitor
Set disk / vnc passwords
Since RHEL carries Juan's patch, and Juan's patch doesn't handle
disk passwords gracefully, how does libvirt cope with that?
No idea, that's the first I've heard of any patch that causes
problems with passwords in QEMU.
My guess is that migration with a password protected qcow2 file isn't a common
test-case.
Regards,
Anthony Liguori
Daniel
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list