Bug 1808499 - Improve VM name validation
Summary: Improve VM name validation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.2
Hardware: x86_64
OS: Linux
medium
low
Target Milestone: rc
: 8.0
Assignee: Michal Privoznik
QA Contact: jiyan
URL:
Whiteboard:
Depends On:
Blocks: 1721804
TreeView+ depends on / blocked
 
Reported: 2020-02-28 16:35 UTC by Michal Privoznik
Modified: 2020-06-15 07:25 UTC (History)
13 users (show)

Fixed In Version: libvirt-6.0.0-11.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1721804
Environment:
Last Closed: 2020-05-05 09:57:51 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:2017 0 None None None 2020-05-05 09:58:51 UTC

Description Michal Privoznik 2020-02-28 16:35:16 UTC
+++ This bug was initially created as a clone of Bug #1721804 +++

Description of problem:

The engine allows VM names that libvirt does not:

2019-06-19 15:32:19,602+10 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ForkJoinPool-1-worker-15) [] EVENT_ID: VM_DOWN_ERROR(119), VM test. is down with error. Exit message: Invalid machine name.

2019-06-19 15:32:49,123+1000 ERROR (vm/2edf431a) [virt.vm] (vmId='2edf431a-075d-4666-8933-4caedb2db0c2') The vm start process failed (vm:937)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 866, in _startUnderlyingVm
    self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2864, in _run
    dom.createWithFlags(flags)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 131, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 94, in wrapper
    return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1110, in createWithFlags
    if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self)
libvirtError: Invalid machine name

Version-Release number of selected component (if applicable):
rhvm-4.3.3.7-0.1.el7.noarch
vdsm-4.30.13-4.el7ev.x86_64
libvirt-4.5.0-10.el7_6.9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create VM named "test."
2. Run it

--- Additional comment from Michal Privoznik on 2020-02-28 17:27:18 CET ---

So after talking with Michal Sekletar in person we were able to come up with a solution. While it's true that machined expects either a valid hostname or valid FQDN, libvirt could try to fix the name it's passing to it. For instance, if the domain is named "test." the dot can be removed and "test" could be passed to machined.

Patch proposed on the upstream list:

https://www.redhat.com/archives/libvir-list/2020-February/msg01138.html

Also, see bug 1790409 which tries to fix similar issue. Michal, can I switch this bug to libvirt or do you want me to clone it?

--- Additional comment from Michal Skrivanek on 2020-02-28 17:31:34 CET ---

That's great!

ideally make a clone please, we have to depend on that new version in the right stream and need a bug for that as well (==this one)

Comment 2 Michal Privoznik 2020-03-13 11:02:05 UTC
Pushed as:

  2695191a44 conf: Don't generate machine names with a dot

v6.1.0-85-g2695191a44

Comment 9 jiyan 2020-03-23 07:34:33 UTC
Reproduced this bug with libvirt-6.0.0-10.module+el8.2.0+5984+dce93708.x86_64.

Version:
kernel-4.18.0-187.el8.x86_64
qemu-kvm-4.2.0-15.module+el8.2.0+6029+618ef2ec.x86_64
libvirt-6.0.0-10.module+el8.2.0+5984+dce93708.x86_64

Steps:
####
1: Create a VM which has . in its name
# cat vm1.xml | grep "<name>"
  <name>vm1.</name>

# virsh create vm1.xml 
error: Failed to create domain from vm1.xml
error: Invalid machine name

####
2: Rename a VM with . in the new name
# cat vm1.xml | grep "<name>"
  <name>vm1</name>

# virsh define vm1.xml 
Domain vm1 defined from vm1.xml

# virsh domrename vm1 vm1.
Domain successfully renamed

# virsh domstate vm1.
shut off

# virsh start vm1.
error: Failed to start domain vm1.
error: Invalid machine name

####
3: Start a VM which has . in its name
# cat vm1.xml | grep "<name>"
  <name>vm1.</name>

# virsh define vm1.xml 
Domain vm1. defined from vm1.xml

# virsh start vm1.
error: Failed to start domain vm1.
error: Invalid machine name

Comment 10 jiyan 2020-03-23 07:35:19 UTC
Verified this bug with libvirt-6.0.0-14.module+el8.2.0+6069+78a1cb09.x86_64.

Steps:
1: Update libvirt 
# yum update libvirt* -y

# rpm -qa libvirt
libvirt-6.0.0-14.module+el8.2.0+6069+78a1cb09.x86_64

# systemctl restart libvirt

####
2: Create a VM which has . in its name
# cat vm1.xml | grep "<name>"
  <name>vm1.</name>

# virsh create vm1.xml 
Domain vm1. created from vm1.xml

# virsh list --all
 Id   Name   State
----------------------
 3    vm1.   running

# machinectl list
MACHINE    CLASS SERVICE      OS VERSION ADDRESSES
qemu-3-vm1 vm    libvirt-qemu -  -       -        

1 machines listed.

####
3: Rename a VM with . in the new name
# cat vm1.xml | grep "<name>"
  <name>vm1</name>

# virsh define vm1.xml 
Domain vm1 defined from vm1.xml

# virsh domrename vm1 vm1.
Domain successfully renamed

# virsh start vm1.
Domain vm1. started

# virsh list --all
 Id   Name   State
----------------------
 2    vm1.   running

# machinectl list
MACHINE    CLASS SERVICE      OS VERSION ADDRESSES
qemu-2-vm1 vm    libvirt-qemu -  -       -        

1 machines listed.

####
4: Start a VM which has . in its name
# cat vm1.xml | grep "<name>"
  <name>vm1.</name>

# virsh define vm1.xml 
Domain vm1. defined from vm1.xml

# virsh start vm1.
Domain vm1. started

# virsh list --all
 Id   Name   State
----------------------
 4    vm1.   running

# machinectl list
MACHINE    CLASS SERVICE      OS VERSION ADDRESSES
qemu-4-vm1 vm    libvirt-qemu -  -       -        

1 machines listed.


All the test results are as expected, move this bug to be verified.

Comment 12 errata-xmlrpc 2020-05-05 09:57:51 UTC
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/RHBA-2020:2017


Note You need to log in before you can comment on or make changes to this bug.