[libvirt] Interface driver and ESX support
I'm trying to get a feel of the python binding and the esx driver Trying to get the number of interfaces hit(as anticipated) a non-support wall: Traceback (most recent call last): File "test.py", line 362, in ? vmm.refresh() File "test.py", line 189, in refresh print self.conn.numOfDefinedInterfaces() File "/usr/lib/python2.4/site-packages/libvirt.py", line 1347, in numOfDefinedInterfaces if ret == -1: raise libvirtError ('virConnectNumOfDefinedInterfaces() failed', conn=self) libvirt.libvirtError: this function is not supported by the hypervisor: virConnectNumOfDefinedInterfaces I'm wondering how to fix it can I register the esx driver as the interface driver? so I can use the ESX web-services to handle all the interface issues that normally(?) netcf would handle? if yes - how is it done? I thought that configure --without-netcf would do the trick(it didn't-I think) Thanks Shahar
On Tue, Sep 08, 2009 at 06:56:10AM -0700, Shahar Klein wrote:
I'm trying to get a feel of the python binding and the esx driver
Trying to get the number of interfaces hit(as anticipated) a non-support wall:
Traceback (most recent call last): File "test.py", line 362, in ? vmm.refresh() File "test.py", line 189, in refresh print self.conn.numOfDefinedInterfaces() File "/usr/lib/python2.4/site-packages/libvirt.py", line 1347, in numOfDefinedInterfaces if ret == -1: raise libvirtError ('virConnectNumOfDefinedInterfaces() failed', conn=self) libvirt.libvirtError: this function is not supported by the hypervisor: virConnectNumOfDefinedInterfaces
I'm wondering how to fix it
/** * virConnectNumOfDefinedInterfaces: * @conn: pointer to the hypervisor connection * * Provides the number of defined (inactive) interfaces on the * physical host. * * Returns the number of defined interface found or -1 in case of * error */ *on thephysical host* ESX only support remote access basically, so the whole set of Interface functions are moot. I think it's not what you're looking for anyway. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
mmm I would like to get host(i.e. node) interface info as well as domain(guest) network/interface info I will probably would like to set/manipulate the node and domains as well but it is simpler to start with the get functions - isn't it? Did I totally misunderstood the architecture? shahar ________________________________ From: Daniel Veillard <veillard@redhat.com> To: Shahar Klein <shaharklein@yahoo.com> Cc: libvir-list@redhat.com Sent: Tuesday, September 8, 2009 5:20:34 PM Subject: Re: [libvirt] Interface driver and ESX support On Tue, Sep 08, 2009 at 06:56:10AM -0700, Shahar Klein wrote:
I'm trying to get a feel of the python binding and the esx driver
Trying to get the number of interfaces hit(as anticipated) a non-support wall:
Traceback (most recent call last): File "test.py", line 362, in ? vmm.refresh() File "test.py", line 189, in refresh print self.conn.numOfDefinedInterfaces() File "/usr/lib/python2.4/site-packages/libvirt.py", line 1347, in numOfDefinedInterfaces if ret == -1: raise libvirtError ('virConnectNumOfDefinedInterfaces() failed', conn=self) libvirt.libvirtError: this function is not supported by the hypervisor: virConnectNumOfDefinedInterfaces
I'm wondering how to fix it
/** * virConnectNumOfDefinedInterfaces: * @conn: pointer to the hypervisor connection * * Provides the number of defined (inactive) interfaces on the * physical host. * * Returns the number of defined interface found or -1 in case of * error */ *on thephysical host* ESX only support remote access basically, so the whole set of Interface functions are moot. I think it's not what you're looking for anyway. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Shahar Klein wrote:
mmm
I would like to get host(i.e. node) interface info as well as domain(guest) network/interface info
I will probably would like to set/manipulate the node and domains as well but it is simpler to start with the get functions - isn't it?
Did I totally misunderstood the architecture?
More or less, yes (at least for the ESX driver). The ESX driver is a bit special, and different from some of the other drivers in that you don't run a libvirtd on the target machine. It accesses the ESX API's via SOAP on the remote machine. So what the libvirt driver can do is limited by what the ESX API's can do. If the ESX API's can do the sort of enumeration you are talking about, then I think it would be possible to implement it, although it would require an entirely new interface driver. -- Chris Lalancette
Let me rephrase my question : ) In the current libvirt infrastructure I can do a lot of things with libvirt and a remote ESX node I can list all the guests I can suspend a guest I can get a lot of node info and much more.... can I (for example) 1. add NIC to a guest domain 2. list all the physical interfaces on a node If not - what do I need to develop should I expand the current driver or should I need to develop a new interface driver(like netcf) or maybe I can assign the current esx driver as the interface driver and expand it to handle the relvant requests 10x again Shahar ________________________________ From: Chris Lalancette <clalance@redhat.com> To: Shahar Klein <shaharklein@yahoo.com> Cc: veillard@redhat.com; libvir-list@redhat.com Sent: Tuesday, September 8, 2009 5:55:42 PM Subject: Re: [libvirt] Interface driver and ESX support Shahar Klein wrote:
mmm
I would like to get host(i.e. node) interface info as well as domain(guest) network/interface info
I will probably would like to set/manipulate the node and domains as well but it is simpler to start with the get functions - isn't it?
Did I totally misunderstood the architecture?
More or less, yes (at least for the ESX driver). The ESX driver is a bit special, and different from some of the other drivers in that you don't run a libvirtd on the target machine. It accesses the ESX API's via SOAP on the remote machine. So what the libvirt driver can do is limited by what the ESX API's can do. If the ESX API's can do the sort of enumeration you are talking about, then I think it would be possible to implement it, although it would require an entirely new interface driver. -- Chris Lalancette
Shahar Klein wrote:
Let me rephrase my question : )
In the current libvirt infrastructure I can do a lot of things with libvirt and a remote ESX node I can list all the guests I can suspend a guest I can get a lot of node info and much more....
can I (for example) 1. add NIC to a guest domain
From looking at the current libvirt ESX driver (in src/esx/esx_driver.c), it looks like no, this is not implemented yet.
2. list all the physical interfaces on a node
This is also not implemented yet.
If not - what do I need to develop should I expand the current driver
For case 1) above, you should certainly expand the current driver (although again, this all depends on whether the ESX SOAP API supports this operation, which I can't answer). For case 2) above, it's a lot more tricky. If you look at src/interface_driver.c, that is one network interface driver that can enumerate all of the physical devices on a host (using netcf as the backend). *If* the ESX SOAP API's provide something similar, then you possibly could write a new network interface driver for ESX that used the SOAP API's on the backend. This would be a whole new interface driver, and may require new API's (although I'm not sure about this, since I don't know the interface driver very well). -- Chris Lalancette
thanks Chris I'll try to write somthing and see how it goes shahar ________________________________ From: Chris Lalancette <clalance@redhat.com> To: Shahar Klein <shaharklein@yahoo.com> Cc: veillard@redhat.com; libvir-list@redhat.com Sent: Wednesday, September 9, 2009 10:18:39 AM Subject: Re: [libvirt] Interface driver and ESX support Shahar Klein wrote:
Let me rephrase my question : )
In the current libvirt infrastructure I can do a lot of things with libvirt and a remote ESX node I can list all the guests I can suspend a guest I can get a lot of node info and much more....
can I (for example) 1. add NIC to a guest domain
From looking at the current libvirt ESX driver (in src/esx/esx_driver.c), it looks like no, this is not implemented yet.
2. list all the physical interfaces on a node
This is also not implemented yet.
If not - what do I need to develop should I expand the current driver
For case 1) above, you should certainly expand the current driver (although again, this all depends on whether the ESX SOAP API supports this operation, which I can't answer). For case 2) above, it's a lot more tricky. If you look at src/interface_driver.c, that is one network interface driver that can enumerate all of the physical devices on a host (using netcf as the backend). *If* the ESX SOAP API's provide something similar, then you possibly could write a new network interface driver for ESX that used the SOAP API's on the backend. This would be a whole new interface driver, and may require new API's (although I'm not sure about this, since I don't know the interface driver very well). -- Chris Lalancette
2009/9/9 Shahar Klein <shaharklein@yahoo.com>:
Let me rephrase my question : ) In the current libvirt infrastructure I can do a lot of things with libvirt and a remote ESX node I can list all the guests I can suspend a guest I can get a lot of node info and much more.... can I (for example) 1. add NIC to a guest domain
The attach/detach device driver functions aren't implemented yet, but that's on my todo list.
2. list all the physical interfaces on a node
The VI API contains methods and types to do this. It requires a new interface driver as Chris already said. This is not implemented yet, but that's on my todo list.
If not - what do I need to develop should I expand the current driver or should I need to develop a new interface driver(like netcf) or maybe I can assign the current esx driver as the interface driver and expand it to handle the relvant requests 10x again Shahar
The basic question is: How urgent is this for you? Do you need it now or can you wait some time until I implemented it? PS: I just finished the implementation of the driver function for virDomainDefineXML(). I need to cleanup the patches a bit and will post them by the end of the week, depends on how fast I can get done some other urgent, university related work.
I think I understand the mechanism of the VI API and the way esx_vi.c is using it the surounding is a bit more complex for me so can you provide the framework? I mean can you put in the esx_interface_driver.c and h and the registration etc... and also putting it all into the auto make mechanism(I should learn this sometime...) I will put in the content into the functions for the time being I am registering the esx_driver as the interface driver so I can get a fill of it something like that: diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c index 8d1af71..677f778 100644 --- a/src/esx/esx_driver.c +++ b/src/esx/esx_driver.c @@ -3018,7 +3018,89 @@ esxDomainMigrateFinish(virConnectPtr dconn, const char *dname, return esxDomainLookupByName(dconn, dname); } +struct interface_driver +{ + virMutex lock; +}; + +static virDrvOpenStatus esxInterfaceOpenInterface(virConnectPtr conn, + virConnectAuthPtr auth ATTRIBUTE_UNUSED, + int flags ATTRIBUTE_UNUSED) +{ + struct interface_driver *driverState; + + if (VIR_ALLOC(driverState) < 0) + { + virReportOOMError(conn); + goto alloc_error; + } + + /* initialize non-0 stuff in driverState */ + if (virMutexInit(&driverState->lock) < 0) + { + /* what error to report? */ + goto mutex_error; + } + + + conn->interfacePrivateData = driverState; + return 0; +mutex_error: + VIR_FREE(driverState); +alloc_error: + return -1; +} + +static int esxInterfaceCloseInterface(virConnectPtr conn) +{ + + if (conn->interfacePrivateData != NULL) + { + struct interface_driver *driver = conn->interfacePrivateData; + /* destroy lock */ + virMutexDestroy(&driver->lock); + /* free driver state */ + VIR_FREE(driver); + } + conn->interfacePrivateData = NULL; + return 0; +} + +static int esxInterfaceNumOfInterfaces(virConnectPtr conn) +{ + int count = 7; + return count; +} + +static virInterfaceDriver esxInterfaceDriver = { + "EsxInterface", + esxInterfaceOpenInterface, /* open */ + esxInterfaceCloseInterface, /* close */ + esxInterfaceNumOfInterfaces, /* numOfInterfaces */ + NULL, /* listInterfaces */ + NULL, /* numOfInterfaces */ + NULL, /* listInterfaces */ + NULL, /* interfaceLookupByName */ + NULL, /* interfaceLookupByMACSTring */ + NULL, /* interfaceGetXMLDesc */ + NULL, /* interfaceDefineXML */ + NULL, /* interfaceUndefine */ + NULL, /* interfaceCreate */ + NULL, /* interfaceDestroy */ +#if 0 + esxInterfaceListInterfaces, /* listInterfaces */ + esxInterfaceNumOfDefinedInterfaces, /* numOfInterfaces */ + esxInterfaceListDefinedInterfaces, /* listInterfaces */ + esxInterfaceLookupByName, /* interfaceLookupByName */ + esxInterfaceLookupByMACString, /* interfaceLookupByMACSTring */ + esxInterfaceGetXMLDesc, /* interfaceGetXMLDesc */ + esxInterfaceDefineXML, /* interfaceDefineXML */ + esxInterfaceUndefine, /* interfaceUndefine */ + esxInterfaceCreate, /* interfaceCreate */ + esxInterfaceDestroy, /* interfaceDestroy */ +#endif +}; static virDriver esxDriver = { VIR_DRV_ESX, @@ -3096,6 +3178,7 @@ int esxRegister(void) { virRegisterDriver(&esxDriver); + virRegisterInterfaceDriver(&esxInterfaceDriver); return 0; } ________________________________ From: Matthias Bolte <matthias.bolte@googlemail.com> To: Shahar Klein <shaharklein@yahoo.com> Cc: Chris Lalancette <clalance@redhat.com>; libvir-list@redhat.com Sent: Wednesday, September 9, 2009 11:37:17 AM Subject: Re: [libvirt] Interface driver and ESX support 2009/9/9 Shahar Klein <shaharklein@yahoo.com>:
Let me rephrase my question : ) In the current libvirt infrastructure I can do a lot of things with libvirt and a remote ESX node I can list all the guests I can suspend a guest I can get a lot of node info and much more.... can I (for example) 1. add NIC to a guest domain
The attach/detach device driver functions aren't implemented yet, but that's on my todo list.
2. list all the physical interfaces on a node
The VI API contains methods and types to do this. It requires a new interface driver as Chris already said. This is not implemented yet, but that's on my todo list.
If not - what do I need to develop should I expand the current driver or should I need to develop a new interface driver(like netcf) or maybe I can assign the current esx driver as the interface driver and expand it to handle the relvant requests 10x again Shahar
The basic question is: How urgent is this for you? Do you need it now or can you wait some time until I implemented it? PS: I just finished the implementation of the driver function for virDomainDefineXML(). I need to cleanup the patches a bit and will post them by the end of the week, depends on how fast I can get done some other urgent, university related work.
2009/9/9 Shahar Klein <shaharklein@yahoo.com>:
I think I understand the mechanism of the VI API and the way esx_vi.c is using it the surounding is a bit more complex for me so can you provide the framework? I mean can you put in the esx_interface_driver.c and h and the registration etc... and also putting it all into the auto make mechanism(I should learn this sometime...) I will put in the content into the functions for the time being I am registering the esx_driver as the interface driver so I can get a fill of it
Well, if you want to give it a try, here you go. I attached a patch that adds a basic interface driver with open and close method. The interface driver doesn't need it's own private driver struct, it just uses the same context already opened by the main ESX driver. Listing the available physical NICs should be easy. You'll need to obtain the HostSystem object and query for its config.network.pnic property. This is a list of PhysicalNic objects. You'll need to add a mapping for the PhysicalNic type to the esx_vi_types.[ch]. There is plenty of examples in the current ESX driver how to do all these things. Matthias
Thank you very much : ) ________________________________ From: Matthias Bolte <matthias.bolte@googlemail.com> To: Shahar Klein <shaharklein@yahoo.com> Cc: Chris Lalancette <clalance@redhat.com>; libvir-list@redhat.com Sent: Wednesday, September 9, 2009 1:11:47 PM Subject: Re: [libvirt] Interface driver and ESX support 2009/9/9 Shahar Klein <shaharklein@yahoo.com>:
I think I understand the mechanism of the VI API and the way esx_vi.c is using it the surounding is a bit more complex for me so can you provide the framework? I mean can you put in the esx_interface_driver.c and h and the registration etc... and also putting it all into the auto make mechanism(I should learn this sometime...) I will put in the content into the functions for the time being I am registering the esx_driver as the interface driver so I can get a fill of it
Well, if you want to give it a try, here you go. I attached a patch that adds a basic interface driver with open and close method. The interface driver doesn't need it's own private driver struct, it just uses the same context already opened by the main ESX driver. Listing the available physical NICs should be easy. You'll need to obtain the HostSystem object and query for its config.network.pnic property. This is a list of PhysicalNic objects. You'll need to add a mapping for the PhysicalNic type to the esx_vi_types.[ch]. There is plenty of examples in the current ESX driver how to do all these things. Matthias
I'm not sure what you mean about mapping lets take the pnics as a study case for me do I need to define a structure similar to this: http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/v... and also take care for it's allocation? ________________________________ From: Matthias Bolte <matthias.bolte@googlemail.com> To: Shahar Klein <shaharklein@yahoo.com> Cc: Chris Lalancette <clalance@redhat.com>; libvir-list@redhat.com Sent: Wednesday, September 9, 2009 1:11:47 PM Subject: Re: [libvirt] Interface driver and ESX support 2009/9/9 Shahar Klein <shaharklein@yahoo.com>:
I think I understand the mechanism of the VI API and the way esx_vi.c is using it the surounding is a bit more complex for me so can you provide the framework? I mean can you put in the esx_interface_driver.c and h and the registration etc... and also putting it all into the auto make mechanism(I should learn this sometime...) I will put in the content into the functions for the time being I am registering the esx_driver as the interface driver so I can get a fill of it
Well, if you want to give it a try, here you go. I attached a patch that adds a basic interface driver with open and close method. The interface driver doesn't need it's own private driver struct, it just uses the same context already opened by the main ESX driver. Listing the available physical NICs should be easy. You'll need to obtain the HostSystem object and query for its config.network.pnic property. This is a list of PhysicalNic objects. You'll need to add a mapping for the PhysicalNic type to the esx_vi_types.[ch]. There is plenty of examples in the current ESX driver how to do all these things. Matthias
2009/9/10 Shahar Klein <shaharklein@yahoo.com>:
I'm not sure what you mean about mapping lets take the pnics as a study case for me do I need to define a structure similar to this: http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/v... and also take care for it's allocation?
Yes, you need to implement the mapping (a better word may be 'binding') of this VI API type to a C type, that also includes to care about its allocation. You'll need to implement at least this set of function in esx_vi_types.[ch]: esxVI_PhysicalNic_Alloc() esxVI_PhysicalNic_Free() esxVI_PhysicalNic_CastFromAnyType() esxVI_PhysicalNic_CastListFromAnyType() esxVI_PhysicalNic_Deserialize() esxVI_PhysicalNic_DeserializeList() You could use the binding for the HostCpuIdInfo type, but unfortunately I haven't published the code for it yet. This code also includes some essential helper functions for esxVI_PhysicalNic_CastListFromAnyType(). Beside the PhysicalNic type, you may also have to bind the types of its members like PhysicalNicLinkInfo, PhysicalNicSpec and HostIpConfig, if you need or care about the information provided by them. The binding for HostCpuIdInfo is part of a larger set of patches that add some new features to ESX driver, but the patches needs some cleanup first. I may have some time later this evening to clean them up and post them. PS: You should refer to version 2.5 of the VI API [1] and not 4.0, because the complete VI API mapping is currently based on version 2.5. At some point I'll have to properly distinguish between version 2.5 and 4.0, but currently I would like to stick to version 2.5 only. [1] http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/ Matthias
I've defined (among others): int esxVI_PhysicalNic_CastListFromAnyType(virConnectPtr conn, esxVI_AnyType *anyType, esxVI_PhysicalNic **pNicList); but runing it returns somthing like: Expecting type 'PhysicalNic' but found 'ArrayOfPhysicalNic' Does it mean I should also implement: esxVI_ArrayOfPhysicalNic_CastListFromAnyType() and all the funcs/type definition coming with it? thanks Shahar ________________________________ From: Matthias Bolte <matthias.bolte@googlemail.com> To: Shahar Klein <shaharklein@yahoo.com> Cc: libvir-list@redhat.com Sent: Thursday, September 10, 2009 6:24:25 PM Subject: Re: [libvirt] Interface driver and ESX support 2009/9/10 Shahar Klein <shaharklein@yahoo.com>:
I'm not sure what you mean about mapping lets take the pnics as a study case for me do I need to define a structure similar to this: http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/v... and also take care for it's allocation?
Yes, you need to implement the mapping (a better word may be 'binding') of this VI API type to a C type, that also includes to care about its allocation. You'll need to implement at least this set of function in esx_vi_types.[ch]: esxVI_PhysicalNic_Alloc() esxVI_PhysicalNic_Free() esxVI_PhysicalNic_CastFromAnyType() esxVI_PhysicalNic_CastListFromAnyType() esxVI_PhysicalNic_Deserialize() esxVI_PhysicalNic_DeserializeList() You could use the binding for the HostCpuIdInfo type, but unfortunately I haven't published the code for it yet. This code also includes some essential helper functions for esxVI_PhysicalNic_CastListFromAnyType(). Beside the PhysicalNic type, you may also have to bind the types of its members like PhysicalNicLinkInfo, PhysicalNicSpec and HostIpConfig, if you need or care about the information provided by them. The binding for HostCpuIdInfo is part of a larger set of patches that add some new features to ESX driver, but the patches needs some cleanup first. I may have some time later this evening to clean them up and post them. PS: You should refer to version 2.5 of the VI API [1] and not 4.0, because the complete VI API mapping is currently based on version 2.5. At some point I'll have to properly distinguish between version 2.5 and 4.0, but currently I would like to stick to version 2.5 only. [1] http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/ Matthias
No, as I said before you should wait until you can use the unpublished binding of HostCpuIdInfo as an example. This also includes the code to handle ArrayOf* types. I'm currently cleaning up this patches (didn't have time on thursday for that) and will post them today, just wait for this patches, because they will help you. Matthias 2009/9/13 Shahar Klein <shaharklein@yahoo.com>:
I've defined (among others): int esxVI_PhysicalNic_CastListFromAnyType(virConnectPtr conn, esxVI_AnyType *anyType, esxVI_PhysicalNic **pNicList); but runing it returns somthing like: Expecting type 'PhysicalNic' but found 'ArrayOfPhysicalNic' Does it mean I should also implement: esxVI_ArrayOfPhysicalNic_CastListFromAnyType() and all the funcs/type definition coming with it? thanks Shahar ________________________________ From: Matthias Bolte <matthias.bolte@googlemail.com> To: Shahar Klein <shaharklein@yahoo.com> Cc: libvir-list@redhat.com Sent: Thursday, September 10, 2009 6:24:25 PM Subject: Re: [libvirt] Interface driver and ESX support
2009/9/10 Shahar Klein <shaharklein@yahoo.com>:
I'm not sure what you mean about mapping lets take the pnics as a study case for me do I need to define a structure similar to this:
http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/v... and also take care for it's allocation?
Yes, you need to implement the mapping (a better word may be 'binding') of this VI API type to a C type, that also includes to care about its allocation. You'll need to implement at least this set of function in esx_vi_types.[ch]:
esxVI_PhysicalNic_Alloc() esxVI_PhysicalNic_Free() esxVI_PhysicalNic_CastFromAnyType() esxVI_PhysicalNic_CastListFromAnyType() esxVI_PhysicalNic_Deserialize() esxVI_PhysicalNic_DeserializeList()
You could use the binding for the HostCpuIdInfo type, but unfortunately I haven't published the code for it yet. This code also includes some essential helper functions for esxVI_PhysicalNic_CastListFromAnyType().
Beside the PhysicalNic type, you may also have to bind the types of its members like PhysicalNicLinkInfo, PhysicalNicSpec and HostIpConfig, if you need or care about the information provided by them.
The binding for HostCpuIdInfo is part of a larger set of patches that add some new features to ESX driver, but the patches needs some cleanup first. I may have some time later this evening to clean them up and post them.
PS: You should refer to version 2.5 of the VI API [1] and not 4.0, because the complete VI API mapping is currently based on version 2.5. At some point I'll have to properly distinguish between version 2.5 and 4.0, but currently I would like to stick to version 2.5 only.
[1] http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/
Matthias
participants (4)
-
Chris Lalancette -
Daniel Veillard -
Matthias Bolte -
Shahar Klein