Red Hat Bugzilla – Bug 1408823
[z-stream clone - 4.0.7] Unable to set instance type via python SDK without separately setting the console type first
Last modified: 2017-04-03 09:26:51 EDT
+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1396153 +++ ====================================================================== Description of problem: As reported from the customer: ------8<----------- After we import a VM from KVM we have certain operations we need to complete... including setting the Instance Type, Optimizing for Server and picking it's network... However through the API when we attempt to alter the instance type we get an error from RHVM. This will impact our migration of close to 800 VMs over the coming months. --- vms_service = connection.system_service().vms_service() vm = vms_service.list(search='name=' + vm_name) if len(vm) != 1: print 'not found, or duplicate' exit() vm = vm[0] it_service = connection.system_service().instance_types_service().list() vm_instance_type_obj = None for it in it_service: if it.name == vm_instance_type: vm_instance_type_obj = it break if vm_instance_type_obj == None: print 'could not find instant type' exit() # GET OUR VM vm_service = vms_service.vm_service(vm.id) # UPDATE OUR VM vm_service.update( types.Vm( instance_type=vm_instance_type_obj ) ) Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/fabric/main.py", line 743, in main *args, **kwargs File "/usr/local/lib/python2.7/site-packages/fabric/tasks.py", line 427, in execute results['<local-only>'] = task.run(*args, **new_kwargs) File "/usr/local/lib/python2.7/site-packages/fabric/tasks.py", line 174, in run return self.wrapped(*args, **kwargs) File "/Users/ccrawford40/git/capella/uops-systems-code/fabric/builds/rhev_ops.py", line 103, in rhev_dr_import_config instance_type=vm_instance_type_obj File "/usr/local/lib/python2.7/site-packages/ovirtsdk4/services.py", line 24130, in update self._check_fault(response) File "/usr/local/lib/python2.7/site-packages/ovirtsdk4/service.py", line 98, in _check_fault Service._raise_error(response, fault) File "/usr/local/lib/python2.7/site-packages/ovirtsdk4/service.py", line 71, in _raise_error raise Error(msg) ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Cannot edit VM. Cannot set single display device via VNC display.]". HTTP response code is 400. ------8<----------- If the customer first modifies the console from CIRRUS to QXL, the above code snippet works without issues. Similarly, if they perform the following via the SDK, this also works without issue: ------8<----------- vm_service.update( types.Vm( display=types.Display( single_qxl_pci=False ) ) ) vm_service.update( types.Vm( instance_type=vm_instance_type_obj ) ) ------8<----------- Version-Release number of selected component (if applicable): rhevm-4.0.4.4-0.1 How reproducible: Always for customer Steps to Reproduce: 1. Import a VM from KVM 2. Attempt to update the VM's instance type 3. Actual results: Unless the console type is set first (explicitly), then the above error is returned. Expected results: Instance type should be set without error. Additional info: (Originally by jhunsaker)
Python SDK just pass through the values user will set. The issue here is that default values at the engine backend side aren't correctly set based on the values set by the user. Jakub, can you please take a look? (Originally by Ondra Machacek)
Verified with rhevm-4.0.7-0.1.el7ev.noarch. Imported vms from kvm: 1. VM with VNC-CIRRUS chose OS type 'linux' on import menu. Result: Vm imported wth VNC CIRRUS and single pci disalbed. 2. VM with VNC-CIRRUS chose OS type 'other_os' on import menu. Result: Vm imported wth VNC CIRRUS and single pci disalbed. 3. VM with SPICE-QXL chose OS type 'linux' on import menu. Result: Vm imported with SPICE QXL and single pci enabled. 4. VM with SPICE-QXL chose OS type 'other_os' on import menu. Result: Vm imported with SPICE QXL and single pci disabled. All the imports results are correct and expected.
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-2017-0542.html