Description of problem: Hosted Engine bootstrap the VM on which the Engine will run using vdsm client and the JSON-like configuration format that Vdsm supported since early 3.y versions. Starting from version 4.2, Vdsm can create VMs out of the standard libvirt domain XML, augmented with minimal metadata specific to oVirt. Hosted Engine should switch to the domain XML to configure the Engine's VM. Version-Release number of selected component (if applicable): Any How reproducible: 100% Steps to Reproduce: 1. create the Engine VM Actual results: VM gets created using the legacy JSON-like vm configuration format Expected results: VM gets created using the libvirt domain XML format Additional info: The end result (VM configuration) is expected to be exactly identical, what changes is just how the data is sent to Vdsm
*** Bug 1533524 has been marked as a duplicate of this bug. ***
Verified on ovirt-hosted-engine-setup-2.2.10-1.el7ev.noarch
Blocking this since the VM could fail to start as for https://bugzilla.redhat.com/1560666
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Re-targeting tentatively to 4.2.3
This was basically reverted to workaround a libvirt bug https://bugzilla.redhat.com/show_bug.cgi?id=1547095. The feature has to be re-enabled before we ship a downstream version as quite a lot of other fixes depend on it.
http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-ansible-suite-master/143/artifact/exported-artifacts/test_logs/he-basic-ansible-suite-master/post-he_deploy/lago-he-basic-ansible-suite-master-host0/_var_log/vdsm/vdsm.log it seams that we have another regression with this, at least on master: 2018-04-05 09:27:22,765-0400 ERROR (vm/9bb2deab) [virt.vm] (vmId='9bb2deab-f686-4629-acee-90e2774a66b6') The vm start process failed (vm:945) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 874, in _startUnderlyingVm self._run() File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2832, in _run domxml = hooks.before_vm_start(self._buildDomainXML(), File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2258, in _buildDomainXML return vmxml.format_xml(dom, pretty=True) File "/usr/lib/python2.7/site-packages/vdsm/virt/vmxml.py", line 71, in format_xml stream, encoding='utf-8', xml_declaration=True) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 820, in write serialize(write, self._root, encoding, qnames, namespaces) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 939, in _serialize_xml _serialize_xml(write, e, encoding, qnames, None) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 939, in _serialize_xml _serialize_xml(write, e, encoding, qnames, None) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 939, in _serialize_xml _serialize_xml(write, e, encoding, qnames, None) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 932, in _serialize_xml v = _escape_attrib(v, encoding) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1092, in _escape_attrib _raise_serialization_error(text) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1052, in _raise_serialization_error "cannot serialize %r (type %s)" % (text, type(text).__name__) TypeError: cannot serialize 0 (type int) 2018-04-05 09:27:22,765-0400 INFO (vm/9bb2deab) [virt.vm] (vmId='9bb2deab-f686-4629-acee-90e2774a66b6') Changed state to Down: cannot serialize 0 (type int) (code=1) (vm:1685)
Verified on: ovirt-hosted-engine-setup-2.2.18-1.el7ev.noarch ovirt-hosted-engine-ha-2.2.10-1.el7ev.noarch rhvm-appliance-4.2-20180420.0.el7.noarch ovirt-engine version in the appliance: ovirt-engine-4.2.3.2-0.1.el7.noarch Steps: 1. Deploy HE, and wait until the installation is finished. 2. Force OVF update by editing the HE VM (for example changing memory) 3. Wait a minute until the OVF is updated 4. Set global maintenance mode on the HE and shut down the HE VM 5. Start the HE VM using 'hosted-engine --vm-start' 6. Check VDSM logs, around the VM.create command. Result: Under VM.create the VM XML is printed in a bridge: "... DEBUG (jsonrpc/3) [jsonrpc.JsonRpcServer] Calling 'VM.create' in bridge with {u'vmParams': {u'xml': u'<?xml version=\'1.0\' encoding=\'UTF-8\'?>\n<domain xmlns:ovirt ..." and "... INFO (jsonrpc/3) [api.virt] START create(vmParams={u'xml': u'<?xml version=\'1.0\' encoding=\'UTF-8\'?>\n<domain xmlns:ovirt ..." by comment #7 now the hook passed: 2018-04-26 20:51:55,495+0300 DEBUG (vm/75f93aba) [root] /usr/bin/taskset --cpu-list 0-7 /usr/libexec/vdsm/hooks/before_vm_start/50_hostedengine (cwd None) (commands:65) 2018-04-26 20:51:55,687+0300 DEBUG (vm/75f93aba) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:86) 2018-04-26 20:51:55,688+0300 INFO (vm/75f93aba) [root] /usr/libexec/vdsm/hooks/before_vm_start/50_hostedengine: rc=0 err= (hooks:110) 2018-04-26 20:51:55,688+0300 DEBUG (vm/75f93aba) [root] /usr/bin/taskset --cpu-list 0-7 /usr/libexec/vdsm/hooks/before_vm_start/50_vfio_mdev (cwd None) (commands:65) 2018-04-26 20:51:55,876+0300 DEBUG (vm/75f93aba) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:86) 2018-04-26 20:51:55,876+0300 INFO (vm/75f93aba) [root] /usr/libexec/vdsm/hooks/before_vm_start/50_vfio_mdev: rc=0 err= (hooks:110) 2018-04-26 20:51:55,877+0300 DEBUG (vm/75f93aba) [root] /usr/bin/taskset --cpu-list 0-7 /usr/libexec/vdsm/hooks/before_vm_start/50_vhostmd (cwd None) (commands:65) 2018-04-26 20:51:56,038+0300 DEBUG (vm/75f93aba) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:86) 2018-04-26 20:51:56,039+0300 INFO (vm/75f93aba) [root] /usr/libexec/vdsm/hooks/before_vm_start/50_vhostmd: rc=0 err= (hooks:110) 2018-04-26 20:51:56,039+0300 INFO (vm/75f93aba) [virt.vm] (vmId='75f93aba-949f-49de-bbb9-b71f68e19678') <?xml version="1.0" encoding="utf-8"?><domain type="kvm" xmlns:ns0="http://ovirt.org/vm/tune/1.0" xmlns:ov irt-vm="http://ovirt.org/vm/1.0"> <name>HostedEngine</name> <uuid>75f93aba-949f-49de-bbb9-b71f68e19678</uuid> <memory>4194304</memory> ...
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 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.