Bug 1418187 - Engine should stop sending the "display" legacy parameter to VDSM as part of the VM create api
Summary: Engine should stop sending the "display" legacy parameter to VDSM as part of ...
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-4.2.0
: 4.2.0
Assignee: Shahar Havivi
QA Contact: Israel Pinto
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-01 08:46 UTC by Sharon Gratch
Modified: 2017-12-20 11:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-12-20 11:10:26 UTC
oVirt Team: Virt
rule-engine: ovirt-4.2+
rule-engine: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 74308 0 master MERGED core: the display vdsm parameter is deprecated 2017-03-20 11:50:47 UTC

Description Sharon Gratch 2017-02-01 08:46:32 UTC
Description of problem:
When calling the VM.create api, the Engine sends a legacy parameter "display" "with possible values: "qxl" or "vnc.
Only Engine <= 3.6 should use that parameter since from Engine > 3.6 we use the graphic device parameters.
Therefore Engine 4.2 should not send this parameter anymore and VDSM should stop supporting it.

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

How reproducible:

Steps to Reproduce:
1. Run a VM with Run or RunOnce commands
2. Check the parametres sent to VDSM with the VM.create api 

Actual results:
in addition to the graphics device parameters and video device parameters the Engine sends the "display" parameter (VdsProperties.display) which is redundant.

Expected results:
The "display" parameter should be omitted in both Engine side and VDSM side.

Additional info:
Please check if all display* parameters should be omitted (displayPort, displaySecurePort, displayIp etc).

Comment 1 Yaniv Kaul 2017-03-12 12:00:28 UTC
Note that 4.2 should still support 3.6 cluster level, I think (need to get an agreement on this!)

Comment 2 Shahar Havivi 2017-03-20 10:27:22 UTC
(In reply to Yaniv Kaul from comment #1)
> Note that 4.2 should still support 3.6 cluster level, I think (need to get
> an agreement on this!)

Patch will only send the 'display' argument when running VM in 3.6 cluster.

Comment 3 Israel Pinto 2017-09-25 10:28:19 UTC
Verify with:
Software version:4.2.0-0.0.master.20170917124606.gita804ef7.el7.centos

1. Create VM in 4.2 DC 
   Create VM in 3.6 DC
2. Start VM and check create command

In 4.2 the display is not written to the command,
In 3.6 the display is presented
3.6 log:
2017-09-25 13:21:25,920+03 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] (org.ovirt.thread.EE-ManagedThreadFactory-engine-Thread-281) [71c4ab8b-1a94-4044-b699-087fce3dda7a] VM {memGuaranteedSize=1024, smpThreadsPerCore=1, cpuType=Conroe, vmId=e4cbf3b6-5cd3-4f6d-9674-ec43216998e8, acpiEnable=true, tabletEnable=true, vmType=kvm, smp=1, smpCoresPerSocket=1, emulatedMachine=pc-i440fx-rhel7.2.0, smartcardEnable=false, guestNumaNodes=[{memory=1024, cpus=0, nodeIndex=0}], transparentHugePages=true, displayNetwork=ovirtmgmt, vmName=36_BZ, kvmEnable=true, devices=[{type=video, specParams={vgamem=16384, heads=1, vram=8192, ram=65536}, device=qxl, deviceId=b331c0f3-c954-46d2-828c-b3bd9f6865e7}, {type=graphics, specParams={keyMap=en-us}, device=vnc, deviceId=9341ea7b-1188-4a02-b5cc-f17eec163bdd}, {iface=ide, shared=false, path=, readonly=true, index=2, type=disk, specParams={path=}, device=cdrom, deviceId=96df16f6-6891-4fdf-9ab3-3cbddd2df763}, {shared=false, address={bus=0, controller=0, unit=0, type=drive, target=0}, imageID=62b43fe9-128d-4dc3-889d-76f0f7b1c941, format=raw, index=0, optional=false, type=disk, deviceId=62b43fe9-128d-4dc3-889d-76f0f7b1c941, domainID=508550c1-52d1-44dc-bc79-3f04e6898ca1, propagateErrors=off, iface=scsi, readonly=false, bootOrder=1, poolID=f281b116-2c62-4b02-bee1-393235cc0d56, volumeID=7cd3abc0-00bf-4ab7-9713-4a8ebc21825a, specParams={}, device=disk}, {filter=vdsm-no-mac-spoofing, nicModel=pv, filterParameters=[], type=interface, specParams={inbound={}, outbound={}}, device=bridge, linkActive=true, deviceId=a3de9441-784d-4639-b3a6-e645b75f9c35, macAddr=00:1a:4a:16:10:71, network=ovirtmgmt}, {index=0, model=piix3-uhci, type=controller, specParams={}, device=usb, deviceId=4733d30c-350c-408d-bbbb-afec26aa1ed3}, {type=balloon, specParams={model=virtio}, device=memballoon, deviceId=c01ddd28-2a3f-48e9-a2c7-61c090bd8fd6}, {index=0, model=virtio-scsi, type=controller, specParams={}, device=scsi, deviceId=3bae2665-1cc5-4509-92b2-6b5ea7e8bdf7}, {type=controller, specParams={}, device=virtio-serial, deviceId=0bf307a1-3efb-4cd8-aeea-199326a22239}, {model=virtio, type=rng, specParams={source=random}, device=virtio, deviceId=a9e8ab2d-d379-4a9d-9f03-07b18f608072}], custom={}, display=vnc, timeOffset=0, nice=0, maxMemSize=4096, maxMemSlots=16, bootMenuEnable=false, memSize=1024}

Comment 4 Sandro Bonazzola 2017-12-20 11:10:26 UTC
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

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

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