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 -=|