[Libvir] Request and proposition about hardware capabilities in virNodeInfo
Hello, To administrate virtual machines by using livbvirt, we need to known if the underlying hardware platform supports hvm (Intel-VT or AMD-V) or not. Currently, this information is returned by the "xm info" command of Xen in the "xen_caps" line but there is no equivalent in libvirt. So we propose to add this information in libvirt API. There is three possibilities for doing that: 1) Add one or several fields in the virNodeInfo structure returned by the virNodeGetInfo() function. These fields would be either strings such as strings returned by "xm info" or either bit fields with one bit per hardware capability. 2) Add one or several specific functions returning a boolean value for each hardware capability we want to test. 3) Add a specific function which returns either a bit fields of all the hardware capabilities or a structure such as virNodeInfo but far more complete. The problem with the proposition #1 is that the size of the virNodeInfo structure is changed. This implies for all libvirt users to recompile their programs linked with libvirt to avoid a 'core dump' at the execution. This is the reason why propositions 2 and 3 exist. NB: On an IA32 system, we can check flags in /proc/cpuinfo but on an IA64 platform with Montecito processors, there is no information about hardware capabilities in /proc/cpuinfo and the only way to known if the hardware supports hvm is by using the 'xm info' command. What is your opinion about these propositions ? Regards.
On Wed, Nov 15, 2006 at 05:38:54PM +0100, Philippe Berthault wrote:
Hello,
To administrate virtual machines by using livbvirt, we need to known if the underlying hardware platform supports hvm (Intel-VT or AMD-V) or not. Currently, this information is returned by the "xm info" command of Xen in the "xen_caps" line but there is no equivalent in libvirt. So we propose to add this information in libvirt API.
That's reasonnable, yes.
There is three possibilities for doing that: 1) Add one or several fields in the virNodeInfo structure returned by the virNodeGetInfo() function. These fields would be either strings such as strings returned by "xm info" or either bit fields with one bit per hardware capability.
<grin/> on one hand it makes sense to have a larger _virNodeInfo on the other hand doing so breaks the ABI (for virNodeGetInfo) in an horrible way.
2) Add one or several specific functions returning a boolean value for each hardware capability we want to test.
One specific function using a string input for the name of the capability int virNodeGetCapability(const char *name, int flags) would allow simple queries in an ABI compatible way
3) Add a specific function which returns either a bit fields of all the hardware capabilities or a structure such as virNodeInfo but far more complete.
Good point over 2) is that we can query a lot of parameter in one go. but we are at risk of hitting 1), so I would use padding in the structure (and maybe versioning informations within) to allow smooth evolution.
The problem with the proposition #1 is that the size of the virNodeInfo structure is changed. This implies for all libvirt users to recompile their programs linked with libvirt to avoid a 'core dump' at the execution. This is the reason why propositions 2 and 3 exist.
yup
NB: On an IA32 system, we can check flags in /proc/cpuinfo but on an IA64 platform with Montecito processors, there is no information about hardware capabilities in /proc/cpuinfo and the only way to known if the hardware supports hvm is by using the 'xm info' command.
What is your opinion about these propositions ?
2 is okay for small things like checking VMX support. 3 potentially allows to query far more. I guess it depends on how much more informations we may want to extract in the future, and how structured they may be. 2) looks a safe option, one may be interested in checking a given capability quickly without having to create a structure etc ... I guess others may have an opinion on this, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Nov 15, 2006 at 05:38:54PM +0100, Philippe Berthault wrote:
Hello,
To administrate virtual machines by using livbvirt, we need to known if the underlying hardware platform supports hvm (Intel-VT or AMD-V) or not. Currently, this information is returned by the "xm info" command of Xen in the "xen_caps" line but there is no equivalent in libvirt. So we propose to add this information in libvirt API.
There is three possibilities for doing that: 1) Add one or several fields in the virNodeInfo structure returned by the virNodeGetInfo() function. These fields would be either strings such as strings returned by "xm info" or either bit fields with one bit per hardware capability.
Yeah, as you say we clearly can't do this if we want ABI preserved.
2) Add one or several specific functions returning a boolean value for each hardware capability we want to test.
I don't think that's very scalable over time - the list of capabilities is certainly going to grow over time & its probably going to be varying according to harware too.
3) Add a specific function which returns either a bit fields of all the hardware capabilities or a structure such as virNodeInfo but far more complete.
I think that'll also suffer over the long term with growth in capabilities.
The problem with the proposition #1 is that the size of the virNodeInfo structure is changed. This implies for all libvirt users to recompile their programs linked with libvirt to avoid a 'core dump' at the execution. This is the reason why propositions 2 and 3 exist.
How about 4) virNodeXMLDesc() which returns an XML bloc describing the host capabilities (and whatever other interesting host info we might need). It gives a simple ABI, while allowing easy extension over time to add more data, and matches virDomainXMLDesc quite nicely.
NB: On an IA32 system, we can check flags in /proc/cpuinfo but on an IA64 platform with Montecito processors, there is no information about hardware capabilities in /proc/cpuinfo and the only way to known if the hardware supports hvm is by using the 'xm info' command.
What is your opinion about these propositions ?
There's clearly a need for getting information about host system capabilities when writing applications using libvirt. What isn't so clear, is where this information should belong - alot of it is hardware related & thus already be provided by the HAL daemon over DBus. Virt-manager already talks to HAL to get much of this info If we start adding hardware info to libvirt, where do we draw the line ? Only stuff that's explicitly related to virtualization, or also include things used by virt, such as network device/bridge info ? Or should be push all of this information into HAL. Personally I'd think all info relating to hardware should belong to HAL, but of course this does open the question about how we access this info if running virt-manager remotely in the future. In summary, I'm not at all sure where this info should live, so for now I'm avoiding the issue by having a helper library which has these functions http://hg.et.redhat.com/virt/applications/virtinst--devel Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Thanks a lot for your response about virtinst library. The information we need (hvm or not) is in the /sys/hypervisor/properties/capabilites file. As you say "If we start adding hardware info to libvirt, where do we draw the line ?". We are agree with this question. It wasn't a good idea to introduce in libvirt some APIs related to the hardware. So you can drop the request. Daniel P. Berrange a écrit :
If we start adding hardware info to libvirt, where do we draw the line ? ...
In summary, I'm not at all sure where this info should live, so for now I'm avoiding the issue by having a helper library which has these functions
http://hg.et.redhat.com/virt/applications/virtinst--devel
Dan.
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Philippe Berthault