On 08/04/2011 12:41 PM, Jim Fehlig wrote:
Yeah, I debated about whether to even add this hunk, but was considering
'virsh dump --live ...' where the process still exists and could
potentially be migrated to another host later.
Oh, I forgot about that. I guess we do have a case where migration to
file does not imply the death of the qemu process.
Meanwhile, it raises independent issues - why do we have a write-only
interface in virDomainMigrateSetMaxSpeed? Shouldn't we also be able
to query the speed currently in use, and shouldn't the domain XML
track the current migration speed?
AFAICT, qemu doesn't provide a way to query the speed. The monitor
would need this addition before we could plumb it in libvirt.
Not necessarily true. If we track it in the domain xml, then libvirt
can update that xml any time it makes a change, and set qemu to match
the xml any time that it is changed or qemu started, and answer queries
from the xml rather than by querying the monitor.
How would you like to proceed?
Are you in the mood to add virDomainMigrateGetMaxSpeed and the XML
change necessary to track it? If so, then I'd favor tackling that
first, at which point we'll have answered our questions about what speed
to restore here.
I would even be okay with pushing this patch first (with the tweak of
adding a #define for the 32<<20 magic number), if you can get more
feedback from others agreeing on the points raised here; cleaning things
up to restore the saved value rather than the default value would be an
appropriate part of the series adding the ability to track the saved value.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list