On Wed, Mar 14, 2007 at 11:59:57AM +0000, Richard W.M. Jones wrote:
>
> My thoughts are that capabilities need to return the following
> information about the underlying driver/hypervisor:
>
> * Host CPU flags (1,8)
> * List of guest architectures supported. For each of these:
> - Model of virtualised CPU (10,13)
> example: x86_64
> - Name of the virtualised machine (if applic.)
> example: pc
> - Virtualised CPU features: PAE, ...
> - Fullvirt flag: can we run an unmodified OS as a guest? (2,9)
> or Paravirt: what sort of paravirt API does a guest need
> (eg. xen, pvops, VMI, ...)?
> - The <domain type='?'> for this guest
> example: kqemu
> - The <domain><os><type machine='?'> for this guest (if applic.)
> example: pc
> - Suggested emulator and loader paths (5)
> - Driver-specific flags which libvirt clients would not be
> required to understand, but could be used to enhance
> libvirt clients.
> examples: uses kqemu, uses kvm (3,4,11)
>
> (Notes: (a) I have flattened qemu's nested arch/machine list, because I
> there is not a natural hierarchy. (b) The guest architectures list is a
> Cartesian product, although at the moment the worst case (qemu) would
> only have about 14 entries. An alternate way to do this is discussed at
> the end. (c) The host CPU model is already provided by virNodeGetInfo).
Currently this shows a Cartesian product of (arch,ostype,domaintype,flags)
but I think we should reduce it to merely (arch,ostype) and use a slightly
more heirarchical structure. The domaintype & flags only really add a
slight specialization of the basic (arch,ostype) info, so I think it is
worthwhile.
Also rather than having '<paravirt>xen</paravirt>' and '<fullyvirt/>'
I think we should just call it 'os_type' since this info is used to
populate the <os><type>..</type></os> field in the domain XML. A
second reason is that KVM is very likely to blur the boundaries between
paravirt & fullyvirt. ie, KVM is in its heart a fullyvirt system, but
it supports various paravirt extensions - a fullyvirt guest OS can
detect these paravirt extensions & make use of them on the fly. So
its better not to express a hard paravirt/fullyvirt split in the XML.
So I'm suggesting just <os_type>xen</os_type> and <os_type>hvm</os_type>
> Example: Xen
> ------------
>
> For Xen the primary source for capabilities are the files
> /sys/hypervisor/properties/capabilities and /proc/cpuinfo. A Xen driver
> might present the following description of its capabilities:
>
> <capabilities>
> <host>
> <cpu_flags>
> <cpu_flag> vmx </cpu_flag>
> <cpu_flag> pae </cpu_flag> <!-- etc -->
> </cpu_flags>
> </host>
>
> <guest_architectures>
> <guest_architecture>
> <model> x86_64 </model>
> <paravirt> xen </paravirt>
> <domain_type> xen </domain_type>
> <emulator> /usr/lib/xen/bin/qemu-dm </emulator>
> </guest_architecture>
>
> <guest_architecture>
> <model> i686 </model>
> <pae/>
> <paravirt> xen </paravirt>
> <domain_type> xen </domain_type>
> <emulator> /usr/lib/xen/bin/qemu-dm </emulator>
> </guest_architecture>
>
> <guest_architecture>
> <model> i686 </model>
> <fullvirt/>
> <domain_type> xen </domain_type>
> <loader> /usr/lib/xen/boot/hvmloader </loader>
> <emulator> /usr/lib/xen/bin/qemu-dm </emulator>
> </guest_architecture>
>
> <guest_architecture>
> <model> i686 </model>
> <pae/>
> <fullvirt/>
> <domain_type> xen </domain_type>
> <loader> /usr/lib/xen/boot/hvmloader </loader>
> <emulator> /usr/lib/xen/bin/qemu-dm </emulator>
> </guest_architecture>
>
> <guest_architecture>
> <model> x86_64 </model>
> <fullvirt/>
> <domain_type> xen </domain_type>
> <loader> /usr/lib/xen/boot/hvmloader </loader>
> <emulator> /usr/lib/xen/bin/qemu-dm </emulator>
> </guest_architecture>
> </guest_architectures>
> </capabilities>
This would look like:
<capabilities>
<host>
<cpu>
<arch>x86_64</arch>
<features>
<vmx/>
<pae/>
</features>
</cpu>
</host>
<!-- xen-3.0-x86_64p -->
<guest>
<os_type>xen</os_type>
<arch name="x86_64">
<wordsize>64</wordsize>
<domain type="xen"/>
</arch>
<features>
<pae/>
</features>
</guest>
<!-- xen-3.0-x86_32p -->
<guest>
<os_type>xen</os_type>
<arch name="i686">
<wordsize>32</wordsize>
<domain type="xen"/>
</arch>
<features>
<pae/>
</features>
</guest>
<!-- hvm-3.0-x86_64p -->
<guest>
<os_type>hvm</os_type>
<arch name="x86_64">
<machine >pc</machine>
<machine>isapc</machine>
<emulator>/usr/lib/xen/qemu-dm</emulator>
<loader>/usr/lib/xen/hvmloader</loader>
<domain type="xen"/>
</arch>
<features>
<pae/>
<nonpae/>
</features>
</guest>
<!-- hvm-3.0-x86_64p -->
<guest>
<os_type>hvm</os_type>
<arch name="i686">
<machine >pc</machine>
<machine>isapc</machine>
<emulator>/usr/lib/xen/qemu-dm</emulator>
<loader>/usr/lib/xen/hvmloader</loader>
<domain type="xen"/>
</arch>
<features>
<pae/>
<nonpae/>
</features>
</guest>
</capabilities>
Notice I have an expliciyt '<nonpae/>' flag, because PAE is really a
tri-state. A domain can support PAE, or none-PAE or both.
> Example: qemu + kqemu + kvm
> ---------------------------
>
> Qemu has by far the longest list of supported guest architectures. Out
> of the box it supports 10 distinct machine types and then you can add 4
> extra machine types if the kernel can do kqemu and kvm, making 14 in
> all. Below I have abbreviated this list for clarity.
>
> <capabilities>
> <host>
> <cpu_flags>
> <cpu_flag> vmx </cpu_flag>
> <cpu_flag> pae </cpu_flag> <!-- etc -->
> </cpu_flags>
> </host>
>
> <guest_architectures>
> <guest_architecture>
> <model> sparc </model>
> <machine> sun4m </machine>
> <fullvirt/>
> <domain_type> qemu </domain_type>
> <machine_type> sun4m </machine_type>
> <emulator> /usr/bin/qemu-system-sparc </emulator>
> </guest_architecture>
>
> <guest_architecture>
> <model> i686 </model>
> <machine> pc </machine>
> <fullvirt/>
> <domain_type> qemu </domain_type>
> <machine_type> pc </machine_type>
> <emulator> /usr/bin/qemu </emulator>
> </guest_architecture>
>
> <guest_architecture>
> <model> x86_64 </model>
> <machine> pc </machine>
> <fullvirt/>
> <domain_type> kqemu </domain_type>
> <machine_type> pc </machine_type>
> <emulator> /usr/bin/qemu </emulator>
> <qemu_uses_kqemu />
> </guest_architecture>
>
> <guest_architecture>
> <model> x86_64 </model>
> <machine> pc </machine>
> <fullvirt/>
> <domain_type> kvm </domain_type>
> <machine_type> pc </machine_type>
> <emulator> /usr/bin/qemu-kvm </emulator>
> <qemu_uses_kvm />
> </guest_architecture>
> </guest_architecture>
> </capabilities>
<capabilities>
<host>
<cpu>
<arch>x86_64</arch>
<features>
<vmx/>
<pae/>
</features>
</cpu>
</host>
<guest>
<os_type>hvm</os_type>
<arch name="x86_64">
<wordsize>64</wordsize>
<machine >pc</machine>
<machine>isapc</machine>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<domain type="qemu"/>
<domain type="kqemu"/>
<domain type="kvm">
<emulator>/usr/bin/qemu-kvm</emulator>
</domain>
</arch>
<features>
<pae/>
<nonpae/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name="i686">
<wordsize>32</wordsize>
<machine >pc</machine>
<machine>isapc</machine>
<emulator>/usr/bin/qemu</emulator>
<domain type="qemu"/>
</arch>
<features>
<nonpae/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name="sparc">
<wordsize>32</wordsize>
<machine >sun4m</machine>
<emulator>/usr/bin/qemu-system-sparc</emulator>
<domain type="qemu"/>
</arch>
<features>
<pae/>
<nonpae/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name="ppc">
<wordsize>32</wordsize>
<machine>prep</machine>
<machine>g3bw</machine>
<machine>mac99</machine>
<emulator>/usr/bin/qemu-system-ppc</emulator>
<domain type="qemu"/>
</arch>
<features>
<pae/>
<nonpae/>
</features>
</guest>
</capabilities>
Notice in this example, that the <domain type='kvm'> block inside the
the <arch> can override / specialize arch data. eg we provide an
alternate <emulator> block for KVM.
Als notice mutliple <machine> elements - the first is taken to be the
implicit default machine. Alternatively we could add an explicit
default="true" attribute.
So in summary, with Xen this results in N * <guest> blocks where N equals
the number of entries in /sys/hypervisor/properties/capabilities, and
with QEMU N == number of QEMU architectures (ie 7).
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 -=|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
