[Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 25/11/12 08:11, Dan Kenigsberg wrote:
> On Fri, Nov 23, 2012 at 09:02:09AM +0200, Livnat Peer wrote:
>> On 22/11/12 13:59, Dan Kenigsberg wrote:
>>> On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
>>>> On 22/11/12 00:02, Itamar Heim wrote:
>>>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>>>> To: engine-devel at ovirt.org
>>>>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>>>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> This is a proposal for reporting the vNic implementation details as
>>>>>>> reported by the guest agent per each vNic.
>>>>>>>
>>>>>>> Please review the wiki and add your comments.
>>>>>>
>>>>>>
>>>>>> While we're making the change is there anything else we'd want to
>>>>>> report - MTU, MAC (since a user might try to override), etc ?
>>>>>>>
>>>>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>>>
>>>>> iirc, the fact ip addresses appear under guest info in the api and not
>>>>> under the vnic was a modeling decision.
>>>>> for example, what if guest is using a bridge, or a bond (yes, sounds
>>>>> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
>>>>> michael - do you remember the details of that discussion?
>>>>
>>>> I'd love to know what drove this modeling decision.
>>>> The use case above is not a typical use case.
>>>> We know we won't be able to present the guest internal network
>>>> configuration accurately in some scenarios but if we cover 90% of the
>>>> use cases correctly I think we should not let perfect be the enemy of
>>>> (very) good ;)
>>>
>>> We do not support this yet, but once we have nested virtualization, it
>>> won't be that odd to have a bridge or bond in the guest. I know that we
>>> already have users with in-guest vlan devices.
>>>
>>
>> The fact that it's not odd does not mean it is common.., which was the
>> point I was trying to make.
>> I agree that we should be able to accommodate such info, not sure that
>> it is required at this point.
>>
>>
>>> I think that the api should accomodate these configurations - even if we
>>> do not report them right away. The guest agent already reports (some) of
>>> the information:
>>>
>>
>> Which API are you referring to? if you are talking about VDSM-Engine API
>> we do not change it, only use what is already reported by the GA. I
>> don't think we should change the API for future support...
> 
> I was refering to the Engine API. Now that we are designing how guest IP
> addresses are to be reported, we should think how to accomodate IP
> addresses on non-nic devices.
> 

Currently the engine do not expose guest-network-devices other than
vNICs which were defined in the engine from the first place.

I suggested adding a blob (at VM level) to present the
network-devices-data reported by the guest agent.
So far I did not see on the users list any request for such info, so
maybe we can hold this addition back a little to see what requests our
users have for this.


> I believe that the Engine API should replicate the guest agent API: give
> a list of guest network devices, each one with its ethernet/ipv4/6
> addresses.
> 
> I am less sure how we should correlate this information with the VNICs
> defined on the VM. If we do not want to "taint" the VNIC with this dubious information, we can leave this correlation (based on MAC address) to UI or user script.
> 
> Dan.
>