Bug 1198725 - engine VM doesn't start deploying from disk or appliance
Summary: engine VM doesn't start deploying from disk or appliance
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-hosted-engine-setup
Version: 3.6
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.6.0
Assignee: Simone Tiraboschi
QA Contact: Nikolai Sednev
URL:
Whiteboard: integration
Depends On:
Blocks: 1198138 1234915
TreeView+ depends on / blocked
 
Reported: 2015-03-04 17:16 UTC by Simone Tiraboschi
Modified: 2015-11-04 13:50 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Due to regression from other patches, the engine VM wasn't starting deploying from the appliance. Fixing it.
Clone Of:
Environment:
Last Closed: 2015-11-04 13:50:48 UTC
oVirt Team: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 38389 0 master MERGED packaging: setup: fixing VM parameters type when read from an OVF file Never
oVirt gerrit 38417 0 master MERGED packaging: setup: handling previously generated answerfile with wrong types Never

Description Simone Tiraboschi 2015-03-04 17:16:31 UTC
Description of problem:
Engine VM doesn't start deploying from disk or appliance

Version-Release number of selected component (if applicable):
3.6.0 master

How reproducible:
100%

Steps to Reproduce:
1. try to deploy from disk
2.
3.

Actual results:
it always fails with:
 [ INFO  ] Creating VM
 [ ERROR ] Failed to execute stage 'Closing up': The VM is not powering up: please check VDSM logs
 [ INFO  ] Stage: Clean up

In the VDSM logs you can find:
  Traceback (most recent call last):
    File "/usr/share/vdsm/virt/vm.py", line 1207, in _startUnderlyingVm
      self._run()
    File "/usr/share/vdsm/virt/vm.py", line 2208, in _run
      domxml = hooks.before_vm_start(self._buildDomainXML(), self.conf)
    File "/usr/share/vdsm/virt/vm.py", line 2027, in _buildDomainXML
      return domxml.toxml()
    File "/usr/share/vdsm/virt/vmxml.py", line 459, in toxml
      return self.doc.toprettyxml(encoding='utf-8')
    File "/usr/lib64/python2.7/xml/dom/minidom.py", line 58, in toprettyxml
      self.writexml(writer, "", indent, newl, encoding)
    File "/usr/lib64/python2.7/xml/dom/minidom.py", line 1752, in writexml
      node.writexml(writer, indent, addindent, newl)
    File "/usr/lib64/python2.7/xml/dom/minidom.py", line 817, in writexml
      node.writexml(writer, indent+addindent, addindent, newl)
    File "/usr/lib64/python2.7/xml/dom/minidom.py", line 807, in writexml
      _write_data(writer, attrs[a_name].value)
    File "/usr/lib64/python2.7/xml/dom/minidom.py", line 296, in _write_data
      data = data.replace("&", "&amp;").replace("<", "&lt;"). \
  AttributeError: 'int' object has no attribute 'replace'

Expected results:
it deploys the VM

Additional info:

Comment 1 Sandro Bonazzola 2015-03-05 13:22:09 UTC
Please check if this affects also 3.5.

Comment 2 Simone Tiraboschi 2015-03-05 14:07:46 UTC
(In reply to Sandro Bonazzola from comment #1)
> Please check if this affects also 3.5.

The issue it that we were handling MEM_SIZE_MB as an int while VDSM expects a string and so we get weird behavior.
In 3.5 it wasn't a problem cause we generated a config file via a template for vdsClient and so we had implicit string conversion.
In 3.6 we are using vdscli and so we are skipping the temporary file from the template and from there the issue.
The only possible issue still open is if you run 3.6 deploy script with an answer file wrongly generated by 3.5. I'm going to fix it also converting wrong types from previously generated answer files.

Comment 3 Sandro Bonazzola 2015-03-05 14:16:53 UTC
Ok, moving back to post then, waiting for the new patches.

Comment 4 Nikolai Sednev 2015-05-11 12:15:56 UTC
Hi Simone,
Can you please provide the link to OVA or ISO image with 3.6 engine appliance, so I could verify this bug?

Comment 5 Simone Tiraboschi 2015-05-11 12:21:27 UTC
You can download master OVA from here:
http://jenkins.ovirt.org/view/00%20Unstable%20Jobs%20(Production)/job/ovirt-appliance-engine_master_merged/

Comment 7 Simone Tiraboschi 2015-05-11 16:07:11 UTC
You need to use cloud-init to set engine password on the appliance; no default password.

The web-admin will not run till you run engine-setup on the appliance to configure it; with a recent (today - https://gerrit.ovirt.org/#/c/40546/ ) patch you could do it automatically from hosted-engine via cloud-init on the first boot.

Having a running VM is enough to verify this.

Comment 8 Nikolai Sednev 2015-05-11 21:02:08 UTC
(In reply to Simone Tiraboschi from comment #7)
> You need to use cloud-init to set engine password on the appliance; no
> default password.
> 
> The web-admin will not run till you run engine-setup on the appliance to
> configure it; with a recent (today - https://gerrit.ovirt.org/#/c/40546/ )
> patch you could do it automatically from hosted-engine via cloud-init on the
> first boot.
> 
> Having a running VM is enough to verify this.

Then lets close this one as verified.

Comment 9 Sandro Bonazzola 2015-11-04 13:50:48 UTC
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.


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