[libvirt] Support to transfer OVSDB:Interface stats during Live Migration

[kiran Chunduri]

Hi Laine,
Thanks for the response. Please find my comments inline.
regards
Kiran

On Thu, Jul 26, 2012 at 9:39 PM, Laine Stump <laine at laine.org> wrote:

> On 07/26/2012 09:40 PM, kiran Chunduri wrote:
> > 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.
>
> I'm assuming that the "OVS" part of this is openvswitch?
>
Thats correct. Sorry, next time I will try to be more specific.

>
> > 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
> > qemu+ssh://10.23.167.219/system <http://10.23.167.219/system>'
> >
> > Is this the right behavior (or) Have I missed out on some option?
>
> I don't know if it's "right", but moving state that's outside of the
> 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.

>
> >
> > Can some one please guide on the approach and the source files to look
> > at If i need to add this support?
> >
>
> I don't really have a good idea about that. Could the information
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120727/83de91bb/attachment-0001.htm>