[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Request and proposition about hardware capabilities in virNodeInfo

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


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]