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

[Kyle Mestery (kmestery)]

On Oct 1, 2012, at 2:34 AM, Daniel P. Berrange wrote:
> 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


For the most part, this data will be well below 4K per port. However, if a feature such as
port security is utilized, it could be a list of allowed MAC addresses for the port, which could
explode the length of the data, but still be below 4K per port.

I've added all of Laine's comments into the patch set, I'm testing now. Once that is done, I will
reformulate the patch one more time to make "portdata" a subelement of <interface> rather than
an attribute. When I complete that, I will resubmit the patches again.

Thanks,
Kyle