Hide Forgot
Description of problem: Current Vdsm master supports two way of configuring the VM display settings: 1. the new, modern and preferred way, is to send a proper Graphics device from the client (Engine). This is the recommended way started from oVirt 3.6.x 2. the old way is to send the top-level configure display parameters. Vdsm will reconstruct and use a graphic device from those. When using the old method, Vdsm fails to report back the correct display parameters. An example of failing creation request is: Thread-212::DEBUG::2016-04-08 15:57:50,512::bindingxmlrpc::1229::vds::(wrapper) client [::1]::call vmCreate with ({'emulatedMachine': 'pc', 'vmId': 'e42fc2a1-1f2d-486f-a478-badecf2c61a7', 'devices': [{'device': 'scsi', 'model': 'virtio-scsi', 'type': 'controller'}, {'device': 'console', 'specParams': {'enableSocket': 'true'}, 'type': 'console', 'deviceId': 'c7dea132-45e6-4c1f-9e35-50a33fedc014', 'alias': 'console0'}, {'index': '2', 'iface': 'ide', 'specParams': {}, 'readonly': 'true', 'deviceId': '5ee7678a-3056-4344-885d-381753e2c3dd', 'address': {'bus': '1', 'controller': '0', 'type': 'drive', 'target': '0', 'unit': '0'}, 'device': 'cdrom', 'shared': 'false', 'path': '/tmp/tmpf75QbS/seed.iso', 'type': 'disk'}, {'index': '0', 'iface': 'virtio', 'format': 'raw', 'bootOrder': '1', 'poolID': '00000000-0000-0000-0000-000000000000', 'volumeID': '30697d80-3603-48d8-8ced-4dd3ed9692d1', 'imageID': '55c490a0-fdd5-4027-8012-4507013c2fe9', 'specParams': {}, 'readonly': 'false', 'domainID': '0150ca3b-083b-4f7c-8567-600cccc3cddb', 'optional': 'false', 'deviceId': '55c490a0-fdd5-4027-8012-4507013c2fe9', 'address': {'slot': '0x06', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x0'}, 'device': 'disk', 'shared': 'exclusive', 'propagateErrors': 'off', 'type': 'disk'}, {'nicModel': 'pv', 'macAddr': '00:16:3e:5e:a6:9f', 'linkActive': 'true', 'network': 'ovirtmgmt', 'filter': 'vdsm-no-mac-spoofing', 'specParams': {}, 'deviceId': 'b2832281-59b7-40ce-8cf8-6bb393e6a9b4', 'address': {'slot': '0x03', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x0'}, 'device': 'bridge', 'type': 'interface'}], 'smp': '4', 'memSize': 4096, 'cpuType': 'SandyBridge', 'spiceSecureChannels': 'smain,sdisplay,sinputs,scursor,splayback,srecord,ssmartcard,susbredir', 'vmName': 'HostedEngine', 'display': 'vnc'},) {} Version-Release number of selected component (if applicable): 4.18.0 (4.0.0 alpha 1) How reproducible: 100% of times in this flow Steps to Reproduce: 1. send command like the above from client (e.g. vdscli, [untested] vdsClient) 2. let Vdsm create the VM 3. check the display parameters using e.g. vdsClient -s 0 list Actual results: Missing display parameters: displayIp, displayPort, displaySecurePort Expected results: Reported correct values for display parameters Additional info: 1. seems to happen using xmlrpc 2. Engine flow seems ok
Created attachment 1145148 [details] vdsm log demonstrating the issue
Created attachment 1145149 [details] output of vdsClient getAllVmStats
Created attachment 1145151 [details] output of vdsClient list
why bother when we're about to drop xmlrpc and anything <3.6?
(In reply to Michal Skrivanek from comment #4) > why bother when we're about to drop xmlrpc and anything <3.6? Only because I heard we'll still need to keep compatibility with 3.5 in 4.0. If turns out we don't need, I'll happily CLOSE/WONTFIX :) Furthermore, I'm not sure Engine 3.6.x is ignoring display* parameters - as it should. I'll take this chance to investigate that.
(In reply to Francesco Romani from comment #5) The final consensus was that we don't need 3.5 in 4.0. So we have one less bug:)
(In reply to Michal Skrivanek from comment #6) > (In reply to Francesco Romani from comment #5) > > The final consensus was that we don't need 3.5 in 4.0. So we have one less > bug:) OK, so this bug could be CLOSED WONTFIX