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" <[email protected]> >>>>>>> To: [email protected] >>>>>>> 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. > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
