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
How was that VM created?
(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.
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?
(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?
(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.
(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.
note https://gerrit.ovirt.org/106845 has been reverted for now
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?
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)
Should be tested with libvirt 8.0 as per 1808499
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.
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.