Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1721804

Summary: Improve VM name validation
Product: [oVirt] ovirt-engine Reporter: Germano Veit Michel <gveitmic>
Component: BLL.VirtAssignee: Michal Skrivanek <michal.skrivanek>
Status: CLOSED CURRENTRELEASE QA Contact: meital avital <mavital>
Severity: low Docs Contact:
Priority: low    
Version: 4.3.0CC: ahadas, bugs, michal.skrivanek, mprivozn, msekleta, rbarry, rdlugyhe, sgoodman, srosenbe
Target Milestone: ovirt-4.4.1Flags: pm-rhel: ovirt-4.4+
pm-rhel: devel_ack+
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Before this update libvirt did not support launching virtual machines with names ending with a period, even though the Manager did. This prevented launching virtual machines with names ending with a period. With this update, the Administration Portal and the REST API now prevent ending the name of a virtual machine with a period, resolving the issue.
Story Points: ---
Clone Of:
: 1808499 (view as bug list) Environment:
Last Closed: 2020-07-08 08:27:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1808499    
Bug Blocks:    

Description Germano Veit Michel 2019-06-19 05:45:16 UTC
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

Comment 1 Michal Skrivanek 2019-06-20 06:05:12 UTC
How was that VM created?

Comment 2 Germano Veit Michel 2019-06-20 08:39:26 UTC
(In reply to Michal Skrivanek from comment #1)
> How was that VM created?

Both Admin Portal and API allow creating VM with the invalid name "test.", or renaming existing VM to it.

Comment 3 Steven Rosenberg 2020-02-10 09:42:36 UTC
Does libvirt plan on supporting a period at the end of a VM Name? If so then the validation would not be necessary. Why are we not supporting a period at the end of a name, but support periods anywhere else within the VM Name?

Comment 4 Michal Privoznik 2020-02-10 13:33:50 UTC
(In reply to Steven Rosenberg from comment #3)
> Does libvirt plan on supporting a period at the end of a VM Name? If so then
> the validation would not be necessary. Why are we not supporting a period at
> the end of a name, but support periods anywhere else within the VM Name?

This is not a libvirt limitation rather than machined one which I suppose has the limitation because of their NSS plugin? Michal?

Comment 5 Michal Sekletar 2020-02-20 11:44:58 UTC
(In reply to Michal Privoznik from comment #4)
> (In reply to Steven Rosenberg from comment #3)
> > Does libvirt plan on supporting a period at the end of a VM Name? If so then
> > the validation would not be necessary. Why are we not supporting a period at
> > the end of a name, but support periods anywhere else within the VM Name?
> 
> This is not a libvirt limitation rather than machined one which I suppose
> has the limitation because of their NSS plugin? Michal?

Yes, it is a limitation on systemd-machined side, though, not due to NSS. We expect machine name to be a valid hostname or valid FQDN and "test." is neither.

Comment 6 Steven Rosenberg 2020-02-20 13:46:28 UTC
(In reply to Michal Sekletar from comment #5)
> (In reply to Michal Privoznik from comment #4)
> > (In reply to Steven Rosenberg from comment #3)
> > > Does libvirt plan on supporting a period at the end of a VM Name? If so then
> > > the validation would not be necessary. Why are we not supporting a period at
> > > the end of a name, but support periods anywhere else within the VM Name?
> > 
> > This is not a libvirt limitation rather than machined one which I suppose
> > has the limitation because of their NSS plugin? Michal?
> 
> Yes, it is a limitation on systemd-machined side, though, not due to NSS. We
> expect machine name to be a valid hostname or valid FQDN and "test." is
> neither.

Thank you for your response and for your confirmation.

Comment 7 Michal Skrivanek 2020-02-28 13:29:02 UTC
note https://gerrit.ovirt.org/106845 has been reverted for now

Comment 8 Michal Privoznik 2020-02-28 16:27:18 UTC
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?

Comment 9 Michal Skrivanek 2020-02-28 16:31:34 UTC
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 10 Steven Rosenberg 2020-04-21 08:05:04 UTC
Should be tested with libvirt 8.0 as per 1808499

Comment 11 Qin Yuan 2020-04-21 12:11:28 UTC
Verified with:
libvirt-6.0.0-17.module+el8.2.0+6257+0d066c28.x86_64
vdsm-4.40.13-1.el8ev.x86_64
rhvm-4.4.0-0.33.master.el8ev.noarch

Tested the following scenarios, all passed:
1. Create a new vm 'test.' and start it on Admin portal.
2. Change an existing inactive vm's name to 'vmvm.', and start it on Admin portal.
3. Create a new vm 'vmtest.' and start it via engine API.

Comment 12 Sandro Bonazzola 2020-07-08 08:27:16 UTC
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.1 release, it has been closed with a resolution of CURRENT RELEASE.

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