1:02 a.m.
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(a)redhat.com>
>>>> To: engine-devel(a)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...
> The Guest Agent reports the vNic details:
>
> IP addresses (both IPv4 and IPv6).
> vNic internal name
Actually, the guest agent reports all in-guest network device. vNics (and bonds
and vlans) included.
true, but AFAIU we won't be able to build the networking topology of the
guest from this report. For example if the guest agent reports a bridge
it does not say to which interface it is connected to etc.
>
> The retrieved information by the Guest Agent should be reported to the ovirt-engine
and to be viewed by its client
> Today only the IPv4 addresses are reported to the User, kept on VM level. This
feature will maintain the information on vNic level.
I think we should report the information on the vNic level only when we
can. If we have a vlan device, which we do not know how tie to a
specific vNic, we'd better report its IP address on the VM level.
If I understand you correctly you are suggesting to keep the IP address
property also on the VM level and for devices with reported IP-address
which the engine can not correlate to a VNIC hold it on this VM-level
property.
My concern is that in the UI we are currently displaying in the main
greed the VM IP and on the network sub-tab the IP per vNIC.
If we choose to hold the IP addresses the engine does not correlate on
the VM level they become the more visible addresses for the users which
I am not sure is what we want.
What I suggest is to add a property to VM that says network devices and
hold the GA report as a 'blob'. we can display this info in the API on
the VM level and in the UI maybe display it on the general sub-tab or
add a dialog on the network subtab.
It might be worthwhile to note that we should (try to) correlate Engine
idea of a vNic with the guest agent report, according to the mac address.
The guest can try to fool us by changing the mac address, but that's
true for every bit of info coming from the agent.
Dan.