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

Kyle Mestery (kmestery) kmestery at cisco.com
Mon Oct 1 15:15:39 UTC 2012


On Oct 1, 2012, at 9:40 AM, Kyle Mestery (kmestery) wrote:
> 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.
> 
Actually, I'm going to leave this as an attribute for now, since the patches work just fine as is, unless
someone has a comment about specifically refactoring. I'm resending the patches now.

> Thanks,
> Kyle







More information about the libvir-list mailing list