[libvirt] [PATCH v5] ESX: Add routines to interface driver

Ata Bohra ata.husain at hotmail.com
Mon Aug 6 19:18:38 UTC 2012



(Please ignore earlier messages, as for reason the messages got truncated)
 
Thanks Matthias for the explanation, I was working on the project which required libvirt to control/set networking on a given ESX host. As ESXi is different from hosted hypervisors, we need to configure ESX interface (IP, routing, bridge etc), also it is an integral part of the host settings.
But re-thinking the whole design in light of the explanation provided by you, libvirt interfaces are actually mapping physical interfaces to virtual network. Further, hostVirtualSwitch behaves like switch which defines ports where we can plug VM virtual ethernet cards. It seems likely that we still want to have ability of configuring ESXi virtual interfaces (hostVirtualNics) so not sure if listing physical Nics is completly right to get an 100% operational ESX host. 
Michal has already reviewed the code and I would do the same if this design is one that maps to libvirt terminology the most. Though my design is not accpeted, but it was an amazing learning experience. Thanks for everyones input that came along the way.
 
Regards,
Ata
 

> Date: Sun, 5 Aug 2012 22:45:26 +0200
> Subject: Re: [libvirt] [PATCH v5] ESX: Add routines to interface driver
> From: matthias.bolte at googlemail.com
> To: ata.husain at hotmail.com
> CC: libvir-list at redhat.com
> 
> 2012/8/5 Matthias Bolte <matthias.bolte at googlemail.com>:
> > 2012/8/2 Ata E Husain Bohra <ata.husain at hotmail.com>:
> >> Add following routines to esx_interface_driver:
> >>     esxNumOfInterfaces,
> >>     esxNumOfDefinedInterfaces,
> >>     esxListInterfaces,
> >>     esxListDefinedInterfaces,
> >>     esxInterfaceLookupByMACString,
> >>     esxInterfaceGetXMLDesc,
> >>     esxInterfaceUndefine,
> >>     esxInterfaceCreate,
> >>     esxInterfaceDestroy
> >>
> >> Signed-off-by: Ata E Husain Bohra <ata.husain at hotmail.com>
> >
> > Okay, I finally had time to take a detailed look at the interface
> > driver and the related network driver and your proposed implementation
> > for the interface driver.
> >
> > I think listing HostVirtualNics in the interface driver is not the
> > correct mapping between vSphere API and libvirt. Also listing
> > HostVirtualNics as bridges is not correct because a HostVirtualNic is
> > not a bridge. A HostVirtualSwitch can be seen as a kind of bridge, but
> > a HostVirtualSwitch is more like a virtual network in libvirt terms.
> >
> > In terms of libvirt the interface driver is about physical NICs that
> > can be used to connect a libvirt virtual network to the physical
> > network. Therefore, the interface driver should just list the
> > PhysicalNics, but not the HostVirtualNics. I think there is currently
> > no place in the libvirt API to map the HostVirtualNics to. Also I
> > don't think that it is important to make the HostVirtualNics available
> > via libvirt API. I might be wrong here, but mapping them via libvirt
> > interface driver is still wrong in my opinion.
> >
> > Regarding the network driver, I think a libvirt virtual network is
> > best represented by a HostVirtualSwitch and the HostPortGroups are
> > mapped to the portgroups of a libvirt virtual switch.
> >
> > I'm sorry that I let you wait for quite a while now until I came to
> > this understanding that is contrary to your proposed interface driver.
> 
> I missed to mention that I proposed an implementation for the
> interface and network drivers according to the described mapping:
> 
> https://www.redhat.com/archives/libvir-list/2012-August/msg00307.html
> https://www.redhat.com/archives/libvir-list/2012-August/msg00308.html
> 
> -- 
> Matthias Bolte
> http://photron.blogspot.com
 		 	   		  

--
libvir-list mailing list
libvir-list at redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120806/b3f2c099/attachment-0001.htm>


More information about the libvir-list mailing list