[Engine-devel] Report vNic Implementation Details

[Itamar Heim]

On 11/25/2012 02:56 PM, Livnat Peer wrote:
> On 22/11/12 23:18, Itamar Heim wrote:
>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>> Back to the original question:
>>>
>>> What is most inconvenient for many users is:
>>> 1. The name we provide while creating the VNIC differs from the one in
>>> the guest
>>> 2. No correlation between IP and NIC
>>>
>>> The current page covers for this but indeed as raised here does not
>>> cover what happens if this information is not easy to retrieve due to
>>> non strait forward configurations.
>>>
>>> What I suggest is,
>>>
>>> For the short term:
>>> - Agent to report the MACs, IPs and interface names if can be found,
>>> engine to match these to the existing and show
>>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
>>> page, but...
>>>
>>> - If a match could not be found then just report Name in Engine N/A
>>> and then the rest and keep it in dynamic only table.
>>> This is useful for NICs created by hooks, advanced topology that we
>>> can't support ATM etc.
>>>
>>> *The above does require the agent to at least match MAC to IP.
>>>
>>>
>>> Long term: The agent to report a topology the same as vdsm does (use
>>> same code at least for Linux guests?) and present it similar to what
>>> we present in the host tab. In most cases this will collapse to the
>>> short term.
>>>
>>> MTU, is good to have in any of the two if we can get it.
>>>
>>> More?
>>
>> I don't think the guest agent ip information should be correlated to the
>> vnic engine information at rest api level.
>> the vm (and vnic) api provides the authoritative configuration
>> information of the guest as defined in the engine.
>> I don't think we should 'taint' it with untrusted data from the guest.
>> it would make sense to place there IPs configured/allocated by engine
>> when we deal with ip allocation though.
>>
>
>
> I was too quick to say we have an agreement...
>
> The comment above seems to give more emphasis on the segregation between
> data collected via the GA and data configured via the engine.
>
> In the API we have today the following modeling: per VM entity we hold
> GuestInfo entity and there we hold a list of IP addresses.
>
> Are you suggesting to keep this approach and not report anything on the
> vNIC level at this point (until we'll be able to configure IP addresses
> via the engine)?

yes.

> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
> should be additional to the one on the VM level (as we discussed before
> the correlation between VNIC and GA reported data is not always possible)

i didn't think about reporting guest info at vnic level, only at vm 
level. it could be a valid option, but since some network information 
doesn't correlate to vnic's, i think a more natural modeling at vm level 
may be easier.

>
> Also what you have in mind for the UI?

at ui level i do think/agree it would make sense to show the ip per vnic 
if the correlation between the two is clean and direct (based on mac 
address i assume).
you do need to make sure "bad data" won't break the ui though.

>
>
>
>
>> i.e., the guest info element in the rest api provides good separation
>> between engine level data, and guest agent data.
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>