December 2019 - Devel - libvirt List Archives

[libvirt] [PATCH] docs/auth.html.in: fixed typos
by Andrew Miloradovsky 23 Dec '19

23 Dec '19

Signed-off-by: Andrew Miloradovsky <andrew(a)interpretmath.pw> --- docs/auth.html.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/auth.html.in b/docs/auth.html.in index 62af43a915..c81c1e58ad 100644 --- a/docs/auth.html.in +++ b/docs/auth.html.in @@ -274,7 +274,7 @@ to turn on SASL auth in these listeners. Since the libvirt SASL config file defaults to using GSSAPI (Kerberos), a -config change is rquired to enable plain password auth. This is done by +config change is required to enable plain password auth. This is done by editting <code>/etc/sasl2/libvirt.conf</code> to set the <code>mech_list</code> parameter to <code>scram-sha-1</code>. @@ -317,7 +317,7 @@ in these scenarios - only the plain TCP listener needs encryption Some operating systems do not install the SASL kerberos plugin by default. It may be necessary to install a sub-package such as <code>cyrus-sasl-gssapi</code>. To check whether the Kerberos plugin is installed run the <code>pluginviewer</code> -program and verify that <code>gssapi</code> is listed,eg: +program and verify that <code>gssapi</code> is listed, e.g.: <pre> # pluginviewer @@ -359,7 +359,7 @@ kadmin.local: quit Any client application wishing to connect to a Kerberos enabled libvirt server merely needs to run <code>kinit</code> to gain a user principal. This may well -be done automatically when a user logs into a desktop session, if PAM is setup +be done automatically when a user logs into a desktop session, if PAM is set up to authenticate against Kerberos. </body> -- 2.24.0

2 1

[libvirt] [PATCH] gconfig: Add GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_QEMU_XHCI
by Felipe Borges 23 Dec '19

23 Dec '19

Modern operating systems support qemu-xhci and that's available since libvirt 3.3.x and qemu 2.9.x Signed-off-by: Felipe Borges <feborges(a)redhat.com> --- libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h b/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h index d593764..3f93d7c 100644 --- a/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h +++ b/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h @@ -65,7 +65,8 @@ typedef enum { GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_ICH9_UHCI2, GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_ICH9_UHCI3, GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_VT82C686B_UHCI, - GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_PCI_OHCI + GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_PCI_OHCI, + GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_QEMU_XHCI } GVirConfigDomainControllerUsbModel; GType gvir_config_domain_controller_usb_get_type(void); -- 2.24.1

2 1

[libvirt] [PATCH 0/5] Get rid of "no_memory" labels
by Fabiano Fidêncio 23 Dec '19

23 Dec '19

As pointed out by Ján Tomko, "no_memory seems suspicious in the times of abort()". As libvirt decided to take the path to not report OOM and simply abort when it happens, let's get rid of the no_memory labels and simplify the code around them. The two exceptions are: - phyp code, as libvirt may end up dropping this code entirely; - virfirewall.c code, as it seems we heavily really on firewall->err being set to ENOMEM; If one thinks that virfirewall.c should also be converted, please, shout out and I'll work on that. Fabiano Fidêncio (5): conf: Get rid of "no_memory" labels openvz: Get rid of "no_memory" labels rpc: Get rid of "no_memory" labels util: Get rid of "no_memory" labels vbox: Get rid of "no_memory" labels src/conf/capabilities.c | 16 ++-------- src/conf/domain_audit.c | 40 +++++++------------------ src/openvz/openvz_conf.c | 18 +++++------ src/rpc/virnetclient.c | 42 ++++++++------------------ src/util/virsysinfo.c | 64 +++++++++++++++------------------------- src/util/virsysinfo.h | 2 ++ src/util/viruri.c | 28 +++++++----------- src/vbox/vbox_common.c | 20 +++++-------- 8 files changed, 75 insertions(+), 155 deletions(-) -- 2.24.1

3 7

[libvirt] [PATCH] storage: Fix daemon crash on lookup storagepool by targetpath
by Yi Li 23 Dec '19

23 Dec '19

Causing a crash when storagePoolLookupByTargetPath because of Some types of storage pool have no target elements. Core was generated by `/usr/sbin/libvirtd'. Program terminated with signal 11, Segmentation fault. (gdb) bt 0 0x0000ffff9e951388 in strcmp () from /lib64/libc.so.6 1 0x0000ffff92103e9c in storagePoolLookupByTargetPathCallback ( obj=0xffff7009aab0, opaque=0xffff801058b0) at storage/storage_driver.c:1649 2 0x0000ffff9f2c52a4 in virStoragePoolObjListSearchCb ( payload=0xffff801058b0, name=<optimized out>, opaque=<optimized out>) at conf/virstorageobj.c:476 3 0x0000ffff9f1f2f7c in virHashSearch (ctable=0xffff800f4f60, iter=iter@entry=0xffff9f2c5278 <virStoragePoolObjListSearchCb>, data=data@entry=0xffff95af7488, name=name@entry=0x0) at util/virhash.c:696 4 0x0000ffff9f2c64f0 in virStoragePoolObjListSearch (pools=0xffff800f2ce0, searcher=searcher@entry=0xffff92103e68 <storagePoolLookupByTargetPathCallback>, opaque=<optimized out>) at conf/virstorageobj.c:505 5 0x0000ffff92101f54 in storagePoolLookupByTargetPath (conn=0xffff5c0009f0, path=0xffff7009a850 "/vms/images") at storage/storage_driver.c:1672 Signed-off-by: Yi Li <yili(a)winhong.com> --- src/storage/storage_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index a33328d..5863e1f 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -1713,6 +1713,12 @@ storagePoolLookupByTargetPathCallback(virStoragePoolObjPtr obj, return false; def = virStoragePoolObjGetDef(obj); + + /* Some Storage pool types have no Target elements, + * so we should check it. */ + if (def->target.path == NULL) + return false; + return STREQ(path, def->target.path); } -- 2.7.5

2 3

Re: [libvirt] Add support for vhost-user-scsi-pci/vhost-user-blk-pci
by Cole Robinson 23 Dec '19

23 Dec '19

FYI there's some more recent discussion over here: https://www.redhat.com/archives/libvir-list/2019-December/msg00817.html There isn't any objections to using <disk type='vhostuser'/> for vhost-user-blk, so maybe that's a good place to start. Thanks, Cole On 10/15/19 7:34 AM, Li Feng wrote: > Cole Robinson <crobinso(a)redhat.com> 于2019年10月15日周二上午1:48写道： >> >> On 10/14/19 3:12 AM, Li Feng wrote: >>> Hi Cole & Michal, >>> >>> I'm sorry for my late response, I just end my journey today. >>> Thank your response, your suggestion is very helpful to me. >>> >>> I have added Michal in this mail, Michal helps me review my initial patchset. >>> (https://www.spinics.net/linux/fedora/libvir/msg191339.html) >>> >> >> Whoops I missed that posting, I didn't realize you had sent patches! >> >>> All concern about this feature is the XML design. >>> My original XML design exposes more details of Qemu. >>> >>> <vhost-user-blk-pci type='unix'> >>> <source type='bind' path='/tmp/vhost-blk.sock'> >>> <reconnect enabled='yes' timeout='5' /> >>> </source> >>> <queue num='4'/> >>> </vhost-user-blk-pci> >>> >>> As Cole's suggestion, the better design with all vhost-user-scsi/blk >>> features would like this: >>> >>> vhost-user-blk: >>> >>> <disk type='vhostuser' device='disk'> >>> <source type='unix' path='/path/to/vhost-user-blk.sock' mode='client'> >>> <reconnect enabled='yes' timeout='5' /> >>> </source> >>> <target dev='vda' bus='virtio'/> >>> <queue num='4'/> >>> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> >>> </disk> >>> >>> vhost-user-scsi: >>> >>> <disk type='vhostuser' device='disk'> >>> <source type='unix' path='/path/to/vhost-user-scsi.sock' mode='client'> >>> <reconnect enabled='yes' timeout='5' /> >>> </source> >>> <target dev='sda' bus='scsi'/> >>> <queue num='4'/> >>> </disk> >>> >> >> I think my SCSI idea is wrong, sorry. vhost-user-scsi is for passing a >> scsi host adapter to the VM, correct? If so, then it's not really a >> <disk>, and so using the existing vhost-scsi support in <hostdev> is >> probably better. <hostdev> could possible be used for vhost-user-blk as well >> >> Can you provide some examples of full qemu command lines using >> vhost-user-blk and vhost-user-scsi? Just linking to examples else where >> is fine, but I'm wondering if there's more context > > You could check the vhost-user-scsi/blk examples from SPDK pages: > https://spdk.io/doc/vhost.html > >> >> Internally we already have an abstraction for vhost-scsi: >> >> <hostdev mode='subsystem' type='scsi_host'> >> <source protocol='vhost' wwpn='XXX'/> >> </hostdev> >> >> >> The obvious extension would be >> >> <hostdev mode='subsystem' type='scsi_host'> >> <source protocol='vhostuser' type='unix' >> path='/path/to/vhost-user-scsi.sock' mode='client'/> >> </hostdev> >> >> Internally implementing this will be weird. The <source> parameters are >> only dictated by the hostdev type= field, but in this case they would be >> dictated by the <source protocol=> field, and we would want to reuse the >> internal chardev abstraction. >> >> vhost-user-blk could be implemented similarly, but with type='storage' >> which is the way we pass through block devices to LXC guests, but it >> isn't currently supported in the qemu driver. >> >> I dunno. Maybe Michal or danpb can provide guidance >> > @Michal, @danpb, could you give some guidance? >> >>> Conclusion: >>> 1. Add new type(vhostuser) for disk label; >>> 2. Add queue sub-label for disk to support multiqueue(<queue >>> num='4'/>) or reusing the driver label >>> (<driver name='vhostuser' queues='4'), which one is better? >>> Qemu support multiqueue like this: >>> -device vhost-user-scsi-pci,id=scsi0,chardev=spdk_vhost_scsi0,num_queues=4 >>> -device vhost-user-blk-pci,chardev=spdk_vhost_blk0,num-queues=4 >>> >> >> num-queues is already supported by libvirt for both <disk> and <hostdev> >> with <driver queues=X/>, so whether we use <disk> or <hostdev> you won't >> need to add any new XML here. > Got it. > >> >>> Another question: >>> When qemu is connecting to a vhost-user-scsi controller[1], there may >>> exist multiple LUNs under one target, >>> then one disklabel(<disk/>) will represent multiple SCSI LUNs, >>> the 'dev' property(<target dev='sda' bus='scsi'/>) will be ignored, right? >>> In other words, for vhost-user-scsi disk, it more likes a controller, >>> maybe the controller label is suitable. >>> >> >> Yes you are right, and this was my understanding. But then its not >> really a <controller> in libvirt's sense because we can't attach >> emulated devices to it, so it's more a fit for the existing <hostdev> >> vhost-user support. Unfortunately it's not really a clean fit anywhere, >> there will have to be some kind of compromise. And I'm not sure if >> <disk> or <hostdev> is right for vhost-user-blk, but hopefully others >> have more clear opinions. > > I'm also confused about it. > Thanks for your reply. > > Thanks, > Feng Li > >> >> Thanks, >> Cole >> >>> I look forward to hearing from you as soon as possible. >>> >>> [1]: https://spdk.io/doc/vhost.html >>> >>> Feng Li >>> >>> Cole Robinson <crobinso(a)redhat.com> 于2019年10月10日周四上午6:48写道： >>>> >>>> Sorry for the late reply, and thanks Jano for pointing out elsewhere >>>> that this didn't receive a response. >>>> >>>> On 8/12/19 5:56 AM, Li Feng wrote: >>>>> Hi Guys, >>>>> >>>>> And I want to add the vhost-user-scsi-pci/vhost-user-blk-pci support >>>>> for libvirt. >>>>> >>>>> The usage in qemu like this: >>>>> >>>>> Vhost-SCSI >>>>> -chardev socket,id=char0,path=/var/tmp/vhost.0 >>>>> -device vhost-user-scsi-pci,id=scsi0,chardev=char0 >>>>> Vhost-BLK >>>>> -chardev socket,id=char1,path=/var/tmp/vhost.1 >>>>> -device vhost-user-blk-pci,id=blk0,chardev=char1 >>>>> >>>> >>>> Indeed that matches what I see for the qemu commits too: >>>> >>>> https://git.qemu.org/?p=qemu.git;a=commit;h=00343e4b54b >>>> https://git.qemu.org/?p=qemu.git;a=commit;h=f12c1ebddf7 >>>> >>>>> What type should I add for libvirt. >>>>> Type1: >>>>> <hostdev mode='subsystem' type='vhost-user'> >>>>> <source protocol='vhost-user-scsi' path='/tmp/vhost-scsi.sock'></source> >>>>> <alias name="vhost-user-scsi-disk1"/> >>>>> </hostdev> >>>>> >>>>> >>>>> Type2: >>>>> >>>>> <disk type='network' device='disk'> >>>>> <driver name='qemu' type='raw' cache='none' io='native'/> >>>>> <source protocol='vhost-user' path='/tmp/vhost-scsi.sock'> >>>>> </source> >>>>> <target dev='sdb' bus='vhost-user-scsi'/> >>>>> <boot order='3'/> >>>>> <alias name='scsi0-0-0-1'/> >>>>> <address type='drive' controller='0' bus='0' target='0' unit='1'/> >>>>> </disk> >>>>> >>>>> >>>>> <disk type='network' device='disk'> >>>>> <driver name='qemu' type='raw' cache='none' io='native'/> >>>>> <source protocol='vhost-user' path='/tmp/vhost-blk.sock'> >>>>> </source> >>>>> <target dev='vda' bus='vhost-user-blk'/> >>>>> <boot order='1'/> >>>>> <alias name='virtio-disk0'/> >>>>> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' >>>>> function='0x0'/> >>>>> </disk> >>>>> >>>> >>>> I think wiring this into <disk> makes more sense. <hostdev> is really an >>>> abstraction for assigning a (typically) physical host device to the VM, >>>> so it handles things like hiding a PCI device from the host, and passing >>>> that exact device to the VM. >>>> >>>> In the vhost-user-scsi/blk case, the host device is just a special >>>> process running on the other side of a socket, and the device >>>> represented to the guest is a typical virtio device. So to me it makes >>>> more sense as a <disk> with a <source> that points at that socket. >>>> >>>> target bus=virtio vs bus=scsi is already used to distinguish between >>>> virtio-blk and virtio-scsi, so I think we can keep that bit as is, with >>>> the <address type=drive|pci> to match. We just need to differentiate >>>> between plain virtio and vhost-user >>>> >>>> network devices already have vhostuser support: >>>> >>>> <interface type='vhostuser'> >>>> <source type='unix' path='/tmp/vhost1.sock' mode='server|client'/> >>>> <model type='virtio'/> >>>> </interface> >>>> >>>> Internally that <source> is a virDomainChrSourceDefPtr which is our >>>> internal representation of a chardev. So I think something akin to this >>>> is the way to go. It will likely require updating a LOT of places in the >>>> code that check disk type= field, probably most places that care about >>>> whether type=NETWORK or type=!NETWORK will need to be mirrored for the >>>> new type. >>>> >>>> <disk type='vhostuser' device='disk'> >>>> <source type='unix' path='/path/to/vhost-user-blk.sock' mode='client'/> >>>> <target dev='vda' bus='virtio'/> >>>> </disk> >>>> >>>> <disk type='vhostuser' device='disk'> >>>> <source type='unix' path='/path/to/vhost-user-scsi.sock' mode='client'/> >>>> <target dev='sda' bus='scsi'/> >>>> </disk> >>>> >>>> - Cole >>> >> >> >> - Cole > - Cole

1 0

[libvirt] libvirt API/design questions
by Cole Robinson 23 Dec '19

23 Dec '19

There's some pre-existing libvirt design questions I would like some feedback on, and one new one * `virsh blockresize` doesn't prevent shrink by default, couple users have blown their foot off and there's attempts at patches. https://www.redhat.com/archives/libvir-list/2019-October/msg00258.html https://www.redhat.com/archives/libvir-list/2019-November/msg00843.html Do we implement this as a protection in virsh, or change the API behavior and require a new API flag to allow shrinking? Or some other idea? * vhost-user-scsi and vhost-user-blk XML schema https://www.redhat.com/archives/libvirt-users/2019-October/msg00018.html Last proposal was using <hostdev> for this, which revisiting it now makes more sense than <disk>, because it vhost-user-X doesn't seem to use qemu's block layer at all. So vhost-user-scsi would be: <hostdev mode='subsystem' type='scsi_host'> <source protocol='vhostuser' type='unix' path='/path/to/vhost-user-scsi.sock' mode='client'/> </hostdev> vhost-user-blk maybe requires a new type='block' ? Otherwise it's unclear how to differentiate between the two. Regardless it would be nice to give the original patch author guidance here, they seemed motivated to get this working * Splitting domain_conf up. There's 30k lines in domain_conf.c and 3500 in domain_conf.h, it would be nice to unwind it a bit. Getting some sign off on this ahead of time is critical IMO so pieces can be posted and committed quickly because they will obviously go out of date fast. My thoughts: - domain_def.[ch]: DomainDefXXX and enum definitions. - probably New and Free functions too - domain_parse.[ch]: XML parsing - domain_format.[ch]: XML formatting - domain_validate.[ch]: validate and postparse handling - domain_util.[ch]: everything else, or keep it in domain_conf? domain_def should be easy but no idea how intertwined the rest are. If the domain_validate naming is acceptable for both validate and postparse functions, we could use that naming for qemu_domain.c split too. Also maybe it's worth considering if there's some way to sensibly split the conf/ directory. We could add a top level domain/ directory, but that's kinda ambiguously named as we already have network/ + storage/ + secret/ etc that have different meanings. Maybe sub dirs like conf/domain/ ? I'm curious if anyone has strong feelings either way. There's not really a clear place to dump shared DomainDef code at the moment, like possible domain_cgroup for sharing cgroup handling across lxc + qemu Thanks, Cole

4 5

[libvirt] virsh blockresize syntax is inconsistent with vol-resize and somewhat dangerous
by Tim Small 23 Dec '19

23 Dec '19

Hello, virsh has two commands which can be used to resize block devices - "blockresize" for volumes in use by and active guest, and "vol-resize" for volumes which are not in use. The vol-resize syntax allows to specify the size as a delta (increase or decrease vs. the current size), and also refuses to shrink a volume unless the "--shrink" argument is also passed. Most other tools which can be used for block device resizing (outside of libvirt) also have similar "--shrink" argument requirements when reducing the size of an existing block device. e.g. ceph requires "--allow-shrink" when using the "rbd resize" command. The lack of such a safety device makes "blockresize" a foot-gun (which I recently found to great effect when I typoed the domain name to another valid domain). It seems I am not alone in making this error e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902171 One possible solution would be to make a new command e.g. "domblkresize" or perhaps "live-resize", which implement the "--shrink" and "--delta" behaviour to make it consistent with "vol-resize" syntax, and mark the "blockresize" command as deprecated in the documentation and help (so that existing automation which depends on the current behaviour doesn't break). Any thoughts? Should I open this as an RFE? Thanks, Tim. -- South East Open Source Solutions Limited Registered in England and Wales with company number 06134732. Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309

3 3

[libvirt] [PATCH v5 0/5] qemu_process: Glib sponsored cleanup
by Daniel Henrique Barboza 21 Dec '19

21 Dec '19

changes from previous version 4 [1]: - patch 1: * moved 'dev' inside the for loop in qemuProcessHandleBlockThreshold() * moved 'id' inside the 'for' loop in qemuProcessLookupPTYs() * moved 'path' inside both conditionals in qemuProcessBuildDestroyMemoryPaths() * set 'template=NULL' in case g_mkdtemp() succeeds in qemuProcessQMPInit() - patch 2: new patch. add g_autoptr() support for qemuDomainLogContextPtr - patch 3: * using g_autoptr() on feasible virCommandPtr and * qemuDomainLogContextPtr [1] https://www.redhat.com/archives/libvir-list/2019-December/msg01311.html Daniel Henrique Barboza (5): qemu_process.c: use g_autofree qemu_domain.h: add G_DEFINE_AUTOPTR_CLEANUP_FUNC for qemuDomainLogContext qemu_process.c: use g_autoptr() qemu_process.c: remove cleanup labels after g_auto*() changes qemu_process.c: remove 'cleanup' label from qemuProcessCreatePretendCmd() src/qemu/qemu_domain.h | 1 + src/qemu/qemu_process.c | 445 +++++++++++++++------------------------- 2 files changed, 166 insertions(+), 280 deletions(-) -- 2.24.1

2 6

[libvirt] [PATCH v4 0/4] qemu_process: Glib sponsored cleanup
by Daniel Henrique Barboza 21 Dec '19

21 Dec '19

This series got buried a few months ago. Let's go onward unto the 20s with no one left behind. changes from version 3 [1]: - rebased to master at commit 330b556829 - removed former patch 4. The 'g_strdup_printf' change was made along the road - new patch 4: I am sending this one in separate to patch 3 because this unneeded label was already in the code, being unrelated to the changes of this series. The maintainer is welcome to squash it into patch 3. [1] https://www.redhat.com/archives/libvir-list/2019-October/msg01080.html Daniel Henrique Barboza (4): qemu_process.c: use g_autofree qemu_process.c: use g_autoptr() qemu_process.c: remove cleanup labels after g_auto*() changes qemu_process.c: remove 'cleanup' label from qemuProcessCreatePretendCmd() src/qemu/qemu_process.c | 429 +++++++++++++++------------------------- 1 file changed, 157 insertions(+), 272 deletions(-) -- 2.23.0

3 12

[libvirt] [PATCH] schemas: Allow additional qemu cmd line arguments/env variables and qemuCaps to be interleaved
by Michal Privoznik 21 Dec '19

21 Dec '19

While command line arguments are sort of positional (becasue you have to have two entries, one for "-arg" the other for "value"), it doesn't really matter whether env variables come before or after command line arguments. And it matter even less when playing with qemu capabilities. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/schemas/domaincommon.rng | 54 +++++++++++++++++++---------------- 1 file changed, 29 insertions(+), 25 deletions(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 5f1d4a34a4..b87457382a 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -6295,37 +6295,41 @@ --> <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> + <interleave> + <zeroOrMore> + <element name="arg"> <attribute name='value'/> - </optional> - <empty/> - </element> - </zeroOrMore> + </element> + </zeroOrMore> + <zeroOrMore> + <element name="env"> + <attribute name='name'> + <ref name="filter-param-name"/> + </attribute> + <optional> + <attribute name='value'/> + </optional> + <empty/> + </element> + </zeroOrMore> + </interleave> </element> </define> <define name="qemucapabilities"> <element name="capabilities" ns="http://libvirt.org/schemas/domain/qemu/1.0"> - <zeroOrMore> - <element name="add"> - <attribute name="capability"/> - </element> - </zeroOrMore> - <zeroOrMore> - <element name="del"> - <attribute name="capability"/> - </element> - </zeroOrMore> + <interleave> + <zeroOrMore> + <element name="add"> + <attribute name="capability"/> + </element> + </zeroOrMore> + <zeroOrMore> + <element name="del"> + <attribute name="capability"/> + </element> + </zeroOrMore> + </interleave> </element> </define> -- 2.24.1

3 2