Bug 1475250
Summary: | schema for the pool field in <disk type=volume> does not accept all possible pool names | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | jiyan <jiyan> |
Component: | libvirt | Assignee: | John Ferlan <jferlan> |
Status: | CLOSED ERRATA | QA Contact: | Meina Li <meili> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 7.4 | CC: | dyuan, hhan, jiyan, lmen, meili, pkrempa, rbalakri, shyu, xuzhang, yisun |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-3.9.0-1.el7 | Doc Type: | No Doc Update |
Doc Text: |
undefined
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2018-04-10 10:52:40 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
jiyan
2017-07-26 09:43:43 UTC
I guess the pool name is limited to "[a-zA-Z0-9_\+\-]+" for ages. Just the scheme validation is not consistent when domain/storage is being defined? Lets see John's decision... A <pool> uses : <define name='commonmetadata'> <interleave> <element name='name'> <ref name='genericName'/> </element> where: <define name="genericName"> <data type="string"> <param name="pattern">[a-zA-Z0-9_\+\-]+</param> </data> </define> and a <domain>'s <disk> syntax for a volume is: <define name="diskSourceVolume"> <attribute name="type"> <value>volume</value> </attribute> <optional> <element name="source"> <attribute name="pool"> <ref name="genericName"/> </attribute> so they're using the same 'genericName'. The reason it fails for domain edit and not pool-edit is because the domain XML processing in qemuDomainDefineXMLFlags will cause virDomainDefParseXML to call virXMLValidateAgainstSchema in order to validate the schema. It's the only such call in libvirt, btw. In order to see the invalid schema for the above pool.xml, one can run 'virt-xml-validate' and see that it too would fail: # virt-xml-validate pool.xml pool.xml:2: element name: Relax-NG validity error : Error validating datatype string pool.xml:2: element name: Relax-NG validity error : Element name failed to validate content pool.xml:1: element pool: Relax-NG validity error : Invalid sequence in interleave pool.xml:1: element pool: Relax-NG validity error : Element pool failed to validate content pool.xml fails to validate # If one checks the source for storagePoolDefineXML, they'll find like domains, the "name" can be anything except "\n" (uses virXMLCheckIllegalChars()). So rather than using genericName for the RNG, I'll create a 'poolName' definition to match the 'domainName' definition. That will allow the RNG to be valid. As an aside, having a "." as the first character in the name will cause the file that gets created to be 'hidden' for "normal" directory listings. It's not a problem, just an observation. Anyway, I've posted a patch upstream for his: https://www.redhat.com/archives/libvir-list/2017-September/msg01037.html With a slight adjustment to the original patch to add a check for the '/' character in the exclude regex (since it's not a legal character in pool name anyway), this patch has been pushed: commit 5d7659027fdc34a042af3094d3d02a0d823272c2 (HEAD -> master, origin/master, origin/HEAD, bz1475250_v2) Author: John Ferlan <jferlan> Date: Tue Oct 3 07:14:04 2017 -0400 docs,rng: Adjust storage pool name grammar checks ... It's possible to define and start a pool with a '.' in the name; however, when trying to add a volume to a domain using the storage pool source with a '.' in the storage pool name, the domain RNG validation fails because RNG uses 'genericName' which does not allow a '.' in the name. Domain XML def parsing has a virXMLValidateAgainstSchema which generates the error. The Storage Pool XML def parsing has no call to virXMLValidateAgainstSchema. The only Storage Pool name validation occurs in virStoragePoolDefParseXML to ensure the name doesn't have a '/' in it and in storagePoolDefineXML to call virXMLCheckIllegalChars using the same parameter "\n" as qemuDomainDefineXMLFlags would check after the RNG check could be succesful. In order to resolve this, create a poolName definition in storagecommon.rng that will mimic the domain name regex that disallows a newline character, but add the "/" in the exclude list. Then modify the pool and volume source name definitions to key off that poolName. $ git describe 5d7659027fdc34a042af3094d3d02a0d823272c2 v3.8.0-36-g5d7659027 $ Verified on libvirt-3.9.0-1.el7.x86_64 and qemu-kvm-rhev-2.10.0-4.el7.x86_64. Steps to verify: 1.Prepare pool named '.test' and volume. # cat pool.xml <pool type='dir'> <name>.test</name> <target> <path>/tmp/test</path> </target> </pool> # virsh pool-define pool.xml Pool .test defined from pool.xml # virsh pool-build .test Pool .test built # virsh pool-start .test Pool .test started # virsh vol-list *# Name Path ------------------------------------------------------------------------------ test.raw /tmp/test/test.raw 2. Edit a xml file and the info in disk element is as following, then save and start: ... <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='.test' volume='test.raw'/> <target dev='vdb' bus='virtio'/> </disk> ... # virsh start lmn Domain lmn started # virsh domblklist lmn Target Source ------------------------------------------------ vda /var/lib/libvirt/images/lmn.qcow2 vdb test.raw 3.Prepare pool named '/test'. # cat pool.xml <pool type='dir'> <name>.test</name> <target> <path>/tmp/test</path> </target> </pool> # virsh pool-define pool.xml error: Failed to define pool from pool.xml error: XML error: name /test cannot contain '/' The result is as expected, so move the bug to Verified. 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://access.redhat.com/errata/RHEA-2018:0704 *** Bug 1107420 has been marked as a duplicate of this bug. *** |