[libvirt] [PATCH] update libvirt.rng
The below patch makes a significant update to libvirt.rng to bring it into line with reality. This is an incremental improvement rather than a full fix. In particular, various parts are still under-specified (e.g. qemu char devices). This version lets almost all of the XML files in tests/ validate. I'd appreciate help getting the last few to validate - any volunteers? One possible idea might be virsh validate: split out both the schema validation and the additional checks in libvirt into one consolidated place. This would help people check their definitions. The question also arises on how to help avoid the schema getting so badly out of date again. Some suggestions: - add a validation phase to the test suite, and mark failures - require any changes to the implicit schema to add a test suite entry - and require such changes to update the schema too Comments? thanks, john Index: docs/libvirt.rng =================================================================== RCS file: /data/cvs/libvirt/docs/libvirt.rng,v retrieving revision 1.7 diff -u -r1.7 libvirt.rng --- docs/libvirt.rng 14 Mar 2008 11:08:03 -0000 1.7 +++ docs/libvirt.rng 4 Jul 2008 22:22:52 -0000 @@ -50,6 +50,7 @@ </optional> </group> </choice> + <ref name='clock'/> <ref name='resources'/> <ref name='features'/> <ref name='termination'/> @@ -82,8 +83,13 @@ </choice> <value>hvm</value> </element> + <optional> + <ref name='bootdev'/> + </optional> </element> + <ref name='clock'/> <ref name='resources'/> + <ref name='termination'/> <ref name='devices'/> </interleave> </group> @@ -157,8 +163,14 @@ <interleave> <element name='os'> <element name='type'> - <value>hvm</value> + <choice> + <value>hvm</value> + <value>xen</value> + </choice> </element> + <optional> + <ref name='bootdev' /> + </optional> </element> <ref name='resources'/> <ref name='devices-with-emulator'/> @@ -208,12 +220,29 @@ </optional> <optional> <element name='vcpu'> + <optional> + <attribute name='cpuset' /> + </optional> <ref name='countCPU'/> </element> </optional> </interleave> </define> + <define name='clock'> + <optional> + <element name='clock'> + <attribute name='offset'> + <choice> + <value>localtime</value> + <value>utc</value> + </choice> + </attribute> + <empty/> + </element> + </optional> + </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 @@ -238,14 +267,7 @@ </element> </define> - <!-- - A paravirtualized linux domain, this requires at least a kernel path - and the root device, the initrd and command line arguments are optional - --> - <define name='linux'> - <element name='type'> - <value>linux</value> - </element> + <define name='kernboot'> <interleave> <element name='kernel'> <ref name='absFilePath'/> @@ -269,8 +291,39 @@ </define> <!-- - A fully virtualized domain, this requires the path to the loader and - an optional boot device (hd, fd or cdrom). + A paravirtualized linux domain, this requires at least a kernel path + and the root device, the initrd and command line arguments are optional + --> + <define name='linux'> + <element name='type'> + <value>linux</value> + </element> + <ref name='kernboot'/> + </define> + + <define name='bootdev'> + <element name='boot'> + <attribute name='dev'> + <choice> + <value>hd</value> + <value>fd</value> + <value>cdrom</value> + <value>network</value> + </choice> + </attribute> + <empty/> + </element> + </define> + + <define name='hvmboot'> + <choice> + <ref name='bootdev'/> + <ref name='kernboot'/> + </choice> + </define> + + <!-- + A fully virtualized domain and how to boot it. --> <define name='hvm'> <element name='type'> @@ -281,20 +334,28 @@ <ref name='absFilePath'/> </element> <optional> - <element name='boot'> - <attribute name='dev'> - <choice> - <value>hd</value> - <value>fd</value> - <value>cdrom</value> - </choice> - </attribute> - <empty/> - </element> + <ref name='hvmboot' /> </optional> </interleave> </define> + <define name='diskspec'> + <optional> + <ref name='driver'/> + </optional> + <ref name='target'/> + <optional> + <element name='readonly'> + <empty/> + </element> + </optional> + <optional> + <element name='shareable'> + <empty/> + </element> + </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 @@ -315,43 +376,32 @@ <group> <attribute name='type'> <value>file</value> - </attribute> + </attribute> <interleave> - <element name='source'> - <attribute name='file'> - <ref name='absFilePath'/> - </attribute> - <empty/> - </element> - <optional> - <ref name='driver'/> - </optional> - <ref name='target'/> - <optional> - <ref name='readonly'/> - </optional> - </interleave> + <element name='source'> + <attribute name='file'> + <ref name='absFilePath'/> + </attribute> + <empty/> + </element> + <ref name='diskspec'/> + </interleave> </group> <group> <attribute name='type'> - <value>block</value> - </attribute> - <interleave> - <element name='source'> - <attribute name='dev'> - <ref name='deviceName'/> - </attribute> - <empty/> - </element> - <optional> - <ref name='driver'/> - </optional> - <ref name='target'/> - <optional> - <ref name='readonly'/> - </optional> - </interleave> + <value>block</value> + </attribute> + <interleave> + <element name='source'> + <attribute name='dev'> + <ref name='deviceName'/> + </attribute> + <empty/> + </element> + <ref name='diskspec'/> + </interleave> </group> + <ref name='diskspec'/> </choice> </element> </define> @@ -361,12 +411,16 @@ <attribute name='dev'> <ref name='deviceName'/> </attribute> - </element> - </define> - - <define name='readonly'> - <element name='readonly'> - <empty/> + <optional> + <attribute name='bus'> + <choice> + <value>ide</value> + <value>virtio</value> + <value>fdc</value> + <value>xen</value> + </choice> + </attribute> + </optional> </element> </define> @@ -392,7 +446,7 @@ 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 - options. + options. FIXME --> <define name='interface'> <element name='interface'> @@ -402,12 +456,14 @@ <value>bridge</value> </attribute> <interleave> - <element name='source'> - <attribute name='bridge'> - <ref name='deviceName'/> - </attribute> - <empty/> - </element> + <optional> + <element name='source'> + <attribute name='bridge'> + <ref name='deviceName'/> + </attribute> + <empty/> + </element> + </optional> <ref name='interface-options'/> </interleave> </group> @@ -416,8 +472,24 @@ <value>ethernet</value> </attribute> <interleave> + <optional> + <element name='source'> + <attribute name='dev'> + <ref name='deviceName'/> + </attribute> + <empty/> + </element> + </optional> + <ref name='interface-options'/> + </interleave> + </group> + <group> + <attribute name='type'> + <value>network</value> + </attribute> + <interleave> <element name='source'> - <attribute name='dev'> + <attribute name='network'> <ref name='deviceName'/> </attribute> <empty/> @@ -478,11 +550,17 @@ <empty/> </element> </optional> + <optional> + <element name='model'> + <attribute name='type' /> + <empty/> + </element> + </optional> </interleave> </define> <!-- - An emulator descritpion is just a path to the binary used for the task + An emulator description is just a path to the binary used for the task --> <define name='emulator'> <element name='emulator'> @@ -493,7 +571,8 @@ <!-- A graphic description, currently in Xen only 2 types are supported: - sdl without arguments - - vnc with a required port and optional listen IP address and password + - vnc with a required port and optional listen IP address, password + and keymap --> <define name='graphic'> <element name='graphics'> @@ -518,6 +597,11 @@ <text/> </attribute> </optional> + <optional> + <attribute name='keymap'> + <text/> + </attribute> + </optional> </group> </choice> </element> @@ -565,24 +649,134 @@ </define> <!-- + Specific setup for a qemu emulated character device. Note: this + definition doesn't fully specify the constraints on this node. + --> + <define name='qemucdev'> + <attribute name='type'> + <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> + </choice> + </attribute> + + <interleave> + <optional> + <oneOrMore> + <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> + </oneOrMore> + </optional> + <optional> + <element name='protocol'> + <optional> + <attribute name='type' /> + </optional> + </element> + </optional> + <optional> + <element name='target'> + <optional> + <attribute name='port' /> + </optional> + </element> + </optional> + </interleave> + </define> + + <!-- The description for a console just a tty device --> <define name='console'> <element name='console'> - <attribute name='tty'> - <ref name='devicePath'/> - </attribute> - <empty/> + <choice> + <group> + <optional> + <attribute name='tty'> + <ref name='devicePath'/> + </attribute> + </optional> + <empty/> + </group> + <ref name='qemucdev' /> + </choice> + </element> + </define> + + <define name='sound'> + <oneOrMore> + <element name='sound'> + <attribute name='model'> + <choice> + <value>sb16</value> + <value>es1370</value> + <value>pcspk</value> + </choice> + </attribute> + </element> + </oneOrMore> + </define> + + <define name='parallel'> + <element name='parallel'> + <ref name='qemucdev' /> + </element> + </define> + + <define name='serial'> + <element name='serial'> + <ref name='qemucdev' /> </element> </define> + <define name='input'> + <oneOrMore> + <element name='input'> + <attribute name='type'> + <choice> + <value>tablet</value> + <value>mouse</value> + </choice> + </attribute> + <optional> + <attribute name='bus'> + <choice> + <value>ps2</value> + <value>usb</value> + <value>xen</value> + </choice> + </attribute> + </optional> + </element> + </oneOrMore> + </define> + <!-- - The devices bloc allows: - - an optional emulator path, restricted to hvm configs but hard to check - - an optional graphic description , restricted to hvm configs too - - zero or more disk devices - - zero or more interface devices + Devices attached to a domain. --> <define name='devices'> <element name='devices'> @@ -602,6 +796,18 @@ <optional> <ref name='console'/> </optional> + <optional> + <ref name='sound'/> + </optional> + <optional> + <ref name='parallel'/> + </optional> + <optional> + <ref name='serial'/> + </optional> + <optional> + <ref name='input'/> + </optional> </interleave> </element> </define> @@ -625,6 +831,18 @@ <optional> <ref name='console'/> </optional> + <optional> + <ref name='sound'/> + </optional> + <optional> + <ref name='parallel'/> + </optional> + <optional> + <ref name='serial'/> + </optional> + <optional> + <ref name='input'/> + </optional> </interleave> </element> </define>
On Sat, Jul 05, 2008 at 04:43:04PM +0100, John Levon wrote:
The below patch makes a significant update to libvirt.rng to bring it into line with reality. This is an incremental improvement rather than a full fix. In particular, various parts are still under-specified (e.g. qemu char devices).
This version lets almost all of the XML files in tests/ validate. I'd appreciate help getting the last few to validate - any volunteers?
Sure - what command are you using to validate ?
One possible idea might be virsh validate: split out both the schema validation and the additional checks in libvirt into one consolidated place. This would help people check their definitions.
The question also arises on how to help avoid the schema getting so badly out of date again. Some suggestions:
- add a validation phase to the test suite, and mark failures
This is a good idea.
- require any changes to the implicit schema to add a test suite entry
All XML additions should require test suite support, so if we have validation on all test suite data files this should ensure it is essentially compulsory. [snip the schema] All your changes look good to me. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Sat, Jul 05, 2008 at 05:51:50PM +0100, Daniel P. Berrange wrote:
The below patch makes a significant update to libvirt.rng to bring it into line with reality. This is an incremental improvement rather than a full fix. In particular, various parts are still under-specified (e.g. qemu char devices).
This version lets almost all of the XML files in tests/ validate. I'd appreciate help getting the last few to validate - any volunteers?
Sure - what command are you using to validate ?
xmllint --noout --relaxng docs/libvirt.rng foo.xml regards john
On Sat, Jul 05, 2008 at 08:01:52PM +0100, John Levon wrote:
On Sat, Jul 05, 2008 at 05:51:50PM +0100, Daniel P. Berrange wrote:
The below patch makes a significant update to libvirt.rng to bring it into line with reality. This is an incremental improvement rather than a full fix. In particular, various parts are still under-specified (e.g. qemu char devices).
This version lets almost all of the XML files in tests/ validate. I'd appreciate help getting the last few to validate - any volunteers?
Sure - what command are you using to validate ?
xmllint --noout --relaxng docs/libvirt.rng foo.xml
Here's a further update which makes all of them pass, except for one which had bogus XML that I've fixed. NB, I've done away with the xenpv/xenfv/kvm split in the top level domain element since this is unsustainable and does not really match what the newer XML parser will allow. Daniel Index: docs/libvirt.rng =================================================================== RCS file: /data/cvs/libvirt/docs/libvirt.rng,v retrieving revision 1.7 diff -u -p -r1.7 libvirt.rng --- docs/libvirt.rng 14 Mar 2008 11:08:03 -0000 1.7 +++ docs/libvirt.rng 7 Jul 2008 09:11:57 -0000 @@ -8,88 +8,130 @@ <!-- We handle only document defining a domain - Currently the virtualization types supported are: - - xen, either paravirualized with a linux os or fully virtualized (hvm) - - kvm, requiring a path to the emulator in devices - - qemu, where the arch and machine must be provided in the os block --> <define name='domain'> <element name="domain"> - <choice> - <ref name='xen-domain'/> - <ref name='kvm-domain'/> - <ref name='qemu-domain'/> - </choice> - </element> - </define> - - <!-- - Description of a Xen domain: - The description must start with the identification information and then - os or bootloader, resources, features, devices and termination information - can be given in any order. - --> - <define name='xen-domain'> - <group> - <attribute name='type'> - <value>xen</value> - </attribute> + <ref name='hvs'/> <ref name='ids'/> <interleave> - <choice> - <group> - <ref name='os'/> - <optional> - <ref name='bootloader'/> - </optional> - </group> - <group> - <ref name='bootloader'/> - <optional> - <ref name='os'/> - </optional> - </group> - </choice> + <ref name='os'/> + <ref name='clock'/> <ref name='resources'/> <ref name='features'/> <ref name='termination'/> - <ref name='devices'/> + <optional> + <ref name='devices'/> + </optional> </interleave> - </group> + </element> </define> - <!-- - Description of a QEmu domain: - The description must start with the identification information and then - os, resources, devices can be given in any order. - The specific part are the combinations of architectures and machines - being emulated. - --> - <define name='qemu-domain'> - <group> - <attribute name='type'> - <value>qemu</value> - </attribute> - <ref name='ids'/> + <define name='hvs'> + <attribute name='type'> + <choice> + <value>xen</value> + <value>kvm</value> + <value>kqemu</value> + <value>qemu</value> + <value>lxc</value> + <value>openvz</value> + <value>test</value> + </choice> + </attribute> + </define> + + <define name='os'> + <choice> + <ref name='osxen'/> + <ref name='oshvm'/> + </choice> + </define> + + <define name='osxen'> + <choice> + <group> + <optional> + <ref name='bootloader'/> + </optional> + <element name='os'> + <ref name='ostypexen'/> + <ref name='osbootkernel'/> + </element> + </group> + <group> + <ref name='bootloader'/> + <optional> + <element name='os'> + <ref name='ostypexen'/> + <optional> + <ref name='osbootkernel'/> + </optional> + </element> + </optional> + </group> + </choice> + </define> + + + <define name='oshvm'> + <element name='os'> + <ref name='ostypehvm'/> <interleave> - <element name='os'> - <element name='type'> - <choice> - <ref name='qemu-x86'/> - <ref name='qemu-mips'/> - <ref name='qemu-sparc'/> - <ref name='qemu-ppc'/> - </choice> - <value>hvm</value> + <optional> + <element name='loader'> + <ref name='absFilePath'/> </element> - </element> - <ref name='resources'/> - <ref name='devices'/> + </optional> + <choice> + <ref name='osbootkernel'/> + <ref name='osbootdev'/> + </choice> </interleave> - </group> + </element> </define> - <define name='qemu-x86'> + + <define name='ostypexen'> + <element name='type'> + <optional> + <attribute name='arch'> + <choice> + <value>i686</value> + <value>x86_64</value> + <value>ia64</value> + </choice> + </attribute> + </optional> + <optional> + <attribute name='machine'> + <choice> + <value>xenpv</value> + <value>xenner</value> + </choice> + </attribute> + </optional> + <choice> + <value>xen</value> + <value>linux</value> + </choice> + </element> + </define> + + <define name='ostypehvm'> + <element name='type'> + <optional> + <choice> + <ref name='hvmx86'/> + <ref name='hvmmips'/> + <ref name='hvmsparc'/> + <ref name='hvmppc'/> + </choice> + </optional> + <value>hvm</value> + </element> + </define> + + <define name='hvmx86'> <group> <attribute name='arch'> <choice> @@ -106,7 +148,7 @@ </group> </define> - <define name='qemu-mips'> + <define name='hvmmips'> <group> <attribute name='arch'> <value>mips</value> @@ -117,7 +159,7 @@ </group> </define> - <define name='qemu-sparc'> + <define name='hvmsparc'> <group> <attribute name='arch'> <value>sparc</value> @@ -128,7 +170,7 @@ </group> </define> - <define name='qemu-ppc'> + <define name='hvmppc'> <group> <attribute name='arch'> <value>ppc</value> @@ -143,28 +185,6 @@ </group> </define> - <!-- - Description of a KVM domain: - The description must start with the identification information and then - os, resources, devices can be given in any order. - --> - <define name='kvm-domain'> - <group> - <attribute name='type'> - <value>kvm</value> - </attribute> - <ref name='ids'/> - <interleave> - <element name='os'> - <element name='type'> - <value>hvm</value> - </element> - </element> - <ref name='resources'/> - <ref name='devices-with-emulator'/> - </interleave> - </group> - </define> <!-- The Identifiers can be: @@ -208,44 +228,51 @@ </optional> <optional> <element name='vcpu'> + <optional> + <attribute name='cpuset' /> + </optional> <ref name='countCPU'/> </element> </optional> </interleave> </define> + <define name='clock'> + <optional> + <element name='clock'> + <attribute name='offset'> + <choice> + <value>localtime</value> + <value>utc</value> + </choice> + </attribute> + <empty/> + </element> + </optional> + </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'> - <element name='bootloader'> - <ref name='absFilePath'/> - </element> - </define> - <!-- - The Operating system can be: - - a linux paravirtualized OS - - a fully virtualized machine where the OS is unknown - --> - <define name='os'> - <element name='os'> - <choice> - <ref name='linux'/> - <ref name='hvm'/> - </choice> - </element> + <interleave> + <element name='bootloader'> + <choice> + <ref name='absFilePath'/> + <empty/> + </choice> + </element> + <optional> + <element name='bootloader_args'> + <text/> + </element> + </optional> + </interleave> </define> - <!-- - A paravirtualized linux domain, this requires at least a kernel path - and the root device, the initrd and command line arguments are optional - --> - <define name='linux'> - <element name='type'> - <value>linux</value> - </element> + <define name='osbootkernel'> <interleave> <element name='kernel'> <ref name='absFilePath'/> @@ -268,31 +295,36 @@ </interleave> </define> - <!-- - A fully virtualized domain, this requires the path to the loader and - an optional boot device (hd, fd or cdrom). - --> - <define name='hvm'> - <element name='type'> - <value>hvm</value> + <define name='osbootdev'> + <element name='boot'> + <attribute name='dev'> + <choice> + <value>hd</value> + <value>fd</value> + <value>cdrom</value> + <value>network</value> + </choice> + </attribute> + <empty/> </element> - <interleave> - <element name='loader'> - <ref name='absFilePath'/> + </define> + + + <define name='diskspec'> + <optional> + <ref name='driver'/> + </optional> + <ref name='target'/> + <optional> + <element name='readonly'> + <empty/> </element> - <optional> - <element name='boot'> - <attribute name='dev'> - <choice> - <value>hd</value> - <value>fd</value> - <value>cdrom</value> - </choice> - </attribute> - <empty/> - </element> - </optional> - </interleave> + </optional> + <optional> + <element name='shareable'> + <empty/> + </element> + </optional> </define> <!-- @@ -315,43 +347,36 @@ <group> <attribute name='type'> <value>file</value> - </attribute> + </attribute> <interleave> - <element name='source'> - <attribute name='file'> - <ref name='absFilePath'/> - </attribute> - <empty/> - </element> - <optional> - <ref name='driver'/> - </optional> - <ref name='target'/> <optional> - <ref name='readonly'/> + <element name='source'> + <attribute name='file'> + <ref name='absFilePath'/> + </attribute> + <empty/> + </element> </optional> - </interleave> + <ref name='diskspec'/> + </interleave> </group> <group> <attribute name='type'> - <value>block</value> - </attribute> - <interleave> - <element name='source'> - <attribute name='dev'> - <ref name='deviceName'/> - </attribute> - <empty/> - </element> - <optional> - <ref name='driver'/> - </optional> - <ref name='target'/> + <value>block</value> + </attribute> + <interleave> <optional> - <ref name='readonly'/> + <element name='source'> + <attribute name='dev'> + <ref name='deviceName'/> + </attribute> + <empty/> + </element> </optional> - </interleave> + <ref name='diskspec'/> + </interleave> </group> + <ref name='diskspec'/> </choice> </element> </define> @@ -361,12 +386,16 @@ <attribute name='dev'> <ref name='deviceName'/> </attribute> - </element> - </define> - - <define name='readonly'> - <element name='readonly'> - <empty/> + <optional> + <attribute name='bus'> + <choice> + <value>ide</value> + <value>virtio</value> + <value>fdc</value> + <value>xen</value> + </choice> + </attribute> + </optional> </element> </define> @@ -376,23 +405,23 @@ extended in the future, and libvirt doesn't look for specific values. --> <define name='driver'> - <element name='driver'> - <attribute name='name'> + <element name='driver'> + <attribute name='name'> + <ref name='genericName'/> + </attribute> + <optional> + <attribute name='type'> <ref name='genericName'/> </attribute> - <optional> - <attribute name='type'> - <ref name='genericName'/> - </attribute> - </optional> - <empty/> - </element> + </optional> + <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 - options. + options. FIXME --> <define name='interface'> <element name='interface'> @@ -402,12 +431,14 @@ <value>bridge</value> </attribute> <interleave> - <element name='source'> - <attribute name='bridge'> - <ref name='deviceName'/> - </attribute> - <empty/> - </element> + <optional> + <element name='source'> + <attribute name='bridge'> + <ref name='deviceName'/> + </attribute> + <empty/> + </element> + </optional> <ref name='interface-options'/> </interleave> </group> @@ -416,8 +447,24 @@ <value>ethernet</value> </attribute> <interleave> + <optional> + <element name='source'> + <attribute name='dev'> + <ref name='deviceName'/> + </attribute> + <empty/> + </element> + </optional> + <ref name='interface-options'/> + </interleave> + </group> + <group> + <attribute name='type'> + <value>network</value> + </attribute> + <interleave> <element name='source'> - <attribute name='dev'> + <attribute name='network'> <ref name='deviceName'/> </attribute> <empty/> @@ -445,44 +492,50 @@ - the target device used --> <define name='interface-options'> - <interleave> - <optional> - <element name='target'> - <attribute name='dev'> - <ref name='deviceName'/> - </attribute> - <empty/> - </element> - </optional> - <optional> - <element name='mac'> - <attribute name='address'> - <ref name='addrMAC'/> - </attribute> - <empty/> - </element> - </optional> - <optional> - <element name='ip'> - <attribute name='address'> - <ref name='addrIP'/> - </attribute> - <empty/> - </element> - </optional> - <optional> - <element name='script'> - <attribute name='path'> - <ref name='filePath'/> + <interleave> + <optional> + <element name='target'> + <attribute name='dev'> + <ref name='deviceName'/> + </attribute> + <empty/> + </element> + </optional> + <optional> + <element name='mac'> + <attribute name='address'> + <ref name='addrMAC'/> </attribute> - <empty/> - </element> - </optional> - </interleave> + <empty/> + </element> + </optional> + <optional> + <element name='ip'> + <attribute name='address'> + <ref name='addrIP'/> + </attribute> + <empty/> + </element> + </optional> + <optional> + <element name='script'> + <attribute name='path'> + <ref name='filePath'/> + </attribute> + <empty/> + </element> + </optional> + <optional> + <element name='model'> + <attribute name='type' /> + <empty/> + </element> + </optional> + </interleave> </define> <!-- - An emulator descritpion is just a path to the binary used for the task + An emulator description is just a path to the binary used for the task --> <define name='emulator'> <element name='emulator'> @@ -493,7 +546,8 @@ <!-- A graphic description, currently in Xen only 2 types are supported: - sdl without arguments - - vnc with a required port and optional listen IP address and password + - vnc with a required port and optional listen IP address, password + and keymap --> <define name='graphic'> <element name='graphics'> @@ -505,9 +559,19 @@ <attribute name='type'> <value>vnc</value> </attribute> - <attribute name='port'> - <ref name='PortNumber'/> - </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='listen'> <ref name='addrIP'/> @@ -518,6 +582,11 @@ <text/> </attribute> </optional> + <optional> + <attribute name='keymap'> + <text/> + </attribute> + </optional> </group> </choice> </element> @@ -565,66 +634,149 @@ </define> <!-- + Specific setup for a qemu emulated character device. Note: this + definition doesn't fully specify the constraints on this node. + --> + <define name='qemucdev'> + <attribute name='type'> + <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> + </choice> + </attribute> + + <interleave> + <optional> + <oneOrMore> + <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> + </oneOrMore> + </optional> + <optional> + <element name='protocol'> + <optional> + <attribute name='type' /> + </optional> + </element> + </optional> + <optional> + <element name='target'> + <optional> + <attribute name='port' /> + </optional> + </element> + </optional> + </interleave> + </define> + + <!-- The description for a console just a tty device --> <define name='console'> <element name='console'> - <attribute name='tty'> - <ref name='devicePath'/> + <choice> + <group> + <optional> + <attribute name='tty'> + <ref name='devicePath'/> + </attribute> + </optional> + <empty/> + </group> + <ref name='qemucdev' /> + </choice> + </element> + </define> + + <define name='sound'> + <element name='sound'> + <attribute name='model'> + <choice> + <value>sb16</value> + <value>es1370</value> + <value>pcspk</value> + </choice> </attribute> - <empty/> </element> </define> - <!-- - The devices bloc allows: - - an optional emulator path, restricted to hvm configs but hard to check - - an optional graphic description , restricted to hvm configs too - - zero or more disk devices - - zero or more interface devices - --> - <define name='devices'> - <element name='devices'> - <interleave> - <optional> - <ref name='emulator'/> - </optional> - <optional> - <ref name='graphic'/> - </optional> - <zeroOrMore> - <ref name='disk'/> - </zeroOrMore> - <zeroOrMore> - <ref name='interface'/> - </zeroOrMore> - <optional> - <ref name='console'/> - </optional> - </interleave> + <define name='parallel'> + <element name='parallel'> + <ref name='qemucdev' /> + </element> + </define> + + <define name='serial'> + <element name='serial'> + <ref name='qemucdev' /> + </element> + </define> + + <define name='input'> + <element name='input'> + <attribute name='type'> + <choice> + <value>tablet</value> + <value>mouse</value> + </choice> + </attribute> + <optional> + <attribute name='bus'> + <choice> + <value>ps2</value> + <value>usb</value> + <value>xen</value> + </choice> + </attribute> + </optional> </element> </define> <!-- - Sometimes the emulator is mandatory, e.g. with KVM + Devices attached to a domain. --> - <define name='devices-with-emulator'> + <define name='devices'> <element name='devices'> <interleave> - <ref name='emulator'/> <optional> - <ref name='graphic'/> + <ref name='emulator'/> </optional> <zeroOrMore> - <ref name='disk'/> - </zeroOrMore> - <zeroOrMore> - <ref name='interface'/> + <choice> + <ref name='graphic'/> + <ref name='disk'/> + <ref name='interface'/> + <ref name='console'/> + <ref name='sound'/> + <ref name='parallel'/> + <ref name='serial'/> + <ref name='input'/> + </choice> </zeroOrMore> - <optional> - <ref name='console'/> - </optional> </interleave> </element> </define> @@ -688,7 +840,7 @@ </define> <define name='domainName'> <data type='string'> - <param name="pattern">[a-zA-Z0-9_\+\-]+</param> + <param name="pattern">[a-zA-Z0-9_\+\-&]+</param> </data> </define> <define name='genericName'> @@ -708,12 +860,12 @@ </define> <define name='filePath'> <data type='string'> - <param name="pattern">[a-zA-Z0-9_\+\-%./]+</param> + <param name="pattern">[a-zA-Z0-9_\+\-%./&]+</param> </data> </define> <define name='absFilePath'> <data type='string'> - <param name="pattern">/[a-zA-Z0-9_\+\-%./]+</param> + <param name="pattern">/[a-zA-Z0-9_\+\-%./&]+</param> </data> </define> <define name='devicePath'> Index: tests/qemuxml2argvdata/qemuxml2argv-input-xen.xml =================================================================== RCS file: /data/cvs/libvirt/tests/qemuxml2argvdata/qemuxml2argv-input-xen.xml,v retrieving revision 1.1 diff -u -p -r1.1 qemuxml2argv-input-xen.xml --- tests/qemuxml2argvdata/qemuxml2argv-input-xen.xml 15 May 2008 16:11:40 -0000 1.1 +++ tests/qemuxml2argvdata/qemuxml2argv-input-xen.xml 7 Jul 2008 09:11:57 -0000 @@ -4,9 +4,9 @@ <memory>219200</memory> <currentMemory>219200</currentMemory> <vcpu>1</vcpu> + <bootloader>/foo</bootloader> <os> <type>xen</type> - <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Jul 07, 2008 at 10:16:16AM +0100, Daniel P. Berrange wrote:
On Sat, Jul 05, 2008 at 08:01:52PM +0100, John Levon wrote:
On Sat, Jul 05, 2008 at 05:51:50PM +0100, Daniel P. Berrange wrote:
The below patch makes a significant update to libvirt.rng to bring it into line with reality. This is an incremental improvement rather than a full fix. In particular, various parts are still under-specified (e.g. qemu char devices).
This version lets almost all of the XML files in tests/ validate. I'd appreciate help getting the last few to validate - any volunteers?
Very cool ! Thanks ! At ne point i was tempted to add a checking against the RNG when running 'make check' but the sytax was too much in flux to be realistic at the time. Now that all the XML backend is being uniformized (we will have to refactor OpenVZ code too BTW) it starts to make sense adding it. For a virsh command I think it's fine, the main difficulty is to make sure we have a good hardcoded path for the rng file when 'make install' is done and that the packaging includes the file. The other option would be to include the .rng at compile time but it's less generic though more reliable.
Sure - what command are you using to validate ?
xmllint --noout --relaxng docs/libvirt.rng foo.xml
Here's a further update which makes all of them pass, except for one which had bogus XML that I've fixed. NB, I've done away with the xenpv/xenfv/kvm split in the top level domain element since this is unsustainable and does not really match what the newer XML parser will allow. [...] </define> <define name='domainName'> <data type='string'> - <param name="pattern">[a-zA-Z0-9_\+\-]+</param> + <param name="pattern">[a-zA-Z0-9_\+\-&]+</param> </data> </define> <define name='genericName'> @@ -708,12 +860,12 @@ </define> <define name='filePath'> <data type='string'> - <param name="pattern">[a-zA-Z0-9_\+\-%./]+</param> + <param name="pattern">[a-zA-Z0-9_\+\-%./&]+</param> </data> </define> <define name='absFilePath'> <data type='string'> - <param name="pattern">/[a-zA-Z0-9_\+\-%./]+</param> + <param name="pattern">/[a-zA-Z0-9_\+\-%./&]+</param> </data> </define> <define name='devicePath'>
yes I added recently one example with various & added to make sure the escaping to/from XML was correctly handled, the other special chars from an XML viewpoint are < > ' and " which i don't think should be supported by libvirt. There is also most of the ASCII chars below ' ' 0x20 which are forbidden in XML and not escapable, i don't think we should try to allow them either. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Jul 07, 2008 at 06:37:25AM -0400, Daniel Veillard wrote:
For a virsh command I think it's fine, the main difficulty is to make sure we have a good hardcoded path for the rng file when 'make install' is done and that the packaging includes the file.
On Solaris, this would be: /usr/share/lib/xml/rng/libvirt.rng (Probably: we've only got /usr/share/lib/xml/dtd/ to date.) regards john
On Mon, Jul 07, 2008 at 01:14:17PM +0100, John Levon wrote:
On Mon, Jul 07, 2008 at 06:37:25AM -0400, Daniel Veillard wrote:
For a virsh command I think it's fine, the main difficulty is to make sure we have a good hardcoded path for the rng file when 'make install' is done and that the packaging includes the file.
On Solaris, this would be:
/usr/share/lib/xml/rng/libvirt.rng
(Probably: we've only got /usr/share/lib/xml/dtd/ to date.)
Neither exist on Fedora / Linux - the closest I see is /usr/share/xml/xhtml/1.0/xhtml1-strict.dtd Thus I'd suggest we install schemas into the generic pkgdatadir /usr/share/libvirt/schemas/{domain,network,capabilities,storage}.rng and let OS-distributors either move it, or symlink to this when building their own binary packages. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Jul 07, 2008 at 01:31:37PM +0100, Daniel P. Berrange wrote:
(Probably: we've only got /usr/share/lib/xml/dtd/ to date.)
Neither exist on Fedora / Linux - the closest I see is
/usr/share/xml/xhtml/1.0/xhtml1-strict.dtd
Thus I'd suggest we install schemas into the generic pkgdatadir
/usr/share/libvirt/schemas/{domain,network,capabilities,storage}.rng
and let OS-distributors either move it, or symlink to this when building their own binary packages.
Fine by me (it'd be nice for the image.rng from virt-install to go there too, though) regards john
On Mon, Jul 07, 2008 at 01:42:02PM +0100, John Levon wrote:
On Mon, Jul 07, 2008 at 01:31:37PM +0100, Daniel P. Berrange wrote:
(Probably: we've only got /usr/share/lib/xml/dtd/ to date.)
Neither exist on Fedora / Linux - the closest I see is
/usr/share/xml/xhtml/1.0/xhtml1-strict.dtd
Even that wasn't a given, I had to fight for this a long time ago, but that's history now ;-)
Thus I'd suggest we install schemas into the generic pkgdatadir
/usr/share/libvirt/schemas/{domain,network,capabilities,storage}.rng
and let OS-distributors either move it, or symlink to this when building their own binary packages.
Fine by me (it'd be nice for the image.rng from virt-install to go there too, though)
Since the rng(s) are very specific to libvirt, I really think we need to consider this libvirt data rather than XML data. The fact that we use an XML related technology of encoding and validation is an internal property and we are not proposing general purpose XML data. So something under /usr/share/libvirt/ sounds right, schemas is a proper subdirectory name, so i really agree with the suggestion. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon