Re: [Engine-devel] Report vNic Implementation Details
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Simon Grinberg" <simon(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, November 22, 2012 11:18:48 PM
Subject: Re: [Engine-devel] Report vNic Implementation Details
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.
Agree that there should be a clear distinction between guest data and configuration.
Never the less you need to report the guest data and correlate where you can to the
configuration.
Where and how you present this correlation is a different matter and should be discussed.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel