Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1418187

Summary:	Engine should stop sending the "display" legacy parameter to VDSM as part of the VM create api
Product:	[oVirt] ovirt-engine	Reporter:	Sharon Gratch <sgratch>
Component:	BLL.Virt	Assignee:	Shahar Havivi <shavivi>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Israel Pinto <ipinto>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.1.0	CC:	bugs, tjelinek
Target Milestone:	ovirt-4.2.0	Flags:	rule-engine: ovirt-4.2+ rule-engine: planning_ack+ rule-engine: devel_ack+ mavital: testing_ack+
Target Release:	4.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-20 11:10:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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:
100%

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

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

Results:
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.