10:38 a.m.
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.
11:51 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
12:12 p.m.
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 -=|
4:51 a.m.
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.
6580
days inactive
6581
days old
3 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Philippe Berthault