[Libvir] Capabilities XML format
Hey, Just a few brief comments after using it: - <os_type>xen<os_type> is equivalent to <os><type>linux</type></os>, which is pretty confusing. Sounds to me like we should deprecate the latter and move to "xen" everywhere for this. - We have <host><arch>x86_64</arch></host> and <guest><arch name="x86_64"/></guest>. I can see why we did that, but it seems odd to me to have different syntaxes for <arch> depending on its context. - I'm not sure how interesting the stuff in <guest><arch> is ... how were we envisaging these bits being used? - It's a pain to have to parse XML to discover whether e.g. you can run a 64 bit guest. I'd much prefer to see the kind of API I'm using here: http://www.gnome.org/~markmc/code/test-caps.py e.g. caps = cnx.getCapabilities() supports_x86_64 = False for guest in caps.guests: if guest.arch == "x86_64": supports_x86_64 = True Cheers, Mark.
On Fri, Apr 20, 2007 at 03:18:35PM +0100, Mark McLoughlin wrote:
Hey, Just a few brief comments after using it:
- <os_type>xen<os_type> is equivalent to <os><type>linux</type></os>, which is pretty confusing. Sounds to me like we should deprecate the latter and move to "xen" everywhere for this.
Yes, I agree - the Xen driver should never have been using 'linux' for indicating paravirt, since the Xen paravirt ABI is guest agnositic.
- We have <host><arch>x86_64</arch></host> and <guest><arch name="x86_64"/></guest>. I can see why we did that, but it seems odd to me to have different syntaxes for <arch> depending on its context.
Irritating, but we're stuck with it :-)
- I'm not sure how interesting the stuff in <guest><arch> is ... how were we envisaging these bits being used?
The 'domain' block within it lets you determine what kind of guest VM is available to host the OS. eg QEMU, KVM, KQEMU, Xen. It maps to the <domain type='XXX'> attribute/element in the domain XML. The 'wordsize' is just a convenience so you don't need to have a manual mapping of arch names to wordsize, if you wanted that info. Depending on OS/domain type there's various other elements inside there too - emulator, loader, machine etc. These all map through to the domain XML. The idea is you pick which arch you're going to run, and you can take all the info in the capabilities and plug it into your domain XML. Once we use it in virt-manager/virt-install it will remove alot of hardcoded if Xen ...if paravirt...else nastiness.
- It's a pain to have to parse XML to discover whether e.g. you can run a 64 bit guest. I'd much prefer to see the kind of API I'm using here:
This comes back to a previous discussion we had about the convenience of the python APIs in particular. They're fairly low level mapping straight onto libvirt C APIs with no higher level constructs. In virt-manager we have some higher level python APIs we wrap on top, but they've been changing quite abit over time as we evolve our codebase. Some of things they do include tracking VM state & resource info, which probably isn't so desirable for a general API.
http://www.gnome.org/~markmc/code/test-caps.py
e.g.
caps = cnx.getCapabilities() supports_x86_64 = False for guest in caps.guests: if guest.arch == "x86_64": supports_x86_64 = True
Or.... xml = cnx.getCapabilities() supports_x86_64 = xpathBool("count(/capabilities/guest/arch[@name='x86_64']) > 0") Regards, 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 -=|
Hi, One other comment - we should expose how a guest can be booted - i.e. what values of <boot dev='foo'> is supported and whether <kernel> is supported. e.g. QEMU should be able to boot with a supplied kernel/initrd or, as Dan points out, over the network using PXE. Cheers, Mark.
participants (2)
-
Daniel P. Berrange -
Mark McLoughlin