Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1091688 - [SDK]: Update VM OS type from RHEL to Win7 fail on required domain name.
Summary: [SDK]: Update VM OS type from RHEL to Win7 fail on required domain name.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-sdk
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.5.0
Assignee: Juan Hernández
QA Contact: Ilanit Stein
URL:
Whiteboard: infra
: 1091858 1111128 1131932 (view as bug list)
Depends On:
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-04-27 09:59 UTC by Ilanit Stein
Modified: 2019-03-22 07:14 UTC (History)
15 users (show)

Fixed In Version: rhevm-sdk-python-3.5.0.0-1.el6_5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-11 21:13:32 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)
logs (deleted)
2014-04-27 10:02 UTC, Ilanit Stein
no flags Details
sdk vm os type update failure reproduce output (deleted)
2014-04-29 12:29 UTC, Ilanit Stein
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0183 normal SHIPPED_LIVE rhevm-sdk-python bug fix and enhancement update 2015-02-12 01:36:21 UTC
oVirt gerrit 27221 None None None Never
oVirt gerrit 27667 None None None Never
oVirt gerrit 27668 None None None Never

Description Ilanit Stein 2014-04-27 09:59:43 UTC
Description of problem:
Automation test of vms has regression compared to av6.1:
Update VM from RHEL to win7 fail on:

"status: 400
reason: Bad Request
detail: If Domain supplied, Domain name expected to be supplied as well."

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

How reproducible:
It failed for 3 test runs in a role starting this build:
http://jenkins.qa.lab.tlv.redhat.com:8080/view/Compute/view/3.4-git/view/Virt/job/3.4-git-compute-virt-reg_vms-sdk-nfs/105/

Steps to Reproduce:
Try to update a VM from RHEL to windows 7

Full failure:
http://jenkins.qa.lab.tlv.redhat.com:8080/view/Compute/view/3.4-git/view/Virt/job/3.4-git-compute-virt-reg_vms-sdk-nfs/105/testReport/junit/Vms/052-Update%20VM%20OS%20type%20from%20RHEL%20to%20Win7/Update_VM_OS_type_from_RHEL_to_Win7/

Comment 1 Ilanit Stein 2014-04-27 10:02:52 UTC
Created attachment 890197 [details]
logs

Comment 2 Juan Hernández 2014-04-28 08:50:30 UTC
*** Bug 1091858 has been marked as a duplicate of this bug. ***

Comment 3 Juan Hernández 2014-04-28 12:55:26 UTC
What version was this tested with? I just tried to reproduce it with av7 and the following script:

---8<---
#!/usr/bin/python

import ovirtsdk.api
import ovirtsdk.xml

api = ovirtsdk.api.API(
    url='https://rhel.example.com/api',
    username='admin@internal',
    password='******',
    ca_file='/etc/pki/ovirt-engine/ca.pem',
    debug=True)

vm = api.vms.get(name="myvm")
print(vm)

vm.get_os().set_type("windows_7")
vm.update()

api.disconnect()
--->8---

And it works correctly for me.

From the failures in the ART logs it looks that this is what was sent to the engine:

<vm>
    <name>restvm_os_win</name>
    <os type="windows_7"/>
</vm>

So I also tested with the following simple shell script (no SDK in the middle):

---8<---
#!/bin/sh -x

curl \
-k \
-X PUT \
-H "Accept: application/xml" \
-H "Content-Type: application/xml" \
-d "
<vm>
<name>myvm</name>
<os type='windows_7'/>
</vm>
" \
-u admin@internal:****** \
https://rhel.example.com/ovirt-engine/api/vms/7422948b-a399-491c-9374-807306067bee
--->8---

It works fine as well.

Can you repeat the tests with the Python script and report the results?

Comment 5 Ilanit Stein 2014-04-29 12:28:35 UTC
This was run on av7. 

I reproduced it on my local environment, installed with av7.
I tried to update OS from os type="rhel_6x64" to os type="windows_7".

My versions details:
[root@dhcp163-101 ~]# rpm -qa | grep sdk
rhevm-sdk-python-3.4.1.0-1.el6ev.noarch
[root@dhcp163-101 ~]# rpm -q rhevm
rhevm-3.4.0-0.15.beta3.el6ev.noarch

Using your python script (insecure):
--------------------------------------------
#!/usr/bin/python

import ovirtsdk.api
import ovirtsdk.xml

api = ovirtsdk.api.API(
    url='https://rhel.example.com/api',
    username='admin@internal',
    password='123456',
    insecure=True,
    debug=True)

vm = api.vms.get(name="test")
print(vm)

vm.get_os().set_type("windows_7")
vm.update()

api.disconnect()
---------------------------------------------
The output is attached.

Comment 6 Ilanit Stein 2014-04-29 12:29:57 UTC
Created attachment 890784 [details]
sdk vm os type update failure reproduce output

Comment 7 Juan Hernández 2014-04-29 12:57:36 UTC
Ilia, apparently this VM has an "vm_init" data with all fields blank or empty, and that is what is triggering this behavior. Can you check what is the content of the "vm_init" table for this VM?

  select * from vm_init where vm_guid = '61331fdb-03a3-4848-b751-7397f23a0634'

How was this VM created? From a template? Imported? Using cloud-init?

Comment 8 Ilanit Stein 2014-04-29 13:59:36 UTC
My name is Ilanit :-)

1. This VM was created from scratch, and installed with rhel
2. This vm exist in vm_init table (at the bottom):
engine=# select * from vm_init;
                vm_id                 | host_name | domain | authorized_keys | regenerate_keys | time_zone | dns_servers | dns_search_domains | networks | password | winkey | custom_script 
--------------------------------------+-----------+--------+-----------------+-----------------+-----------+-------------+--------------------+----------+----------+--------+---------------
 00000000-0000-0000-0000-000000000000 |           |        |                 | f               |           |             |                    |          |          |        | 
 90950439-143f-4a79-998e-abcb35af41a4 |           |        |                 | f               |           |             |                    | [ ]      |          |        | 
 3baa5b81-f0de-4429-9bf1-cb402dcda033 |           |        |                 |                 |           |             |                    |          |          |        | 
 3601f689-09d7-40ab-b75e-e6b72dca18dc |           |        |                 |                 |           |             |                    |          |          |        | 
 3df39d61-9075-4fe9-a86e-87ff0766b3da |           |        |                 | f               |           |             |                    | [ ]      |          |        | 
 229f5a87-e0ba-466c-b8d1-7cc61a198da0 |           |        |                 | f               |           |             |                    | [ ]      |          |        | 
 4d19341e-4dfd-4aa5-8701-5b7046df6d49 |           |        |                 | f               |           |             |                    | [ ]      |          |        | 
 5f6c6e1a-6097-4538-943c-bbcdaf2f53b7 |           |        |                 | f               |           |             |                    | [ ]      |          |        | 
 61331fdb-03a3-4848-b751-7397f23a0634 |           |        |                 |                 |           |             |                    |          |          |        | 
(9 rows)

Comment 9 Juan Hernández 2014-04-29 16:39:39 UTC
The root cause of this problem is that the version of generateDS.py that we currently use (2.9a) doesn't handle correctly empty elements:

# cat > test.xsd <<.
<xs:schema
  version="1.0"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:complexType name="Domain">
    <xs:complexContent>
      <xs:sequence>
        <xs:element name="name" type="xs:string" minOccurs="0"/>
      </xs:sequence>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="domain" type="Domain"/>

</xs:schema>
.

# cat > test.xml <<.
<domain>
  <name></name>
</domain>
.

With version 2.9a of generateDS.py the empty "name" element is removed when parsing and then rendering the XML document:

# pip install generateDS==2.9a
# generateDS.py -o test.py test.xsd
# python test.py test.xml
<?xml version="1.0" ?>
<domain/>

With version 2.12a of generateDS.py the element is preserved:

# pip install generateDS==2.12a
# generateDS.py -o test.py test.xsd
# python test.py test.xml
<?xml version="1.0" ?>
<domain>
    <name></name>
</domain>

So we need to update to version 2.12a of generateDS.py.

Comment 10 Juan Hernández 2014-05-19 10:06:15 UTC
The version of generateDS.py has been updated. To complete the fix the SDK needs to be regenerated.

Comment 11 Juan Hernández 2014-05-23 13:19:45 UTC
This issue has been fixed in version 3.5.0.0 of the upstream Python SDK. It will be fixed downstream with the next rebase.

Comment 12 Juan Hernández 2014-06-20 08:55:25 UTC
*** Bug 1111128 has been marked as a duplicate of this bug. ***

Comment 13 Juan Hernández 2014-07-03 15:06:43 UTC
This fix is contained in rhevm-sdk-python-3.5.0.0-1.el6_5, already available in brew.

Comment 22 Petter Reinholdtsen 2014-08-20 10:46:59 UTC
Where can I download the rhevm-sdk-python-3.5.0.0-1.el6_5 package?  We have run into a similar problem when trying to update the VM description, and would like to give the new RPM a go.

Comment 23 Juan Hernández 2014-08-20 12:25:17 UTC
*** Bug 1131932 has been marked as a duplicate of this bug. ***

Comment 24 Juan Hernández 2014-08-20 12:26:51 UTC
To workaround the issue the caller can force an update of the domain name right before the update of the VM:

  # This is a workaround for bug 1091688, it can be removed
  # once version 3.5 of the rhevm-sdk-python package is
  # available:
  domain = vm.get_domain()
  if domain is not None and domain.get_name() is None:
    domain.set_name("")
  vm.update()

Comment 25 Ilanit Stein 2014-09-02 12:55:50 UTC
Verified on 3.4 setup av11.2, with ovirt-engine-sdk-python-3.5.0.5-1.20140820.gitc47c189.el6.noarch

Comment 27 errata-xmlrpc 2015-02-11 21:13:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

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

https://rhn.redhat.com/errata/RHBA-2015-0183.html


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