Description of problem: Trying to run the next VM which was imported from VMware and include special characters: centos44%/\&+=?!@#$^*()[] failed with the next engine.log error: 2018-04-01 14:22:29,946+03 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-67) [] EVENT_ID: VM_DOWN_ERROR(119), VM centos44%/\&+=?!@#$^*()[]1 is down with error. Exit message: (domain_definition):2: xmlParseEntityRef: no name <name>centos44%/\&+=?!@#$^*()[]1</name> - another issue with it is that in RHV, only the next special chars are valid: "." "," "_" "-" and importing from external provider is allowing other chars to be included in VM name. - Removing these chars from VM name is solving the "running VM" issue. - At the past there were no issues with running such VM. Version-Release number of selected component (if applicable): rhvm-4.2.2.6-0.1.el7 libvirt-client-3.9.0-14.el7_5.2.x86_64 qemu-kvm-rhev-2.10.0-21.el7_5.1.x86_64 sanlock-3.6.0-1.el7.x86_64 vdsm-4.20.23-1.el7ev.x86_64 virt-v2v-1.36.10-6.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Import VM with special chars from external provider. 2. Run VM 3. Actual results: VM failed to start. Expected results: VM should run, or an appropriate message related to these chars should appear. Additional info: engine.log and vdsm.log attached
Created attachment 1415790 [details] engine.log
Created attachment 1415791 [details] vdsm.log
can you try that?
I could observe at least three problems: - libvirt doesn't permit `/' character in VM name. - `&' is not escaped when passed for the first time to libvirt, so an invalid XML is provided to libvirt. - The second libvirt defineXML call fails, apparently due to changed VM name, perhaps escaping is applied this time. So it looks like at least one XML escaping problem in Vdsm (XML received from Engine looks OK) and the libvirt constraint on `/'.
we'll see if there is anything to backport, hopefully it's not going to be a problem
After speaking with Milan/Michal, let's also run it through validation in the engine. Andrej, can you pick it up from there?
I'm not sure what is the expected behavior now in order to verify this bug. The current behavior when trying to import VM named: RHEL7_2-invalid-name-44%/\&+=?!@#$^*()[]: is: the second import dialog rejects the action when clicking "ok" button with the next "operation canceled" pop-up message: Error while executing action: " RHEL7_2-invalid-name-44%/\&+=?!@#$^*()[]: Can not import VM. The given name contains special characters. Only lower-case and upper-case letters, numbers, '_', '-', '.' are allowed. Attribute: vm.vmStatic.name " Is that the expected behavior in such case?
Yes, that is expected. It should not be possible to import a VM with invalid name, using UI or API. Maybe we could improve the UI, if the popup is too inconvenient, but it works.
Referenced in vdsm v4.30.3 despite this bug is on ovirt-engine
There were fixes in both Vdsm and Engine.
Verified on: ovirt-engine-4.3.0-0.2.master.20181121071050.gita8fcd23.el7.noarch
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.0 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.