3:49 a.m.
The documentation of libvirt doesn't indicate which functions are for
Xen or QEMU or both. The only way to know that, is by searching in
libvirt sources.
It would be interesting for libvirt users to add in the documentation,
for each function, a mention such as "QEMU only", "Xen(TM) only",
"QEMU
and Xen(TM)", etc..
Regards.
Libvirt 0.2.3 functions dedicated to QEMU only:
virConnectListDefinedNetworks
virConnectListNetworks
virConnectNumOfDefinedNetworks
virConnectNumOfNetworks
virDomainGetAutostart
virDomainSetAutostart
virNetworkCreate
virNetworkCreateXML
virNetworkDefineXML
virNetworkDestroy
virNetworkFree
virNetworkGetAutostart
virNetworkGetBridgeName
virNetworkGetName
virNetworkGetUUID
virNetworkGetUUIDString
virNetworkGetXMLDesc
virNetworkLookupByName
virNetworkLookupByUUID
virNetworkLookupByUUIDString
virNetworkSetAutostart
virNetworkUndefine
Libvirt 0.2.3 functions dedicated to Xen(TM) only:
virConnectGetMaxVcpus
virConnectGetType
virDomainAttachDevice
virDomainCoreDump
virDomainDetachDevice
virDomainGetMaxMemory
virDomainGetSchedulerParameters
virDomainGetSchedulerType
virDomainPinVcpu
virDomainReboot
virDomainSetMaxMemory
virDomainSetMemory
virDomainSetSchedulerParameters
virDomainSetVcpus
4:04 a.m.
Philippe Berthault wrote:
The documentation of libvirt doesn't indicate which functions are
for
Xen or QEMU or both. The only way to know that, is by searching in
libvirt sources.
It would be interesting for libvirt users to add in the documentation,
for each function, a mention such as "QEMU only", "Xen(TM) only",
"QEMU
and Xen(TM)", etc..
Thanks for looking into this.
Regards.
Libvirt 0.2.3 functions dedicated to QEMU only:
virConnectListDefinedNetworks
virConnectListNetworks
virConnectNumOfDefinedNetworks
virConnectNumOfNetworks
The above should work on Xen too ...
virNetworkCreate
virNetworkCreateXML
virNetworkDefineXML
virNetworkDestroy
virNetworkFree
virNetworkGetAutostart
virNetworkGetBridgeName
virNetworkGetName
virNetworkGetUUID
virNetworkGetUUIDString
virNetworkGetXMLDesc
virNetworkLookupByName
virNetworkLookupByUUID
virNetworkLookupByUUIDString
virNetworkSetAutostart
virNetworkUndefine
The network functions currently use the QEMU server. That's a strange
historical artifact that should be removed (or perhaps has been by Dan's
patches - I have yet to check them in detail).
Libvirt 0.2.3 functions dedicated to Xen(TM) only:
virConnectGetMaxVcpus
virConnectGetType
virDomainAttachDevice
virDomainCoreDump
virDomainDetachDevice
virDomainGetMaxMemory
virDomainGetSchedulerParameters
virDomainGetSchedulerType
virDomainPinVcpu
virDomainReboot
virDomainSetMaxMemory
virDomainSetMemory
virDomainSetSchedulerParameters
virDomainSetVcpus
A lot of these are Xen-specific features. Some may one day be supported
by kvm when it gets proper, working SMP support. I notice they got an
SMP guest to boot a couple of weeks ago. However virConnectGetType
should work on QEMU.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
7:37 a.m.
On Thu, Jun 28, 2007 at 10:04:51AM +0100, Richard W.M. Jones wrote:
Philippe Berthault wrote:
>The documentation of libvirt doesn't indicate which functions are for
>Xen or QEMU or both. The only way to know that, is by searching in
>libvirt sources.
>
>It would be interesting for libvirt users to add in the documentation,
>for each function, a mention such as "QEMU only", "Xen(TM) only",
"QEMU
>and Xen(TM)", etc..
Thanks for looking into this.
>Regards.
>
>
>Libvirt 0.2.3 functions dedicated to QEMU only:
>virConnectListDefinedNetworks
>virConnectListNetworks
>virConnectNumOfDefinedNetworks
>virConnectNumOfNetworks
The above should work on Xen too ...
>virNetworkCreate
>virNetworkCreateXML
>virNetworkDefineXML
>virNetworkDestroy
>virNetworkFree
>virNetworkGetAutostart
>virNetworkGetBridgeName
>virNetworkGetName
>virNetworkGetUUID
>virNetworkGetUUIDString
>virNetworkGetXMLDesc
>virNetworkLookupByName
>virNetworkLookupByUUID
>virNetworkLookupByUUIDString
>virNetworkSetAutostart
>virNetworkUndefine
The network functions currently use the QEMU server. That's a strange
historical artifact that should be removed (or perhaps has been by Dan's
patches - I have yet to check them in detail).
Yes, all of the above are implemented in the qemu_driver.c file, however,
the way the drivers are actived means, that they get enabled for use by
Xen too. The key is that 'libvirtd' needs to be running.
>Libvirt 0.2.3 functions dedicated to Xen(TM) only:
>virConnectGetMaxVcpus
>virConnectGetType
Should both work for QEMU too now.
>virDomainAttachDevice
>virDomainDetachDevice
If QEMU/KVM gets suport for paravirt drivers we can implenent this, but
not at this time.
>virDomainCoreDump
Should implenent for QEMU, though not quite sure how yet
>virDomainGetMaxMemory
Should implement for QEMU
>virDomainGetSchedulerParameters
>virDomainGetSchedulerType
>virDomainPinVcpu
Can definitely implement these for QEMU
>virDomainReboot
Can't implement this until KVM/QEMU gets ACPI S5 support
>virDomainSetMaxMemory
>virDomainSetMemory
Can only implement these for inactive domains, until KVM/QEMU has a memory
balloon driver.
>virDomainSetSchedulerParameters
Can implement this.
>virDomainSetVcpus
Can only implement this for inactive domains
So we can & should implement most of these for QEMU....
It would still be useful to have a chart describing what APIs are implemented
by which driver though & any restrictions the impl may have.
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 -=|
7:45 a.m.
Daniel P. Berrange wrote:
It would still be useful to have a chart describing what APIs are
implemented
by which driver though & any restrictions the impl may have.
I'll have a go at this.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
8:23 a.m.
On Thu, Jun 28, 2007 at 01:45:36PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
>It would still be useful to have a chart describing what APIs are
>implemented
>by which driver though & any restrictions the impl may have.
I'll have a go at this.
Yes that would be useful thanks ! But I'm afraid it may be painful to
maintain too, as the various case may increase and the state of the
drivers/hypervisors will evolve.
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/
8:29 a.m.
On Thu, Jun 28, 2007 at 09:23:19AM -0400, Daniel Veillard wrote:
On Thu, Jun 28, 2007 at 01:45:36PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >It would still be useful to have a chart describing what APIs are
> >implemented
> >by which driver though & any restrictions the impl may have.
>
> I'll have a go at this.
Yes that would be useful thanks ! But I'm afraid it may be painful to
maintain too, as the various case may increase and the state of the
drivers/hypervisors will evolve.
As part of any patches submitted for review, we should require that
this doc be updated. Likewise if it adds a new API to virsh, the virsh
man page update should be required too.
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 -=|
8:30 a.m.
On Thu, Jun 28, 2007 at 09:23:19AM -0400, Daniel Veillard wrote:
On Thu, Jun 28, 2007 at 01:45:36PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >It would still be useful to have a chart describing what APIs are
> >implemented
> >by which driver though & any restrictions the impl may have.
>
> I'll have a go at this.
Yes that would be useful thanks ! But I'm afraid it may be painful to
maintain too, as the various case may increase and the state of the
drivers/hypervisors will evolve.
This is why library documentation should *always* mention what version
an API became supported/was added in. It's utterly miserable trying to
use an evolving library otherwise :)
regards
john
8:38 a.m.
John Levon wrote:
On Thu, Jun 28, 2007 at 09:23:19AM -0400, Daniel Veillard wrote:
> On Thu, Jun 28, 2007 at 01:45:36PM +0100, Richard W.M. Jones wrote:
>> Daniel P. Berrange wrote:
>>> It would still be useful to have a chart describing what APIs are
>>> implemented
>>> by which driver though & any restrictions the impl may have.
>> I'll have a go at this.
> Yes that would be useful thanks ! But I'm afraid it may be painful to
> maintain too, as the various case may increase and the state of the
> drivers/hypervisors will evolve.
This is why library documentation should *always* mention what version
an API became supported/was added in. It's utterly miserable trying to
use an evolving library otherwise :)
Point taken - I will try to add version numbers reflecting when
operations became supported.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
7:44 a.m.
New subject: [PATCH] hvsupport page documents libvirt versions and supported hypervisor calls (was: Re: [Libvir] request for libvirt documentation improvement)
The patch is attached.
The web page will appear at http://libvirt.org/hvsupport.html within an
hour or so.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
8:25 a.m.
New subject: [PATCH] hvsupport page documents libvirt versions and supported hypervisor calls (was: Re: [Libvir] request for libvirt documentation improvement)
On Fri, Jun 29, 2007 at 01:44:25PM +0100, Richard W.M. Jones wrote:
The patch is attached.
The web page will appear at http://libvirt.org/hvsupport.html within an
hour or so.
Cool, it's there :-)
The web site is actually updated every 30 mn (I could increase the
frequency if needed, it really costs peanuts).
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/
8:33 a.m.
New subject: [PATCH] hvsupport page documents libvirt versions and supportedhypervisorcalls (was: Re: [Libvir] request for libvirt documentation improvement)
Hi, Rich
It is very useful to me too!
Thanks
Atsushi SAKAI
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
The patch is attached.
The web page will appear at http://libvirt.org/hvsupport.html within an
hour or so.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
6169
days inactive
6170
days old
10 comments
6 participants
participants (6)
-
Atsushi SAKAI -
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Philippe Berthault -
Richard W.M. Jones