On the contrary, we should reject creating such pool in the code. Having a space as a pool name doesn't make much sense.

(In reply to Peter Krempa from comment #1)
> On the contrary, we should reject creating such pool in the code. Having a
> space as a pool name doesn't make much sense.

Should we reject creating volume/guest/network/snapshot..（all objects) with such name? 
Seem libvirt accept whitespce as objects name.


# virsh vol-list " " 
 Name                 Path                                    
------------------------------------------------------------------------------
                      /var/lib/libvirt/images/null2/  
# virsh list 
 Id    Name                           State
----------------------------------------------------
 7                                    running

# virsh net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
                      inactive   no            yes
# virsh snapshot-create-as 7 " " 
Domain snapshot   created

Pools are abstract, so we control what they are named.  Volumes can come from the filesystem, so we pretty much have to allow anything except for . and .., and probably reject /.  Network names have to match rules for network devices, so that's probably also a place to reject odd names.  Guest names with leading dots are also awkward, as it leads to hidden logs.

One problem is that because we weren't conservative in the beginning about rejecting odd names, people may have already used them.  If we start rejecting it now, and a person upgrades libvirt, then their resource may suddenly stop working - and that's not nice.  We'd have to have a plan in place for back-compat for accessing and renaming any resource whose name is rendered invalid by tightened rules.  On the other hand, tightening rules can be a good thing - just because you CAN use a stupid name with odd characters doesn't mean you SHOULD.

Moving to 7.3

Move to consideration for 7.4

The "original issue" related to virt-xml-validate for storage_pool is no longer an issue because bz1475250 and libvirt commit id '5d7659027' altered the schema from 'genericName' (which didn't allow spaces, but did allow '\n') to one that more closely resembled the domain name processing.

I've posted some patches related to the remaining discussion that will add checking for newly defined/created storage pools, domain names, network names, nwfilter names, secret names, and snapshot names to disallow usage of all "white space" as a name - this includes any combination of "space" and/or "tab" characters as the entire name.

The initial patches do not include similar logic for interfaces or node devices, since those are system based/generated and wouldn't have a name completely composed of white space. I also did not include storage volumes since it's possible someone could have created a file with a name of all white space even though it's a bit unusual or dangerous (and not our problem to solve).

See:
https://www.redhat.com/archives/libvir-list/2018-July/msg02046.html

As of:
commit 5d7659027fdc34a042af3094d3d02a0d823272c2
Author:     John Ferlan <jferlan>
CommitDate: 2017-10-05 08:10:46 -0400

    docs,rng: Adjust storage pool name grammar checks                                                                                                                
                                                                                                                                               
git describe: v3.8.0-36-g5d7659027f contains: v3.9.0-rc1~230

Space is an allowed character in pool name.

I don't see a compelling reason to prevent the user from using such inconvenient names.

*** This bug has been marked as a duplicate of bug 1475250 ***