[libvirt] [PATCH 0/3] Transport network port data during live migration

Daniel P. Berrange berrange at redhat.com
Mon Oct 1 07:34:08 UTC 2012


On Mon, Oct 01, 2012 at 03:48:32AM +0000, Kyle Mestery (kmestery) wrote:
> On Sep 30, 2012, at 9:44 AM, Laine Stump wrote:
> > On 09/28/2012 03:58 PM, Kyle Mestery (kmestery) wrote:
> >> As an example, an OpenFlow controller may have certain information about the
> >> port, specific to this controller, which it may want to store with the port itself on the
> >> host. This especially true if an agent exists on the host which needs to read this data,
> >> update it, and use it to perform some tasks. It's convenient to have this data stored
> >> as close to the port itself, which in this case is the OVS DB, and having it transferred
> >> as part of the migration protocol is also very handy.
> >> 
> > 
> > But how big is it, and what does it look like? (I assume it's all
> > printable ASCII, since you're getting it as the output of a shell command)
> > 
> > If it's *really* large, possibly it would go better as a subelement of
> > <interface>, rather than an attribute, i.e.:
> > 
> >   <interface index='1' vporttype='openvswitch'>
> >     <portdata>
> >     blah blah blah blah
> >     </portdata>
> >   </interface>
> 
> 
> Yes. it's all printable ASCII. I think at the largest, it's possible for it to be up to a few K (e.g. 2-4K
> or so). So perhaps making it a subelement would be the way to go.
> 
> As for an example, let me talk to some controller people and see if I can scrounge one up.

The other reason why I want to see indicitive size is to make sure we
don't risk hitting any limits on the size of the migration cookie.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list