Thanks for the response. Please find my comments inline.
regards
Kiran
On Thu, Jul 26, 2012 at 9:39 PM, Laine Stump <laine@xxxxxxxxx> wrote:
On 07/26/2012 09:40 PM, kiran Chunduri wrote:I'm assuming that the "OVS" part of this is openvswitch?
> Hi,
> I was experimenting 'live migration' with libvirt (using virsh) and
> observed that post migration the Interface stats in 'OVSDB:Interface'
> table are not transferred.
Thats correct. Sorry, next time I will try to be more specific.
> qemu+ssh://10.23.167.219/system <http://10.23.167.219/system>'
> Only the values in 'external_ids' column seem to be synced up. The
> libvirt version I'm using is 0.9.11.3. The virsh command used for
> migration is: 'virsh migrate --live fc17-vm
>I don't know if it's "right", but moving state that's outside of the
> Is this the right behavior (or) Have I missed out on some option?
guest itself is outside the scope of migration, at least for now.
Well, you are right in that the run time state of the virtual port is outside of the guest. But in case of Live-Migration, I think it will be good to have a mechanism, within libvirt, to carry the Virtual Port stats and any opaque run-time state along with the VM. Other than libvirt, I can't see who else can address this requirement.
I don't really have a good idea about that. Could the information
>
> Can some one please guide on the approach and the source files to look
> at If i need to add this support?
>
related to a given guest interface be easily represented in XML within
the <interface> section of the guest's domain XML (which is the only
thing aside from an image of the guest's memory, and state of the
guest's emulated devices, that is transferred during a migration)? If
that's the case, maybe the openvswitch support in libvirt could be
extended to, for example, recognize some extra stuff inside of the
<virtualport type='openvswitch'> element when resuming a paused (due to
migration or save) guest, and use that data to populate the db.
Here, I'm not sure if XML file is the right location to store the run time state (for eg:stats) of virtual port. Even if it is possible to store in XML data form, it would mean the guest domains XML file need to modified before Migration (or) frequently whenever there is a change to this data. Ideally I would prefer, if 'libvirt' expose a opaque data framework, that OpenVswitch (or any other Virtual Switch) driver can fill in before migration and replay at the destination host.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list