9:18 a.m.
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.
9:48 a.m.
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 -=|
8:52 a.m.
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.
6423
days inactive
6426
days old
2 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Mark McLoughlin