libvirt/docs/schemas/domain.rng

2377 lines
61 KiB
Plaintext
Raw Normal View History

<?xml version="1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<!-- We handle only document defining a domain -->
<start>
<ref name="domain"/>
</start>
<include href='storageencryption.rng'/>
<!--
description element, maybe placed anywhere under the root
-->
<define name="description">
<element name="description">
<text/>
</element>
</define>
<!--
We handle only document defining a domain
-->
<define name="domain">
<element name="domain">
<ref name="hvs"/>
<ref name="ids"/>
<interleave>
<optional>
<ref name="description"/>
</optional>
XML schema for CPU flags XML schema for CPU flags Firstly, CPU topology and model with optional features have to be advertised in host capabilities: <host> <cpu> <arch>ARCHITECTURE</arch> <features> <!-- old-style features are here --> </features> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature name="NAME"/> </cpu> ... </host> Secondly, drivers which support detailed CPU specification have to advertise it in guest capabilities: <guest> ... <features> <cpuselection/> </features> </guest> And finally, CPU may be configured in domain XML configuration: <domain> ... <cpu match="MATCH"> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature policy="POLICY" name="NAME"/> </cpu> </domain> Where MATCH can be one of: - 'minimum' specified CPU is the minimum requested CPU - 'exact' disable all additional features provided by host CPU - 'strict' fail if host CPU doesn't exactly match POLICY can be one of: - 'force' turn on the feature, even if host doesn't have it - 'require' fail if host doesn't have the feature - 'optional' match host - 'disable' turn off the feature, even if host has it - 'forbid' fail if host has the feature 'force' and 'disable' policies turn on/off the feature regardless of its availability on host. 'force' is unlikely to be used but its there for completeness since Xen and VMWare allow it. 'require' and 'forbid' policies prevent a guest from being started on a host which doesn't/does have the feature. 'forbid' is for cases where you disable the feature but a guest may still try to access it anyway and you don't want it to succeed. 'optional' policy sets the feature according to its availability on host. When a guest is booted on a host that has the feature and then migrated to another host, the policy changes to 'require' as we can't take the feature away from a running guest. Default policy for features provided by host CPU but not specified in domain configuration is set using match attribute of cpu tag. If 'minimum' match is requested, additional features will be treated as if they were specified with 'optional' policy. 'exact' match implies 'disable' policy and 'strict' match stands for 'forbid' policy. * docs/schemas/capability.rng docs/schemas/domain.rng: extend the RelaxNG schemas to add CPU flags support
2009-12-18 13:37:09 +00:00
<optional>
<ref name="cpu"/>
</optional>
<optional>
<ref name="sysinfo"/>
</optional>
<ref name="os"/>
<ref name="clock"/>
<ref name="resources"/>
<ref name="features"/>
<ref name="termination"/>
<optional>
<ref name="devices"/>
</optional>
<optional>
<ref name="seclabel"/>
</optional>
<optional>
<ref name='qemucmdline'/>
</optional>
</interleave>
2008-07-08 12:05:13 +00:00
</element>
</define>
<define name="seclabel">
<element name="seclabel">
<attribute name="model">
<text/>
</attribute>
<attribute name="type">
<choice>
<value>dynamic</value>
<value>static</value>
</choice>
</attribute>
<element name="label">
<text/>
</element>
</element>
</define>
<define name="hvs">
<attribute name="type">
2008-07-08 12:05:13 +00:00
<choice>
<value>xen</value>
<value>kvm</value>
<value>kqemu</value>
<value>qemu</value>
<value>lxc</value>
<value>openvz</value>
<value>test</value>
2008-07-08 12:05:13 +00:00
</choice>
</attribute>
</define>
<define name="os">
2008-07-08 12:05:13 +00:00
<choice>
<ref name="osxen"/>
<ref name="oshvm"/>
<ref name="osexe"/>
2008-07-08 12:05:13 +00:00
</choice>
</define>
<define name="osxen">
2008-07-08 12:05:13 +00:00
<choice>
<group>
<optional>
<ref name="bootloader"/>
</optional>
<element name="os">
<ref name="ostypexen"/>
<ref name="osbootkernel"/>
</element>
2008-07-08 12:05:13 +00:00
</group>
<group>
<ref name="bootloader"/>
<optional>
<element name="os">
<ref name="ostypexen"/>
<optional>
<ref name="osbootkernel"/>
</optional>
</element>
</optional>
2008-07-08 12:05:13 +00:00
</group>
</choice>
</define>
<define name="oshvm">
<element name="os">
<ref name="ostypehvm"/>
<interleave>
<optional>
<element name="loader">
<ref name="absFilePath"/>
</element>
</optional>
<choice>
<ref name="osbootkernel"/>
<zeroOrMore>
<ref name="osbootdev"/>
</zeroOrMore>
</choice>
<optional>
<element name="bootmenu">
<attribute name="enable">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</element>
</optional>
<optional>
<ref name="smbios"/>
</optional>
</interleave>
2008-07-08 12:05:13 +00:00
</element>
</define>
<define name="ostypexen">
<element name="type">
2008-07-08 12:05:13 +00:00
<optional>
<attribute name="arch">
<choice>
<value>i686</value>
<value>x86_64</value>
<value>ia64</value>
</choice>
</attribute>
2008-07-08 12:05:13 +00:00
</optional>
<optional>
<attribute name="machine">
<choice>
<value>xenpv</value>
<value>xenner</value>
</choice>
</attribute>
2008-07-08 12:05:13 +00:00
</optional>
<choice>
<value>xen</value>
<value>linux</value>
2008-07-08 12:05:13 +00:00
</choice>
</element>
</define>
<define name="ostypehvm">
<element name="type">
2008-07-08 12:05:13 +00:00
<optional>
<choice>
<ref name="hvmx86"/>
<ref name="hvmmips"/>
<ref name="hvmsparc"/>
<ref name="hvmppc"/>
</choice>
2008-07-08 12:05:13 +00:00
</optional>
<value>hvm</value>
</element>
</define>
<define name="hvmx86">
<group>
<optional>
<attribute name="arch">
<choice>
<value>i686</value>
<value>x86_64</value>
</choice>
</attribute>
</optional>
<optional>
<attribute name="machine">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\.\-]+</param>
</data>
</attribute>
</optional>
</group>
</define>
<define name="hvmmips">
<group>
<optional>
<attribute name="arch">
<value>mips</value>
</attribute>
</optional>
<optional>
<attribute name="machine">
<value>mips</value>
</attribute>
</optional>
</group>
</define>
<define name="hvmsparc">
<group>
<optional>
<attribute name="arch">
<value>sparc</value>
</attribute>
</optional>
<optional>
<attribute name="machine">
<value>sun4m</value>
</attribute>
</optional>
</group>
</define>
<define name="hvmppc">
<group>
<optional>
<attribute name="arch">
<value>ppc</value>
</attribute>
</optional>
<optional>
<attribute name="machine">
<choice>
<value>g3beige</value>
<value>mac99</value>
<value>prep</value>
</choice>
</attribute>
</optional>
</group>
</define>
<define name="osexe">
<element name="os">
<element name="type">
<value>exe</value>
</element>
<interleave>
<optional>
<element name="init">
<ref name="absFilePath"/>
</element>
</optional>
</interleave>
</element>
</define>
<!--
The Identifiers can be:
- an optional id attribute with a number on the domain element
- a mandatory name
- an optional uuid
-->
<define name="ids">
<optional>
<attribute name="id">
<ref name="unsignedInt"/>
</attribute>
</optional>
<interleave>
<element name="name">
<ref name="domainName"/>
</element>
<optional>
<element name="uuid">
<ref name="UUID"/>
</element>
</optional>
</interleave>
</define>
<!--
Resources usage defines the amount of memory (maximum and possibly
current usage) and number of virtual CPUs used by that domain.
We can't check here the rule that currentMemory <= memory
-->
<define name="resources">
<interleave>
<element name="memory">
<ref name="memoryKB"/>
</element>
<optional>
<element name="currentMemory">
<ref name="memoryKB"/>
</element>
</optional>
<optional>
<element name="memoryBacking">
<optional>
<element name="hugepages">
<empty/>
</element>
</optional>
</element>
</optional>
<!-- The Blkio cgroup related tunables would go in the blkiotune -->
<optional>
<element name="blkiotune">
<!-- I/O weight the VM can use -->
<optional>
<element name="weight">
<ref name="weight"/>
</element>
</optional>
</element>
</optional>
<!-- All the memory/swap related tunables would go in the memtune -->
<optional>
2010-10-12 14:12:08 +00:00
<element name="memtune">
<!-- Maximum memory the VM can use -->
<optional>
<element name="hard_limit">
<ref name="memoryKB"/>
</element>
</optional>
<!-- Minimum memory ascertained for the VM during contention -->
<optional>
<element name="soft_limit">
<ref name="memoryKB"/>
</element>
</optional>
<!-- Minimum amount of memory required to start the VM -->
<optional>
<element name="min_guarantee">
<ref name="memoryKB"/>
</element>
</optional>
<!-- Maximum swap area the VM can use -->
<optional>
<element name="swap_hard_limit">
<ref name="memoryKB"/>
</element>
</optional>
</element>
</optional>
<optional>
<element name="vcpu">
2008-07-08 12:05:13 +00:00
<optional>
<attribute name="cpuset">
<ref name="cpuset"/>
</attribute>
2008-07-08 12:05:13 +00:00
</optional>
<optional>
<attribute name="current">
<ref name="countCPU"/>
</attribute>
</optional>
<ref name="countCPU"/>
</element>
</optional>
</interleave>
</define>
<define name="clock">
2008-07-08 12:05:13 +00:00
<optional>
<element name="clock">
<choice>
<attribute name="offset">
2008-07-08 12:05:13 +00:00
<value>localtime</value>
</attribute>
<attribute name="offset">
2008-07-08 12:05:13 +00:00
<value>utc</value>
</attribute>
<group>
<attribute name="offset">
<value>timezone</value>
</attribute>
<optional>
<attribute name="timezone">
<ref name="timeZone"/>
</attribute>
</optional>
</group>
<group>
<attribute name="offset">
<value>variable</value>
</attribute>
<optional>
<attribute name="adjustment">
<ref name="timeDelta"/>
</attribute>
</optional>
</group>
</choice>
<zeroOrMore>
<ref name="timer"/>
</zeroOrMore>
2008-07-08 12:05:13 +00:00
</element>
</optional>
</define>
<define name="timer">
<element name="timer">
<attribute name="name">
<choice>
<value>platform</value>
<value>pit</value>
<value>rtc</value>
<value>hpet</value>
<value>tsc</value>
</choice>
</attribute>
<optional>
<attribute name="track">
<choice>
<value>boot</value>
<value>guest</value>
<value>wall</value>
</choice>
</attribute>
</optional>
<optional>
<attribute name="tickpolicy">
<choice>
<value>delay</value>
<value>catchup</value>
<value>merge</value>
<value>discard</value>
</choice>
</attribute>
</optional>
<optional>
<ref name="catchup"/>
</optional>
<optional>
<attribute name="frequency">
<ref name="unsignedInt"/>
</attribute>
</optional>
<optional>
<attribute name="mode">
<choice>
<value>auto</value>
<value>native</value>
<value>emulate</value>
<value>paravirt</value>
<value>smpsafe</value>
</choice>
</attribute>
</optional>
<optional>
<attribute name="present">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
<empty/>
</element>
</define>
<define name="catchup">
<element name="catchup">
<optional>
<attribute name="threshold">
<ref name="unsignedInt"/>
</attribute>
<attribute name="slew">
<ref name="unsignedInt"/>
</attribute>
<attribute name="limit">
<ref name="unsignedInt"/>
</attribute>
</optional>
</element>
</define>
<!--
A bootloader may be used to extract the OS information instead of
defining the OS parameter in the instance. It points just to the
binary or script used to extract the data from the first disk device.
-->
<define name="bootloader">
2008-07-08 12:05:13 +00:00
<interleave>
<element name="bootloader">
<choice>
<ref name="absFilePath"/>
<empty/>
</choice>
2008-07-08 12:05:13 +00:00
</element>
<optional>
<element name="bootloader_args">
<text/>
</element>
2008-07-08 12:05:13 +00:00
</optional>
</interleave>
</define>
<define name="osbootkernel">
<interleave>
<element name="kernel">
<ref name="absFilePath"/>
</element>
<optional>
<element name="initrd">
<ref name="absFilePath"/>
</element>
</optional>
<optional>
<element name="root">
<ref name="absFilePath"/>
</element>
</optional>
<optional>
<element name="cmdline">
<text/>
</element>
</optional>
</interleave>
</define>
<define name="osbootdev">
<element name="boot">
<attribute name="dev">
2008-07-08 12:05:13 +00:00
<choice>
<value>hd</value>
<value>fd</value>
<value>cdrom</value>
<value>network</value>
</choice>
</attribute>
<empty/>
</element>
2008-07-08 12:05:13 +00:00
</define>
<define name="diskspec">
2008-07-08 12:05:13 +00:00
<optional>
<ref name="driver"/>
2008-07-08 12:05:13 +00:00
</optional>
<ref name="target"/>
<optional>
<ref name="deviceBoot"/>
</optional>
2008-07-08 12:05:13 +00:00
<optional>
<element name="readonly">
2008-07-08 12:05:13 +00:00
<empty/>
</element>
2008-07-08 12:05:13 +00:00
</optional>
<optional>
<element name="shareable">
2008-07-08 12:05:13 +00:00
<empty/>
</element>
</optional>
<optional>
<element name="serial">
<ref name="diskSerial"/>
</element>
</optional>
<optional>
<ref name="encryption"/>
</optional>
<optional>
<ref name="address"/>
</optional>
</define>
<!--
A disk description can be either of type file or block
The name of the attribute on the source element depends on the type
-->
<define name="disk">
<element name="disk">
<optional>
<attribute name="device">
<choice>
<value>floppy</value>
<value>disk</value>
<value>cdrom</value>
</choice>
</attribute>
</optional>
<choice>
<group>
<attribute name="type">
<value>file</value>
2008-07-08 12:05:13 +00:00
</attribute>
<interleave>
<optional>
<element name="source">
<attribute name="file">
<ref name="absFilePath"/>
</attribute>
<empty/>
</element>
</optional>
<ref name="diskspec"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>block</value>
</attribute>
<interleave>
<optional>
<element name="source">
<attribute name="dev">
<ref name="absFilePath"/>
</attribute>
<empty/>
</element>
</optional>
<ref name="diskspec"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>dir</value>
</attribute>
<interleave>
<optional>
<element name="source">
<attribute name="dir">
<ref name="absFilePath"/>
</attribute>
<empty/>
</element>
</optional>
<ref name="diskspec"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>network</value>
</attribute>
<interleave>
<optional>
<element name="source">
<attribute name="protocol">
<choice>
<value>nbd</value>
<value>rbd</value>
<value>sheepdog</value>
</choice>
</attribute>
<optional>
<attribute name="name"/>
</optional>
<zeroOrMore>
<element name="host">
<attribute name="name">
<ref name="hostName"/>
</attribute>
<attribute name="port">
<ref name="unsignedInt"/>
</attribute>
</element>
</zeroOrMore>
<empty/>
</element>
</optional>
<ref name="diskspec"/>
</interleave>
</group>
<ref name="diskspec"/>
</choice>
</element>
</define>
<define name="target">
<element name="target">
<attribute name="dev">
<ref name="deviceName"/>
</attribute>
2008-07-08 12:05:13 +00:00
<optional>
<attribute name="bus">
<choice>
<value>ide</value>
<value>fdc</value>
<value>scsi</value>
<value>virtio</value>
<value>xen</value>
<value>usb</value>
<value>uml</value>
</choice>
</attribute>
2008-07-08 12:05:13 +00:00
</optional>
</element>
</define>
<!--
Disk may use a special driver for access. Currently this is
only defined for Xen for tap/aio and file, but will certainly be
extended in the future, and libvirt doesn't look for specific values.
-->
<define name="driver">
<element name="driver">
2009-01-30 17:15:39 +00:00
<choice>
<group>
<ref name="driverFormat"/>
<optional>
<ref name="driverCache"/>
</optional>
</group>
<group>
<optional>
<ref name="driverFormat"/>
</optional>
<ref name="driverCache"/>
</group>
2009-01-30 17:15:39 +00:00
</choice>
<optional>
<ref name="driverErrorPolicy"/>
</optional>
<optional>
<ref name="driverIO"/>
</optional>
2008-07-08 12:05:13 +00:00
<empty/>
</element>
</define>
<define name="driverFormat">
<attribute name="name">
<ref name="genericName"/>
2009-01-30 17:15:39 +00:00
</attribute>
<optional>
<attribute name="type">
<ref name="genericName"/>
2009-01-30 17:15:39 +00:00
</attribute>
</optional>
</define>
<define name="driverCache">
<attribute name="cache">
2009-01-30 17:15:39 +00:00
<choice>
<value>none</value>
<value>writeback</value>
<value>writethrough</value>
2009-01-30 17:15:39 +00:00
</choice>
</attribute>
</define>
<define name="driverErrorPolicy">
<attribute name="error_policy">
<choice>
<value>stop</value>
<value>ignore</value>
<value>enospace</value>
</choice>
</attribute>
</define>
<define name="driverIO">
<attribute name="io">
<choice>
<value>threads</value>
<value>native</value>
</choice>
</attribute>
</define>
<define name="controller">
<element name="controller">
<choice>
<group>
<optional>
<attribute name="type">
<choice>
<value>fdc</value>
<value>ide</value>
<value>scsi</value>
<value>sata</value>
<value>ccid</value>
</choice>
</attribute>
</optional>
</group>
<!-- virtio-serial can have 2 additional attributes -->
<group>
<attribute name="type">
<value>virtio-serial</value>
</attribute>
<optional>
<attribute name="ports">
<ref name="unsignedInt"/>
</attribute>
</optional>
<optional>
<attribute name="vectors">
<ref name="unsignedInt"/>
</attribute>
</optional>
</group>
</choice>
<attribute name="index">
<ref name="unsignedInt"/>
</attribute>
<optional>
<attribute name="model">
<choice>
<value>auto</value>
<value>buslogic</value>
<value>lsilogic</value>
<value>lsisas1068</value>
<value>vmpvscsi</value>
</choice>
</attribute>
</optional>
<optional>
<ref name="address"/>
</optional>
</element>
</define>
<define name="filesystem">
<element name="filesystem">
<choice>
<group>
<attribute name="type">
<value>file</value>
</attribute>
<interleave>
<element name="source">
<attribute name="file">
<ref name="absFilePath"/>
</attribute>
<empty/>
</element>
<ref name="filesystemtgt"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>block</value>
</attribute>
<interleave>
<element name="source">
<attribute name="dev">
<ref name="absFilePath"/>
</attribute>
<empty/>
</element>
<ref name="filesystemtgt"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>mount</value>
</attribute>
<interleave>
<element name="source">
<attribute name="dir">
<ref name="absFilePath"/>
</attribute>
<empty/>
</element>
<ref name="filesystemtgt"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>template</value>
</attribute>
<interleave>
<element name="source">
<attribute name="name">
<ref name="genericName"/>
</attribute>
<empty/>
</element>
<ref name="filesystemtgt"/>
</interleave>
</group>
</choice>
<optional>
<ref name="address"/>
<attribute name="accessmode">
<choice>
<value>passthrough</value>
<value>mapped</value>
<value>squash</value>
</choice>
</attribute>
</optional>
</element>
</define>
<define name="filesystemtgt">
<element name="target">
<attribute name="dir">
<ref name="absDirPath"/>
</attribute>
<empty/>
</element>
</define>
<!--
An interface description can either be of type bridge in which case
it will use a bridging source, or of type ethernet which uses a device
source and a device target instead. They both share a set of interface
2008-07-08 12:05:13 +00:00
options. FIXME
-->
<define name="interface">
<element name="interface">
<choice>
<group>
<attribute name="type">
<value>bridge</value>
</attribute>
<interleave>
2008-07-08 12:05:13 +00:00
<optional>
<element name="source">
<attribute name="bridge">
<ref name="deviceName"/>
</attribute>
<empty/>
</element>
2008-07-08 12:05:13 +00:00
</optional>
<ref name="interface-options"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>ethernet</value>
</attribute>
<interleave>
2008-07-08 12:05:13 +00:00
<optional>
<element name="source">
<attribute name="dev">
<ref name="deviceName"/>
</attribute>
<empty/>
</element>
2008-07-08 12:05:13 +00:00
</optional>
<ref name="interface-options"/>
</interleave>
</group>
2008-07-08 12:05:13 +00:00
<group>
<attribute name="type">
2008-07-08 12:05:13 +00:00
<value>network</value>
</attribute>
<interleave>
<element name="source">
<attribute name="network">
<ref name="deviceName"/>
</attribute>
<empty/>
</element>
<ref name="interface-options"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>direct</value>
</attribute>
<interleave>
<element name="source">
<attribute name="dev">
<ref name="deviceName"/>
</attribute>
<optional>
<attribute name="mode">
<ref name="bridgeMode"/>
</attribute>
</optional>
<empty/>
</element>
vepa: parsing for 802.1Qb{g|h} XML This patch parses the following two XML descriptions, one for 802.1Qbg and one for 802.1Qbh, and stores the data internally. The actual triggering of the switch setup protocol has not been implemented here but the relevant code to do that should go into the functions associatePortProfileId() and disassociatePortProfileId(). <interface type='direct'> <source dev='eth0.100' mode='vepa'/> <model type='virtio'/> <virtualport type='802.1Qbg'> <parameters managerid='12' typeid='0x123456' typeidversion='1' instanceid='fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f'/> </virtualport> <filterref filter='clean-traffic'/> </interface> <interface type='direct'> <source dev='eth0.100' mode='vepa'/> <model type='virtio'/> <virtualport type='802.1Qbh'> <parameters profileid='my_profile'/> </virtualport> </interface> I'd suggest to use this patch as a base for triggering the setup protocol with the 802.1Qb{g|h} switch. Several rounds of changes were made to this patch. The following is a list of these changes. - Renamed structure virVirtualPortProfileDef to virVirtualPortProfileParams as per Daniel Berrange's request - Addressing Daniel Berrange's comments: - removing macvtap.h's dependency on domain_conf.h by moving the virVirtualPortProfileDef structure into macvtap.h and not passing virtDomainNetDefPtr to any functions in macvtap.c - Addressed most of Chris Wright's comments: - indicating error in case virtualport XML node cannot be parsed properly - parsing hex and decimal numbers using virStrToLong_ui() with parameter '0' for base - tgifname (target interface name) variable wasn't necessary to pass to openMacvtapTap function anymore - assigning the virtual port data structure to the virDomainNetDef only if it was previously parsed - make sure that the error code returned by openMacvtapTap() is a negative n in case the associatePortProfileId() function failed. - renaming vsi in the XML to virtualport - replace all occurrences of vsi in the source as well - removing mode and MAC address parameters from the functions that will communicate with the hareware diretctly or indirectly - moving the associate and disassociate functions to the end of the file for subsequent patches to easier make them generally available for export - passing the macvtap interface name rather than the link device since this otherwise gives funny side effects when using netlink messages where IFLA_IFNAME and IFLA_ADDRESS are specified and the link dev all of a sudden gets the MAC address of the macvtap interface. - Removing rc = -1 error indications in the case of 802.1Qbg|h setup in case we wanted to use hook scripts for the setup and so the setup doesn't fail here. - if instance ID UUID is not supplied it will automatically be generated - adapted schema to make instance ID UUID optional - added test case - parser and XML generator have been separated into their own functions so they can be re-used elsewhere (passthrough case for example) - Adapted XML parser and generator support the above shown type (802.1Qbg, 802.1Qbh). - Adapted schema to above XML - Adapted test XML to above XML - Passing through the VM's UUID which seems to be necessary for 802.1Qbh -- sorry no host UUID - adding virtual function ID to association function, in case it's necessary to use (for SR-IOV)
2010-05-25 21:37:00 +00:00
<optional>
<ref name="virtualPortProfile"/>
</optional>
<ref name="interface-options"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>user</value>
</attribute>
<interleave>
<ref name="interface-options"/>
</interleave>
</group>
<group>
<attribute name="type">
<value>internal</value>
</attribute>
<interleave>
<element name="source">
<attribute name="name">
<ref name="deviceName"/>
</attribute>
<empty/>
</element>
<ref name="interface-options"/>
</interleave>
</group>
</choice>
</element>
</define>
<!--
The interface options possible are:
- the MAC address
- the IP address bound to the interface
- the name of the script used to set up the binding
- the target device used
- boot order
-->
<define name="interface-options">
2008-07-08 12:05:13 +00:00
<interleave>
<optional>
<element name="target">
<attribute name="dev">
<ref name="deviceName"/>
</attribute>
<empty/>
</element>
2008-07-08 12:05:13 +00:00
</optional>
<optional>
<element name="mac">
<attribute name="address">
<ref name="addrMAC"/>
</attribute>
<empty/>
</element>
2008-07-08 12:05:13 +00:00
</optional>
<optional>
<element name="ip">
<attribute name="address">
<ref name="addrIP"/>
</attribute>
<empty/>
</element>
2008-07-08 12:05:13 +00:00
</optional>
<optional>
<element name="script">
<attribute name="path">
<ref name="filePath"/>
</attribute>
<empty/>
</element>
2008-07-08 12:05:13 +00:00
</optional>
<optional>
<element name="model">
<attribute name="type"/>
<empty/>
</element>
2008-07-08 12:05:13 +00:00
</optional>
<optional>
<element name="driver">
<optional>
<attribute name="name">
<choice>
<value>qemu</value>
<value>vhost</value>
</choice>
</attribute>
</optional>
Add txmode attribute to interface XML for virtio backend This is in response to: https://bugzilla.redhat.com/show_bug.cgi?id=629662 Explanation qemu's virtio-net-pci driver allows setting the algorithm used for tx packets to either "bh" or "timer". This is done by adding ",tx=bh" or ",tx=timer" to the "-device virtio-net-pci" commandline option. 'bh' stands for 'bottom half'; when this is set, packet tx is all done in an iothread in the bottom half of the driver. (In libvirt, this option is called the more descriptive "iothread".) 'timer' means that tx work is done in qemu, and if there is more tx data than can be sent at the present time, a timer is set before qemu moves on to do other things; when the timer fires, another attempt is made to send more data. (libvirt retains the name "timer" for this option.) The resulting difference, according to the qemu developer who added the option is: bh makes tx more asynchronous and reduces latency, but potentially causes more processor bandwidth contention since the cpu doing the tx isn't necessarily the cpu where the guest generated the packets. Solution This patch provides a libvirt domain xml knob to change the option on the qemu commandline, by adding a new attribute "txmode" to the <driver> element that can be placed inside any <interface> element in a domain definition. It's use would be something like this: <interface ...> ... <model type='virtio'/> <driver txmode='iothread'/> ... </interface> I chose to put this setting as an attribute to <driver> rather than as a sub-element to <tune> because it is specific to the virtio-net driver, not something that is generally usable by all network drivers. (note that this is the same placement as the "driver name=..." attribute used to choose kernel vs. userland backend for the virtio-net driver.) Actually adding the tx=xxx option to the qemu commandline is only done if the version of qemu being used advertises it in the output of qemu -device virtio-net-pci,? If a particular txmode is requested in the XML, and the option isn't listed in that help output, an UNSUPPORTED_CONFIG error is logged, and the domain fails to start.
2011-02-03 20:20:01 +00:00
<optional>
<attribute name="txmode">
<choice>
<value>iothread</value>
<value>timer</value>
</choice>
</attribute>
</optional>
<empty/>
</element>
</optional>
<optional>
<ref name="address"/>
</optional>
<optional>
<element name="filterref">
<ref name="filterref-node-attributes"/>
</element>
</optional>
<optional>
<element name="tune">
<optional>
<!-- size of send buffer for network tap devices -->
<element name="sndbuf">
<ref name="unsignedInt"/>
</element>
</optional>
</element>
</optional>
<optional>
<ref name="deviceBoot"/>
</optional>
2008-07-08 12:05:13 +00:00
</interleave>
</define>
vepa: parsing for 802.1Qb{g|h} XML This patch parses the following two XML descriptions, one for 802.1Qbg and one for 802.1Qbh, and stores the data internally. The actual triggering of the switch setup protocol has not been implemented here but the relevant code to do that should go into the functions associatePortProfileId() and disassociatePortProfileId(). <interface type='direct'> <source dev='eth0.100' mode='vepa'/> <model type='virtio'/> <virtualport type='802.1Qbg'> <parameters managerid='12' typeid='0x123456' typeidversion='1' instanceid='fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f'/> </virtualport> <filterref filter='clean-traffic'/> </interface> <interface type='direct'> <source dev='eth0.100' mode='vepa'/> <model type='virtio'/> <virtualport type='802.1Qbh'> <parameters profileid='my_profile'/> </virtualport> </interface> I'd suggest to use this patch as a base for triggering the setup protocol with the 802.1Qb{g|h} switch. Several rounds of changes were made to this patch. The following is a list of these changes. - Renamed structure virVirtualPortProfileDef to virVirtualPortProfileParams as per Daniel Berrange's request - Addressing Daniel Berrange's comments: - removing macvtap.h's dependency on domain_conf.h by moving the virVirtualPortProfileDef structure into macvtap.h and not passing virtDomainNetDefPtr to any functions in macvtap.c - Addressed most of Chris Wright's comments: - indicating error in case virtualport XML node cannot be parsed properly - parsing hex and decimal numbers using virStrToLong_ui() with parameter '0' for base - tgifname (target interface name) variable wasn't necessary to pass to openMacvtapTap function anymore - assigning the virtual port data structure to the virDomainNetDef only if it was previously parsed - make sure that the error code returned by openMacvtapTap() is a negative n in case the associatePortProfileId() function failed. - renaming vsi in the XML to virtualport - replace all occurrences of vsi in the source as well - removing mode and MAC address parameters from the functions that will communicate with the hareware diretctly or indirectly - moving the associate and disassociate functions to the end of the file for subsequent patches to easier make them generally available for export - passing the macvtap interface name rather than the link device since this otherwise gives funny side effects when using netlink messages where IFLA_IFNAME and IFLA_ADDRESS are specified and the link dev all of a sudden gets the MAC address of the macvtap interface. - Removing rc = -1 error indications in the case of 802.1Qbg|h setup in case we wanted to use hook scripts for the setup and so the setup doesn't fail here. - if instance ID UUID is not supplied it will automatically be generated - adapted schema to make instance ID UUID optional - added test case - parser and XML generator have been separated into their own functions so they can be re-used elsewhere (passthrough case for example) - Adapted XML parser and generator support the above shown type (802.1Qbg, 802.1Qbh). - Adapted schema to above XML - Adapted test XML to above XML - Passing through the VM's UUID which seems to be necessary for 802.1Qbh -- sorry no host UUID - adding virtual function ID to association function, in case it's necessary to use (for SR-IOV)
2010-05-25 21:37:00 +00:00
<define name="virtualPortProfile">
<choice>
<group>
<element name="virtualport">
<attribute name="type">
<value>802.1Qbg</value>
</attribute>
<element name="parameters">
<attribute name="managerid">
<ref name="uint8range"/>
</attribute>
<attribute name="typeid">
<ref name="uint24range"/>
</attribute>
<attribute name="typeidversion">
<ref name="uint8range"/>
</attribute>
<optional>
<attribute name="instanceid">
<ref name="UUID"/>
</attribute>
</optional>
</element>
</element>
</group>
<group>
<element name="virtualport">
<attribute name="type">
<value>802.1Qbh</value>
</attribute>
<element name="parameters">
<attribute name="profileid">
<ref name="virtualPortProfileID"/>
</attribute>
</element>
</element>
</group>
</choice>
</define>
<!--
2008-07-08 12:05:13 +00:00
An emulator description is just a path to the binary used for the task
-->
<define name="emulator">
<element name="emulator">
<ref name="absFilePath"/>
</element>
</define>
<!--
A graphic description, currently in Xen only 2 types are supported:
- sdl with optional display, xauth and fullscreen
- vnc with a required port and optional listen IP address, password
2008-07-08 12:05:13 +00:00
and keymap
-->
<define name="graphic">
<element name="graphics">
<choice>
<group>
<attribute name="type">
<value>sdl</value>
</attribute>
<optional>
<attribute name="display">
<text/>
</attribute>
</optional>
2008-07-08 12:05:13 +00:00
<optional>
<attribute name="xauth">
2008-07-08 12:05:13 +00:00
<text/>
</attribute>
</optional>
<optional>
<attribute name="fullscreen">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
</group>
<group>
<attribute name="type">
<value>vnc</value>
</attribute>
<choice>
<group>
<optional>
<attribute name="port">
<ref name="PortNumber"/>
</attribute>
</optional>
<optional>
<attribute name="autoport">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
<optional>
<attribute name="listen">
<ref name="addrIP"/>
</attribute>
</optional>
</group>
<group>
<optional>
<attribute name="socket">
<ref name="absFilePath"/>
</attribute>
</optional>
</group>
</choice>
<optional>
<attribute name="passwd">
<text/>
</attribute>
</optional>
<optional>
<attribute name="keymap">
<text/>
</attribute>
</optional>
</group>
<group>
<attribute name="type">
<value>spice</value>
</attribute>
<optional>
<attribute name="port">
<ref name="PortNumber"/>
</attribute>
</optional>
<optional>
<attribute name="tlsPort">
<ref name="PortNumber"/>
</attribute>
</optional>
<optional>
<attribute name="autoport">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
<optional>
<attribute name="listen">
<ref name="addrIP"/>
</attribute>
</optional>
<optional>
<attribute name="passwd">
<text/>
</attribute>
</optional>
<optional>
<attribute name="keymap">
<text/>
</attribute>
</optional>
<zeroOrMore>
<element name="channel">
<attribute name="name">
<choice>
<value>main</value>
<value>display</value>
<value>inputs</value>
<value>cursor</value>
<value>playback</value>
<value>record</value>
<value>smartcard</value>
</choice>
</attribute>
<attribute name="mode">
<choice>
<value>any</value>
<value>secure</value>
<value>insecure</value>
</choice>
</attribute>
<empty/>
</element>
</zeroOrMore>
</group>
<group>
<attribute name="type">
<value>rdp</value>
</attribute>
<optional>
<attribute name="port">
<ref name="PortNumber"/>
</attribute>
</optional>
<optional>
<attribute name="autoport">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
<optional>
<attribute name="replaceUser">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
<optional>
<attribute name="multiUser">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
<optional>
<attribute name="listen">
<ref name="addrIP"/>
</attribute>
</optional>
</group>
<group>
<attribute name="type">
<value>desktop</value>
</attribute>
<optional>
<attribute name="display">
<text/>
</attribute>
</optional>
<optional>
<attribute name="fullscreen">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
</group>
</choice>
</element>
</define>
<!--
A video adapter description, allowing configuration of device
model, number of virtual heads, and video ram size
-->
<define name="video">
<element name="video">
<optional>
<element name="model">
<attribute name="type">
<choice>
<value>vga</value>
<value>cirrus</value>
<value>vmvga</value>
<value>xen</value>
<value>vbox</value>
<value>qxl</value>
</choice>
</attribute>
<optional>
<attribute name="vram">
<ref name="unsignedInt"/>
</attribute>
</optional>
<optional>
<attribute name="heads">
<ref name="unsignedInt"/>
</attribute>
</optional>
<optional>
<element name="acceleration">
<optional>
<attribute name="accel3d">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
<optional>
<attribute name="accel2d">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
</element>
</optional>
</element>
</optional>
<optional>
<ref name="address"/>
</optional>
</element>
</define>
<!--
When a domain terminates multiple policies can be applied depending
on how it ended:
-->
<define name="termination">
<interleave>
<optional>
<element name="on_reboot">
<ref name="offOptions"/>
</element>
</optional>
<optional>
<element name="on_poweroff">
<ref name="offOptions"/>
</element>
</optional>
<optional>
<element name="on_crash">
<ref name="crashOptions"/>
</element>
</optional>
</interleave>
</define>
<!--
Options when a domain terminates:
destroy: The domain is cleaned up
restart: A new domain is started in place of the old one
preserve: The domain will remain in memory until it is destroyed manually
rename-restart: a variant of the previous one but where the old domain is
renamed before being saved to allow a restart
-->
<define name="offOptions">
<choice>
<value>destroy</value>
<value>restart</value>
<value>preserve</value>
<value>rename-restart</value>
</choice>
</define>
<!--
Options when a domain crashes:
destroy: The domain is cleaned up
restart: A new domain is started in place of the old one
preserve: The domain will remain in memory until it is destroyed manually
rename-restart: a variant of the previous one but where the old domain is
renamed before being saved to allow a restart
coredump-destroy: The crashed domain's core will be dumped, and then the
domain will be terminated completely and all resources
released
coredump-restart: The crashed domain's core will be dumped, and then the
domain will be restarted with the same configuration
-->
<define name="crashOptions">
<choice>
<value>destroy</value>
<value>restart</value>
<value>preserve</value>
<value>rename-restart</value>
<value>coredump-destroy</value>
<value>coredump-restart</value>
</choice>
</define>
2008-07-08 12:05:13 +00:00
<!--
Specific setup for a qemu emulated character device. Note: this
definition doesn't fully specify the constraints on this node.
-->
<define name="qemucdev">
<ref name="qemucdevSrcType"/>
<optional>
<attribute name="tty">
<ref name="absFilePath"/>
</attribute>
</optional>
<interleave>
<ref name="qemucdevSrcDef"/>
<optional>
<ref name="qemucdevTgtDef"/>
</optional>
<optional>
<ref name="address"/>
</optional>
</interleave>
</define>
<define name="qemucdevConsoleTgtType">
<attribute name="type">
<choice>
<value>xen</value>
<value>serial</value>
<value>uml</value>
<value>virtio</value>
</choice>
</attribute>
</define>
<define name="qemucdevTgtDef">
<element name="target">
<interleave>
<optional>
<ref name="qemucdevConsoleTgtType"/>
</optional>
<optional>
<attribute name="port"/>
</optional>
</interleave>
</element>
</define>
<define name="qemucdevSrcType">
<attribute name="type">
2008-07-08 12:05:13 +00:00
<choice>
<value>dev</value>
<value>file</value>
<value>pipe</value>
<value>unix</value>
<value>tcp</value>
<value>udp</value>
<value>null</value>
<value>stdio</value>
<value>vc</value>
<value>pty</value>
<value>spicevmc</value>
2008-07-08 12:05:13 +00:00
</choice>
</attribute>
</define>
<define name="qemucdevSrcDef">
<zeroOrMore>
<element name="source">
<optional>
<attribute name="mode"/>
</optional>
<optional>
<attribute name="path"/>
</optional>
<optional>
<attribute name="host"/>
</optional>
<optional>
<attribute name="service"/>
</optional>
<optional>
<attribute name="wiremode"/>
</optional>
</element>
</zeroOrMore>
<optional>
<element name="protocol">
<optional>
<attribute name="type">
<choice>
<value>raw</value>
<value>telnet</value>
<value>telnets</value>
<value>tls</value>
</choice>
</attribute>
</optional>
</element>
</optional>
2008-07-08 12:05:13 +00:00
</define>
<!--
The description for a console
just a tty device
-->
<define name="console">
<element name="console">
2008-07-08 12:05:13 +00:00
<choice>
<group>
<optional>
<attribute name="tty">
<ref name="absFilePath"/>
2008-07-08 12:05:13 +00:00
</attribute>
</optional>
<empty/>
</group>
<choice>
<ref name="qemucdev"/>
</choice>
2008-07-08 12:05:13 +00:00
</choice>
</element>
</define>
<define name="sound">
<element name="sound">
<attribute name="model">
2008-07-08 12:05:13 +00:00
<choice>
<value>sb16</value>
<value>es1370</value>
<value>pcspk</value>
<value>ac97</value>
<value>ich6</value>
2008-07-08 12:05:13 +00:00
</choice>
</attribute>
<optional>
<ref name="address"/>
</optional>
</element>
</define>
<define name="watchdog">
<element name="watchdog">
<attribute name="model">
<choice>
<value>i6300esb</value>
<value>ib700</value>
</choice>
</attribute>
<optional>
<attribute name="action">
<choice>
<value>reset</value>
<value>shutdown</value>
<value>poweroff</value>
<value>pause</value>
<value>none</value>
<value>dump</value>
</choice>
</attribute>
</optional>
<optional>
<ref name="address"/>
</optional>
</element>
</define>
<define name="memballoon">
<element name="memballoon">
<attribute name="model">
<choice>
<value>virtio</value>
<value>xen</value>
<value>none</value>
</choice>
</attribute>
<optional>
<ref name="address"/>
</optional>
</element>
</define>
<define name="parallel">
<element name="parallel">
<ref name="qemucdev"/>
2008-07-08 12:05:13 +00:00
</element>
</define>
<define name="serial">
<element name="serial">
<ref name="qemucdev"/>
2008-07-08 12:05:13 +00:00
</element>
</define>
<define name="guestfwdTarget">
<element name="target">
<attribute name="type">
<value>guestfwd</value>
</attribute>
<attribute name="address"/>
<attribute name="port"/>
</element>
</define>
<define name="virtioTarget">
<element name="target">
<attribute name="type">
<value>virtio</value>
</attribute>
<optional>
<attribute name="name"/>
</optional>
</element>
</define>
<define name="channel">
<element name="channel">
<ref name="qemucdevSrcType"/>
<interleave>
<ref name="qemucdevSrcDef"/>
<choice>
<ref name="guestfwdTarget"/>
<ref name="virtioTarget"/>
</choice>
<optional>
<ref name="address"/>
</optional>
</interleave>
</element>
</define>
<define name="smartcard">
<element name="smartcard">
<choice>
<group>
<attribute name="mode">
<value>host</value>
</attribute>
<!-- might need to add optional database element here later -->
</group>
<group>
<attribute name="mode">
<value>host-certificates</value>
</attribute>
<ref name='certificate'/>
<ref name='certificate'/>
<ref name='certificate'/>
<optional>
<element name="database">
<ref name="absDirPath"/>
</element>
</optional>
</group>
<group>
<attribute name="mode">
<value>passthrough</value>
</attribute>
<ref name="qemucdevSrcType"/>
<interleave>
<ref name="qemucdevSrcDef"/>
<optional>
<ref name="qemucdevTgtDef"/>
</optional>
</interleave>
</group>
</choice>
<optional>
<ref name="address"/>
</optional>
</element>
</define>
<define name="certificate">
<element name="certificate">
<text/>
</element>
</define>
<define name="input">
<element name="input">
<attribute name="type">
2008-07-08 12:05:13 +00:00
<choice>
<value>tablet</value>
<value>mouse</value>
</choice>
</attribute>
<optional>
<attribute name="bus">
2008-07-08 12:05:13 +00:00
<choice>
<value>ps2</value>
<value>usb</value>
<value>xen</value>
</choice>
</attribute>
</optional>
<optional>
<ref name="address"/>
</optional>
</element>
</define>
<define name="hostdev">
<element name="hostdev">
<optional>
<attribute name="mode">
<choice>
<value>subsystem</value>
<value>capabilities</value>
</choice>
</attribute>
<attribute name="type">
<choice>
<value>usb</value>
<value>pci</value>
</choice>
</attribute>
<attribute name="managed">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
<group>
<element name="source">
<choice>
<group>
<ref name="usbproduct"/>
<optional>
<ref name="usbaddress"/>
</optional>
</group>
<ref name="usbaddress"/>
<element name="address">
<ref name="pciaddress"/>
</element>
</choice>
</element>
</group>
2011-02-03 12:06:21 +00:00
<optional>
<ref name="deviceBoot"/>
</optional>
<optional>
<ref name="address"/>
</optional>
</element>
</define>
<define name="usbproduct">
<element name="vendor">
<attribute name="id">
<ref name="usbId"/>
</attribute>
</element>
<element name="product">
<attribute name="id">
<ref name="usbId"/>
</attribute>
</element>
</define>
<define name="usbaddress">
<element name="address">
<attribute name="bus">
<ref name="usbAddr"/>
</attribute>
<attribute name="device">
<ref name="usbAddr"/>
</attribute>
</element>
</define>
<define name="pciaddress">
<optional>
<attribute name="domain">
<ref name="pciDomain"/>
</attribute>
</optional>
<attribute name="bus">
<ref name="pciBus"/>
</attribute>
<attribute name="slot">
<ref name="pciSlot"/>
</attribute>
<attribute name="function">
<ref name="pciFunc"/>
</attribute>
</define>
<define name="driveaddress">
<optional>
<attribute name="controller">
<ref name="driveController"/>
</attribute>
</optional>
<optional>
<attribute name="bus">
<ref name="driveBus"/>
</attribute>
</optional>
<attribute name="unit">
<ref name="driveUnit"/>
</attribute>
</define>
<define name="virtioserialaddress">
<attribute name="controller">
<ref name="driveController"/>
</attribute>
<optional>
<attribute name="bus">
<ref name="driveBus"/>
</attribute>
</optional>
<optional>
<attribute name="port">
<ref name="driveUnit"/>
</attribute>
</optional>
</define>
<define name="ccidaddress">
<attribute name="controller">
<ref name="driveController"/>
</attribute>
<optional>
<attribute name="slot">
<ref name="driveUnit"/>
</attribute>
</optional>
</define>
<!--
2008-07-08 12:05:13 +00:00
Devices attached to a domain.
Sub-elements such as <alias> are not documented here, as they
can only exist when generated for a live domain and are ignored
when defining a domain.
-->
<define name="devices">
<element name="devices">
<interleave>
<optional>
<ref name="emulator"/>
</optional>
<zeroOrMore>
<choice>
<ref name="disk"/>
<ref name="controller"/>
<ref name="filesystem"/>
<ref name="interface"/>
<ref name="input"/>
<ref name="sound"/>
<ref name="hostdev"/>
<ref name="graphic"/>
<ref name="video"/>
<ref name="console"/>
<ref name="parallel"/>
<ref name="serial"/>
<ref name="channel"/>
<ref name="smartcard"/>
</choice>
</zeroOrMore>
<optional>
<ref name="watchdog"/>
</optional>
<optional>
<ref name="memballoon"/>
</optional>
</interleave>
</element>
</define>
<!--
A set of optional features: PAE, APIC, ACPI, and HAP support
-->
<define name="features">
<optional>
<element name="features">
<interleave>
<optional>
<element name="pae">
<empty/>
</element>
</optional>
<optional>
<element name="apic">
<empty/>
</element>
</optional>
<optional>
<element name="acpi">
<empty/>
</element>
</optional>
<optional>
<element name="hap">
<empty/>
</element>
</optional>
</interleave>
</element>
</optional>
</define>
XML schema for CPU flags XML schema for CPU flags Firstly, CPU topology and model with optional features have to be advertised in host capabilities: <host> <cpu> <arch>ARCHITECTURE</arch> <features> <!-- old-style features are here --> </features> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature name="NAME"/> </cpu> ... </host> Secondly, drivers which support detailed CPU specification have to advertise it in guest capabilities: <guest> ... <features> <cpuselection/> </features> </guest> And finally, CPU may be configured in domain XML configuration: <domain> ... <cpu match="MATCH"> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature policy="POLICY" name="NAME"/> </cpu> </domain> Where MATCH can be one of: - 'minimum' specified CPU is the minimum requested CPU - 'exact' disable all additional features provided by host CPU - 'strict' fail if host CPU doesn't exactly match POLICY can be one of: - 'force' turn on the feature, even if host doesn't have it - 'require' fail if host doesn't have the feature - 'optional' match host - 'disable' turn off the feature, even if host has it - 'forbid' fail if host has the feature 'force' and 'disable' policies turn on/off the feature regardless of its availability on host. 'force' is unlikely to be used but its there for completeness since Xen and VMWare allow it. 'require' and 'forbid' policies prevent a guest from being started on a host which doesn't/does have the feature. 'forbid' is for cases where you disable the feature but a guest may still try to access it anyway and you don't want it to succeed. 'optional' policy sets the feature according to its availability on host. When a guest is booted on a host that has the feature and then migrated to another host, the policy changes to 'require' as we can't take the feature away from a running guest. Default policy for features provided by host CPU but not specified in domain configuration is set using match attribute of cpu tag. If 'minimum' match is requested, additional features will be treated as if they were specified with 'optional' policy. 'exact' match implies 'disable' policy and 'strict' match stands for 'forbid' policy. * docs/schemas/capability.rng docs/schemas/domain.rng: extend the RelaxNG schemas to add CPU flags support
2009-12-18 13:37:09 +00:00
<!--
CPU specification
-->
<define name="cpu">
<element name="cpu">
<choice>
<ref name="cpuTopology"/>
<group>
<ref name="cpuMatch"/>
<interleave>
<ref name="cpuModel"/>
<optional>
<ref name="cpuVendor"/>
</optional>
<optional>
<ref name="cpuTopology"/>
</optional>
<zeroOrMore>
<ref name="cpuFeature"/>
</zeroOrMore>
</interleave>
</group>
</choice>
</element>
</define>
<define name="cpuMatch">
<attribute name="match">
<choice>
<value>minimum</value>
<value>exact</value>
<value>strict</value>
</choice>
</attribute>
</define>
<define name="cpuModel">
<element name="model">
<text/>
</element>
</define>
<define name="cpuVendor">
<element name="vendor">
<text/>
</element>
</define>
<define name="cpuFeature">
<element name="feature">
<attribute name="policy">
<choice>
<value>force</value>
<value>require</value>
<value>optional</value>
<value>disable</value>
<value>forbid</value>
</choice>
</attribute>
<attribute name="name">
<ref name="featureName"/>
</attribute>
<empty/>
</element>
</define>
<define name="cpuTopology">
<element name="topology">
<attribute name="sockets">
<ref name="positiveInteger"/>
</attribute>
<attribute name="cores">
<ref name="positiveInteger"/>
</attribute>
<attribute name="threads">
<ref name="positiveInteger"/>
</attribute>
XML schema for CPU flags XML schema for CPU flags Firstly, CPU topology and model with optional features have to be advertised in host capabilities: <host> <cpu> <arch>ARCHITECTURE</arch> <features> <!-- old-style features are here --> </features> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature name="NAME"/> </cpu> ... </host> Secondly, drivers which support detailed CPU specification have to advertise it in guest capabilities: <guest> ... <features> <cpuselection/> </features> </guest> And finally, CPU may be configured in domain XML configuration: <domain> ... <cpu match="MATCH"> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature policy="POLICY" name="NAME"/> </cpu> </domain> Where MATCH can be one of: - 'minimum' specified CPU is the minimum requested CPU - 'exact' disable all additional features provided by host CPU - 'strict' fail if host CPU doesn't exactly match POLICY can be one of: - 'force' turn on the feature, even if host doesn't have it - 'require' fail if host doesn't have the feature - 'optional' match host - 'disable' turn off the feature, even if host has it - 'forbid' fail if host has the feature 'force' and 'disable' policies turn on/off the feature regardless of its availability on host. 'force' is unlikely to be used but its there for completeness since Xen and VMWare allow it. 'require' and 'forbid' policies prevent a guest from being started on a host which doesn't/does have the feature. 'forbid' is for cases where you disable the feature but a guest may still try to access it anyway and you don't want it to succeed. 'optional' policy sets the feature according to its availability on host. When a guest is booted on a host that has the feature and then migrated to another host, the policy changes to 'require' as we can't take the feature away from a running guest. Default policy for features provided by host CPU but not specified in domain configuration is set using match attribute of cpu tag. If 'minimum' match is requested, additional features will be treated as if they were specified with 'optional' policy. 'exact' match implies 'disable' policy and 'strict' match stands for 'forbid' policy. * docs/schemas/capability.rng docs/schemas/domain.rng: extend the RelaxNG schemas to add CPU flags support
2009-12-18 13:37:09 +00:00
</element>
</define>
<!--
System information specification:
Placeholder for system specific informations likes the ones
contained in the SMBIOS area.
Only a limited subset of entries can be modified there, so we
fully enumerate each case here.
The DMTF spec doesn't specify any string subset, just 0 terminated
byte strings, but better be safe and restrict at least the names
to avoid problems with space normalization in attribute values,
the value is kept as the element body for maximum flexibility.
A priori we allow only type 0 and type 1 string updates
-->
<define name="sysinfo">
<element name="sysinfo">
<attribute name="type">
<value>smbios</value>
</attribute>
<interleave>
<optional>
<element name="bios">
<oneOrMore>
<element name="entry">
<attribute name="name">
<ref name="sysinfo-bios-name"/>
</attribute>
<ref name="sysinfo-value"/>
</element>
</oneOrMore>
</element>
</optional>
<optional>
<element name="system">
<oneOrMore>
<element name="entry">
<attribute name="name">
<ref name="sysinfo-system-name"/>
</attribute>
<ref name="sysinfo-value"/>
</element>
</oneOrMore>
</element>
</optional>
</interleave>
</element>
</define>
<define name="sysinfo-bios-name">
<choice>
<value>vendor</value>
<value>version</value>
<value>date</value>
<value>release</value>
</choice>
</define>
<define name="sysinfo-system-name">
<choice>
<value>manufacturer</value>
<value>product</value>
<value>version</value>
<value>serial</value>
<value>uuid</value>
<value>sku</value>
<value>family</value>
</choice>
</define>
<define name="sysinfo-value">
<data type="string">
<param name='pattern'>[a-zA-Z0-9/\-_\. \(\)]+</param>
</data>
</define>
<define name="smbios">
<element name="smbios">
<attribute name="mode">
<choice>
<value>emulate</value>
<value>host</value>
<value>sysinfo</value>
</choice>
</attribute>
<empty/>
</element>
</define>
<define name="address">
<element name="address">
<choice>
<group>
<attribute name="type">
<value>pci</value>
</attribute>
<ref name="pciaddress"/>
</group>
<group>
<attribute name="type">
<value>drive</value>
</attribute>
<ref name="driveaddress"/>
</group>
<group>
<attribute name="type">
<value>virtio-serial</value>
</attribute>
<ref name="virtioserialaddress"/>
</group>
<group>
<attribute name="type">
<value>ccid</value>
</attribute>
<ref name="ccidaddress"/>
</group>
</choice>
</element>
</define>
<define name="filterref-node-attributes">
<attribute name="filter">
<data type="NCName"/>
</attribute>
<optional>
<element name="parameter">
<attribute name="name">
<ref name="filter-param-name"/>
</attribute>
<attribute name="value">
<ref name="filter-param-value"/>
</attribute>
</element>
</optional>
</define>
<define name="deviceBoot">
<element name="boot">
<attribute name="order">
<ref name="positiveInteger"/>
</attribute>
<empty/>
</element>
</define>
<!--
Optional hypervisor extensions in their own namespace:
QEmu
-->
<define name="qemucmdline">
<element name="commandline" ns="http://libvirt.org/schemas/domain/qemu/1.0">
<zeroOrMore>
<element name="arg">
<attribute name='value'/>
</element>
</zeroOrMore>
<zeroOrMore>
<element name="env">
<attribute name='name'>
<ref name="filter-param-name"/>
</attribute>
<optional>
<attribute name='value'/>
</optional>
<empty/>
</element>
</zeroOrMore>
</element>
</define>
<!--
Type library
Our unsignedInt doesn't allow a leading '+' in its lexical form
A domain name should be made of ascii, numbers, _-+ and is non-empty
UUID currently allows only the 32 characters strict syntax
memoryKB request at least 4Mbytes though Xen will grow bigger if too low
weight currently is in range [100, 1000]
-->
<define name="unsignedInt">
<data type="unsignedInt">
<param name="pattern">[0-9]+</param>
</data>
</define>
XML schema for CPU flags XML schema for CPU flags Firstly, CPU topology and model with optional features have to be advertised in host capabilities: <host> <cpu> <arch>ARCHITECTURE</arch> <features> <!-- old-style features are here --> </features> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature name="NAME"/> </cpu> ... </host> Secondly, drivers which support detailed CPU specification have to advertise it in guest capabilities: <guest> ... <features> <cpuselection/> </features> </guest> And finally, CPU may be configured in domain XML configuration: <domain> ... <cpu match="MATCH"> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature policy="POLICY" name="NAME"/> </cpu> </domain> Where MATCH can be one of: - 'minimum' specified CPU is the minimum requested CPU - 'exact' disable all additional features provided by host CPU - 'strict' fail if host CPU doesn't exactly match POLICY can be one of: - 'force' turn on the feature, even if host doesn't have it - 'require' fail if host doesn't have the feature - 'optional' match host - 'disable' turn off the feature, even if host has it - 'forbid' fail if host has the feature 'force' and 'disable' policies turn on/off the feature regardless of its availability on host. 'force' is unlikely to be used but its there for completeness since Xen and VMWare allow it. 'require' and 'forbid' policies prevent a guest from being started on a host which doesn't/does have the feature. 'forbid' is for cases where you disable the feature but a guest may still try to access it anyway and you don't want it to succeed. 'optional' policy sets the feature according to its availability on host. When a guest is booted on a host that has the feature and then migrated to another host, the policy changes to 'require' as we can't take the feature away from a running guest. Default policy for features provided by host CPU but not specified in domain configuration is set using match attribute of cpu tag. If 'minimum' match is requested, additional features will be treated as if they were specified with 'optional' policy. 'exact' match implies 'disable' policy and 'strict' match stands for 'forbid' policy. * docs/schemas/capability.rng docs/schemas/domain.rng: extend the RelaxNG schemas to add CPU flags support
2009-12-18 13:37:09 +00:00
<define name='positiveInteger'>
<data type='positiveInteger'>
<param name="pattern">[0-9]+</param>
</data>
</define>
<define name="cpuset">
<data type="string">
<param name="pattern">([0-9]+(-[0-9]+)?|\^[0-9]+)(,([0-9]+(-[0-9]+)?|\^[0-9]+))*</param>
</data>
</define>
<define name="countCPU">
<data type="unsignedShort">
<param name="pattern">[0-9]+</param>
<param name="minInclusive">1</param>
</data>
</define>
<define name="hostName">
<data type="string">
<param name="pattern">[a-zA-Z0-9\.\-]+</param>
</data>
</define>
<define name="PortNumber">
<data type="short">
<param name="minInclusive">-1</param>
</data>
</define>
<define name="weight">
<data type="unsignedInt">
<param name="pattern">[0-9]+</param>
<param name="minInclusive">100</param>
<param name="maxInclusive">1000</param>
</data>
</define>
<define name="memoryKB">
<data type="unsignedInt">
<param name="pattern">[0-9]+</param>
<param name="minInclusive">4000</param>
</data>
</define>
<define name="domainName">
<data type="string">
<param name="pattern">[A-Za-z0-9_\.\+\-&amp;:/]+</param>
</data>
</define>
<define name="diskSerial">
<data type="string">
<param name="pattern">[A-Za-z0-9_\.\+\-]+</param>
</data>
</define>
<define name="genericName">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\+\-]+</param>
</data>
</define>
<define name="UUID">
<choice>
<data type="string">
<param name="pattern">[a-fA-F0-9]{32}</param>
</data>
<data type="string">
<param name="pattern">[a-fA-F0-9]{8}\-([a-fA-F0-9]{4}\-){3}[a-fA-F0-9]{12}</param>
</data>
</choice>
</define>
<define name="filePath">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\.\+\-\\&amp;&quot;&apos;&lt;&gt;/%]+</param>
</data>
</define>
<define name="absFilePath">
<data type="string">
<param name="pattern">/[a-zA-Z0-9_\.\+\-\\&amp;&quot;&apos;&lt;&gt;/%]+</param>
</data>
</define>
<define name="absDirPath">
<data type="string">
<param name="pattern">/[a-zA-Z0-9_\.\+\-\\&amp;&quot;&apos;&lt;&gt;/%]*</param>
</data>
</define>
<define name="deviceName">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\.\-\\:/]+</param>
</data>
</define>
<define name="bridgeMode">
<data type="string">
<param name="pattern">(vepa|bridge|private)</param>
</data>
</define>
<define name="addrMAC">
<data type="string">
<param name="pattern">([a-fA-F0-9]{2}:){5}[a-fA-F0-9]{2}</param>
</data>
</define>
<define name="addrIP">
<data type="string">
<param name="pattern">([0-2]?[0-9]?[0-9]\.){3}[0-2]?[0-9]?[0-9]</param>
</data>
</define>
<define name="usbId">
<data type="string">
<param name="pattern">(0x)?[0-9a-fA-F]{1,4}</param>
</data>
</define>
<define name="usbAddr">
<data type="string">
<param name="pattern">(0x)?[0-9a-fA-F]{1,3}</param>
</data>
</define>
<define name="pciDomain">
<data type="string">
<param name="pattern">(0x)?[0-9a-fA-F]{1,4}</param>
</data>
</define>
<define name="pciBus">
<data type="string">
<param name="pattern">(0x)?[0-9a-fA-F]{1,2}</param>
</data>
</define>
<define name="pciSlot">
<data type="string">
<param name="pattern">(0x)?[0-1]?[0-9a-fA-F]</param>
</data>
</define>
<define name="pciFunc">
<data type="string">
<param name="pattern">(0x)?[0-7]</param>
</data>
</define>
<define name="driveController">
<data type="string">
<param name="pattern">[0-9]{1,2}</param>
</data>
</define>
<define name="driveBus">
<data type="string">
<param name="pattern">[0-9]{1,2}</param>
</data>
</define>
<define name="driveUnit">
<data type="string">
<param name="pattern">[0-9]{1,2}</param>
</data>
</define>
XML schema for CPU flags XML schema for CPU flags Firstly, CPU topology and model with optional features have to be advertised in host capabilities: <host> <cpu> <arch>ARCHITECTURE</arch> <features> <!-- old-style features are here --> </features> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature name="NAME"/> </cpu> ... </host> Secondly, drivers which support detailed CPU specification have to advertise it in guest capabilities: <guest> ... <features> <cpuselection/> </features> </guest> And finally, CPU may be configured in domain XML configuration: <domain> ... <cpu match="MATCH"> <model>NAME</model> <topology sockets="S" cores="C" threads="T"/> <feature policy="POLICY" name="NAME"/> </cpu> </domain> Where MATCH can be one of: - 'minimum' specified CPU is the minimum requested CPU - 'exact' disable all additional features provided by host CPU - 'strict' fail if host CPU doesn't exactly match POLICY can be one of: - 'force' turn on the feature, even if host doesn't have it - 'require' fail if host doesn't have the feature - 'optional' match host - 'disable' turn off the feature, even if host has it - 'forbid' fail if host has the feature 'force' and 'disable' policies turn on/off the feature regardless of its availability on host. 'force' is unlikely to be used but its there for completeness since Xen and VMWare allow it. 'require' and 'forbid' policies prevent a guest from being started on a host which doesn't/does have the feature. 'forbid' is for cases where you disable the feature but a guest may still try to access it anyway and you don't want it to succeed. 'optional' policy sets the feature according to its availability on host. When a guest is booted on a host that has the feature and then migrated to another host, the policy changes to 'require' as we can't take the feature away from a running guest. Default policy for features provided by host CPU but not specified in domain configuration is set using match attribute of cpu tag. If 'minimum' match is requested, additional features will be treated as if they were specified with 'optional' policy. 'exact' match implies 'disable' policy and 'strict' match stands for 'forbid' policy. * docs/schemas/capability.rng docs/schemas/domain.rng: extend the RelaxNG schemas to add CPU flags support
2009-12-18 13:37:09 +00:00
<define name="featureName">
<data type="string">
<param name='pattern'>[a-zA-Z0-9\-_]+</param>
</data>
</define>
<define name="timeDelta">
<data type="string">
<param name="pattern">(-|\+)?[0-9]+</param>
</data>
</define>
<define name="timeZone">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\.\+\-/]+</param>
</data>
</define>
<define name="filter-param-name">
<data type="string">
<param name="pattern">[a-zA-Z0-9_]+</param>
</data>
</define>
<define name="filter-param-value">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\.:]+</param>
</data>
</define>
vepa: parsing for 802.1Qb{g|h} XML This patch parses the following two XML descriptions, one for 802.1Qbg and one for 802.1Qbh, and stores the data internally. The actual triggering of the switch setup protocol has not been implemented here but the relevant code to do that should go into the functions associatePortProfileId() and disassociatePortProfileId(). <interface type='direct'> <source dev='eth0.100' mode='vepa'/> <model type='virtio'/> <virtualport type='802.1Qbg'> <parameters managerid='12' typeid='0x123456' typeidversion='1' instanceid='fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f'/> </virtualport> <filterref filter='clean-traffic'/> </interface> <interface type='direct'> <source dev='eth0.100' mode='vepa'/> <model type='virtio'/> <virtualport type='802.1Qbh'> <parameters profileid='my_profile'/> </virtualport> </interface> I'd suggest to use this patch as a base for triggering the setup protocol with the 802.1Qb{g|h} switch. Several rounds of changes were made to this patch. The following is a list of these changes. - Renamed structure virVirtualPortProfileDef to virVirtualPortProfileParams as per Daniel Berrange's request - Addressing Daniel Berrange's comments: - removing macvtap.h's dependency on domain_conf.h by moving the virVirtualPortProfileDef structure into macvtap.h and not passing virtDomainNetDefPtr to any functions in macvtap.c - Addressed most of Chris Wright's comments: - indicating error in case virtualport XML node cannot be parsed properly - parsing hex and decimal numbers using virStrToLong_ui() with parameter '0' for base - tgifname (target interface name) variable wasn't necessary to pass to openMacvtapTap function anymore - assigning the virtual port data structure to the virDomainNetDef only if it was previously parsed - make sure that the error code returned by openMacvtapTap() is a negative n in case the associatePortProfileId() function failed. - renaming vsi in the XML to virtualport - replace all occurrences of vsi in the source as well - removing mode and MAC address parameters from the functions that will communicate with the hareware diretctly or indirectly - moving the associate and disassociate functions to the end of the file for subsequent patches to easier make them generally available for export - passing the macvtap interface name rather than the link device since this otherwise gives funny side effects when using netlink messages where IFLA_IFNAME and IFLA_ADDRESS are specified and the link dev all of a sudden gets the MAC address of the macvtap interface. - Removing rc = -1 error indications in the case of 802.1Qbg|h setup in case we wanted to use hook scripts for the setup and so the setup doesn't fail here. - if instance ID UUID is not supplied it will automatically be generated - adapted schema to make instance ID UUID optional - added test case - parser and XML generator have been separated into their own functions so they can be re-used elsewhere (passthrough case for example) - Adapted XML parser and generator support the above shown type (802.1Qbg, 802.1Qbh). - Adapted schema to above XML - Adapted test XML to above XML - Passing through the VM's UUID which seems to be necessary for 802.1Qbh -- sorry no host UUID - adding virtual function ID to association function, in case it's necessary to use (for SR-IOV)
2010-05-25 21:37:00 +00:00
<define name="uint8range">
<choice>
<data type="string">
<param name="pattern">0x[0-9a-fA-F]{1,2}</param>
</data>
<data type="int">
<param name="minInclusive">0</param>
<param name="maxInclusive">255</param>
</data>
</choice>
</define>
<define name="uint24range">
<choice>
<data type="string">
<param name="pattern">0x[0-9a-fA-F]{1,6}</param>
</data>
<data type="int">
<param name="minInclusive">0</param>
<param name="maxInclusive">16777215</param>
</data>
</choice>
</define>
<define name="virtualPortProfileID">
<data type="string">
<param name="maxLength">39</param>
</data>
</define>
</grammar>