Bug 888748

The XML parsers in libvirt are only able to report errors for attributes that they actually know about. This type of problem you describe is only solvable by doing RNG schema validation. This is an age old request. We basically need to make virDomainDefineXML (and similar APIs) have a VIR_DOMAIN_XML_VALIDATE flag to let virsh request the libvirt perform schema validation.

virsh can't do this directly, because it may be connecting to a remote libvirtd, which has different RNG versions than virsh has locally.

*** Bug 1037454 has been marked as a duplicate of this bug. ***

We are not sure how this bug will be fixed, but we found other problem like this also like bug 1037454:
Libvirt will ignore invalid elements when define or edit.

1. edit a defined guest to add removable='on' or removable='off' to a usb disk.
   # virsh edit rhel7
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/t2.img'/>
      <target dev='sdc' bus='usb' removable='on/off'/>
    </disk>
...

and save successfully.

2. but dumpxml can not see the removeable element, that means libvirt ignore the modification.

3. define a new guest with disk:
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/t2.img'/>
      <target dev='sdc' bus='usb' removable='on/off'/>
    </disk>

define successfully, but dumpxml still can not see removable element in it.

But there is conflict from virt-xml-validate:
# virt-xml-validate rt.xml
Relax-NG validity error : Extra element devices in interleave
rt.xml:19: element devices: Relax-NG validity error : Element domain failed to validate content
rt.xml fails to validate

Just for this element, I can see ""removable" attribute value since 1.1.3" from libvirt.org, that means upstream is supporting now, but in downstream not.

Not just for this element, anyone else for example adding test='test' also has the same work flow.

*** Bug 1046516 has been marked as a duplicate of this bug. ***

(In reply to Daniel Berrange from comment #1)
> The XML parsers in libvirt are only able to report errors for attributes
> that they actually know about. This type of problem you describe is only
> solvable by doing RNG schema validation. This is an age old request. We
> basically need to make virDomainDefineXML (and similar APIs) have a
> VIR_DOMAIN_XML_VALIDATE flag to let virsh request the libvirt perform schema
> validation.

Actually, making validation optional with VIR_DOMAIN_XML_VALIDATE would require creating lots of new APIs since most of *DefineXML API do not support flags. I think we could always validate the XMLs passed to *DefineXML APIs. Do know any reason why we should not make validation mandatory?

(In reply to Jiri Denemark from comment #7)
> (In reply to Daniel Berrange from comment #1)
> > The XML parsers in libvirt are only able to report errors for attributes
> > that they actually know about. This type of problem you describe is only
> > solvable by doing RNG schema validation. This is an age old request. We
> > basically need to make virDomainDefineXML (and similar APIs) have a
> > VIR_DOMAIN_XML_VALIDATE flag to let virsh request the libvirt perform schema
> > validation.
> 
> Actually, making validation optional with VIR_DOMAIN_XML_VALIDATE would
> require creating lots of new APIs since most of *DefineXML API do not
> support flags. I think we could always validate the XMLs passed to
> *DefineXML APIs. Do know any reason why we should not make validation
> mandatory?

I can't think of any application I know that is careful enough to ensure they don't pass new XML elements/attributes to older libvirt versions. Until we added the virDomainGetCapabilities() API we didn't even provide apps enough info to tell what features the libvirt they use supports. Even now we have that API, we don't expose enough info in it yet for apps to be able to rely on it to see what XML they can pass. So making schema validation mandatory will almost certainly break the majority of libvirt applications.

Oh right, in that case we need to provide new *DefineXML APIs with flags. Sigh.

I can reproduce this bug on build libvirt-1.1.1-29.el7.x86_64

Verify this bug on build libvirt-1.2.17-3.el7.x86_64

Scenario 1: virsh edit
Edit the guest xml as below:
<pm>
<suspend-to-disk enable='no'/>
<suspend-to-mem enable='yes'/>
</pm>

1) # virsh edit mig2
    error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng
    Extra element pm in interleave
    Element domain failed to validate content

Failed. Try again? [y,n,i,f,?]:

2) # virsh edit mig2 --skip-validate
Domain mig2 XML configuration edited.


Scenario 2: virsh define
Prepare a guest xml as below:
<pm>
<suspend-to-disk enable='no'/>
<suspend-to-mem enable='yes'/>
</pm>

1) # virsh define mig2.xml --validate
error: Failed to define domain from mig2.xml
error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng
Extra element pm in interleave
Element domain failed to validate content

2) # virsh define mig2.xml
Domain mig2 defined from mig2.xml


Scenario 3: virsh create
Prepare a guest xml as below:
<pm>
<suspend-to-disk enable='no'/>
<suspend-to-mem enable='yes'/>
</pm>

1) # virsh create mig2.xml --validate
error: Failed to create domain from mig2.xml
error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng
Extra element pm in interleave
Element domain failed to validate content

2) # virsh create mig2.xml
Domain mig2 created from mig2.xml


Since there are lots of changes for this bug, I don't know if I have enough verification?

It took me a while to notice you used "enable" instead of "enabled" as the attribute name in suspend-to-* elements and that this caused libvirt to refuse to validate the XML (it was OK at first sight) :-)

I think what you did is enough to verify libvirt validates domain XML when asked to do so.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html