[Engine-devel] Report vNic Implementation Details

[Simon Grinberg]

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Friday, November 23, 2012 9:02:09 AM
> Subject: Re: [Engine-devel] Report  vNic Implementation Details
> 
> 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.


At this point what you need to make sure is that if it does exit you do not crash due to unexpected data. 
Don't forget that using a hook you may create nested virtualization today. 
 
> 
> 
> > 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.

Actually in most cased it does since by default the bridge will get the interface IP. 
Well not that accurate, the bridge gets the lowest IP the of all the devices it is connected to, however there was a fix in libvirt some time back to make sure the external interface IP will be the one the bride gets by providing the tap/tun devices connected to the bridge a MAC address starting with 'FE'

> 
> 
> >>
> >> 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.

I think you should display it as correlated as possible - since I agree with you that the common case is an IP set directly on the VNIC, it means in most cases you'll present the right info in the right place. let's not allow 10% of the cases block us then doing the right thing for the other 90. 

Try to correlate based on MAC and present the internal name and IP as the guest info on the same line with the Defined nic (In API they can (and should as Itamar noted) be separated and probably held as a blob per your suggestion.

Now your problematic scenarios:
1. You have a single VLAN, bridge etc -> It translates to many entries with the same MAC but only one has IP -> collapse all to 'Select to present the one that has IP'. 
2. You have a MAC that does not match -> Present this as a guest only device (IE new line - instead of name say guest only), let the user see and correlate if he wants - it is his network, if he did crazy things it's his problem) 
3. Multiple bridges and Vlans -> Collect all IPs per MAC and collapse, then present as above 

>From the 3 above I expect only the first to be found ATM and even that is rare.

In the future we can work on what I've suggested in a previous email on this thread, present a guest network topology same as you do for the host. 
 

> 
> 
> > 
> > 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.
> > 
> 
>