Bug 1128763

Summary: [RFE] move .vv files generation to backend, return .vv file in REST API when requesting VM ticket with "Accept: application/x-virt-viewer" header
Product: Red Hat Enterprise Virtualization Manager Reporter: David Jaša <djasa>
Component: ovirt-engineAssignee: Tomas Jelinek <tjelinek>
Status: CLOSED ERRATA QA Contact: Shira Maximov <mshira>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.4.0CC: ederevea, gklein, iheim, istein, juan.hernandez, juwu, lbopf, lpeer, michal.skrivanek, nsednev, oourfali, rbalakri, Rhev-m-bugs, sherold, tjelinek, vszocs, yeylon, ykaul
Target Milestone: ovirt-3.6.0-rcKeywords: FutureFeature, Triaged
Target Release: 3.6.0Flags: sherold: Triaged+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
The REST API can be used now to retrieve the complete .vv file with console connection information, allowing easier scripting of connecting to virtual machine graphical consoles.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-09 20:36:31 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:
Bug Depends On:    
Bug Blocks: 1132506    

Description David Jaša 2014-08-11 13:55:43 UTC 
Description of problem:
It would be nice to move .vv file generation to backend so that apps built on top of REST API don't have to reinvent the wheel and generate it itself. Pretty nice way to get the file through the API would IMO be by recognition of "Accept: application/x-virt-viewer" MIME type on /api/VM_UUID/ticket - API would then ask backend for complete .vv file instead of just password and return the .vv file verbatim in the response body in case of success.

Version-Release number of selected component (if applicable):
RHEV/oVirt 3.4

How reproducible:
always

Steps to Reproduce:
1. set "Accept: application/x-virt-viewer" HTTP header to /api/VM/ticket request
2. 
3.

Actual results:
HTTP Status 406 - No match for accept header

Expected results:
.vv file is returned

Additional info:
Vojtech (in CC) considered this idea even cooler than myself :)
Comment 2 Juan Hernández 2014-10-17 14:58:48 UTC 
Einav, why does this block GUI over REST API? If I understand correctly currently the GUI generates the .vv file itself, and sends it to a GUI specific servlet that echoes it back. This can continue working that way with or without support from REST API.

I'm not saying that this shouldn't be implemented in the REST API, just that in my opinion it doesn't block GUI over REST API.
Comment 3 Einav Cohen 2014-10-17 15:09:00 UTC 
(In reply to Juan Hernández from comment #2)
> Einav, why does this block GUI over REST API? If I understand correctly
> currently the GUI generates the .vv file itself, and sends it to a GUI
> specific servlet that echoes it back. This can continue working that way
> with or without support from REST API.
> 
> I'm not saying that this shouldn't be implemented in the REST API, just that
> in my opinion it doesn't block GUI over REST API.

forwarded you an e-mail about this issue. please read it and remove this BZ from the rest-api-gaps tracker if you think that this is the correct thing to do. thanks.
Comment 4 Juan Hernández 2014-10-17 15:11:34 UTC 
Understood, no need to remove it. Thanks.
Comment 6 Max Kovgan 2015-06-28 14:13:03 UTC 
ovirt-3.6.0-3 release
Comment 9 Nikolai Sednev 2015-07-21 13:25:27 UTC 
Worked also for me.

executed on my laptop:
curl -k -u admin@internal:1 -H "Content-Type: application/xml" -H "Accept: application/x-virt-viewer" -X GET https://nsednev-he-3.qa.lab.tlv.redhat.com/ovirt-engine/api/vms/106990be-83a2-486f-95a5-6bf4daeb79cc/graphicsconsoles/5350494345 > /tmp/out.vv ; remote-viewer /tmp/out.vv

Executed on these components:
Host:
rpm -qa vdsm* sanlock* qemu* mom* libvirt* ovirt* gluster*
glusterfs-fuse-3.7.2-3.el7.x86_64
libvirt-python-1.2.8-7.el7_1.1.x86_64
libvirt-daemon-kvm-1.2.8-16.el7_1.3.x86_64
vdsm-python-4.17.0-1054.git562e711.el7.noarch
glusterfs-api-3.7.2-3.el7.x86_64
libvirt-client-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-storage-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-network-1.2.8-16.el7_1.3.x86_64
vdsm-gluster-4.17.0-1054.git562e711.el7.noarch
sanlock-3.2.2-2.el7.x86_64
qemu-kvm-common-ev-2.1.2-23.el7_1.3.1.x86_64
glusterfs-libs-3.7.2-3.el7.x86_64
libvirt-lock-sanlock-1.2.8-16.el7_1.3.x86_64
ovirt-vmconsole-host-1.0.0-0.0.master.20150616120945.gitc1fb2bd.el7.noarch
sanlock-lib-3.2.2-2.el7.x86_64
vdsm-cli-4.17.0-1054.git562e711.el7.noarch
glusterfs-3.7.2-3.el7.x86_64
qemu-kvm-ev-2.1.2-23.el7_1.3.1.x86_64
glusterfs-geo-replication-3.7.2-3.el7.x86_64
libvirt-daemon-driver-nwfilter-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-interface-1.2.8-16.el7_1.3.x86_64
ovirt-vmconsole-1.0.0-0.0.master.20150616120945.gitc1fb2bd.el7.noarch
mom-0.4.5-2.el7.noarch
ovirt-hosted-engine-setup-1.3.0-0.0.master.20150623153111.git68138d4.el7.noarch
vdsm-xmlrpc-4.17.0-1054.git562e711.el7.noarch
ovirt-engine-sdk-python-3.6.0.0-0.15.20150625.gitfc90daf.el7.centos.noarch
qemu-kvm-tools-ev-2.1.2-23.el7_1.3.1.x86_64
glusterfs-client-xlators-3.7.2-3.el7.x86_64
libvirt-daemon-driver-nodedev-1.2.8-16.el7_1.3.x86_64
vdsm-4.17.0-1054.git562e711.el7.noarch
sanlock-python-3.2.2-2.el7.x86_64
glusterfs-cli-3.7.2-3.el7.x86_64
libvirt-daemon-config-nwfilter-1.2.8-16.el7_1.3.x86_64
ovirt-host-deploy-1.4.0-0.0.master.20150617062825.git06a8f80.el7.noarch
vdsm-jsonrpc-4.17.0-1054.git562e711.el7.noarch
qemu-img-ev-2.1.2-23.el7_1.3.1.x86_64
glusterfs-server-3.7.2-3.el7.x86_64
libvirt-daemon-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-secret-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-qemu-1.2.8-16.el7_1.3.x86_64
ovirt-hosted-engine-ha-1.3.0-0.0.master.20150615153650.20150615153645.git5f8c290.el7.noarch
vdsm-infra-4.17.0-1054.git562e711.el7.noarch
vdsm-yajsonrpc-4.17.0-1054.git562e711.el7.noarch
Red Hat Enterprise Linux Server release 7.1 (Maipo)

Engine:
rpm -qa ovirt*
ovirt-host-deploy-java-1.4.0-0.0.master.20150617062845.git06a8f80.el6.noarch
ovirt-engine-restapi-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-userportal-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-iso-uploader-3.6.0-0.0.master.20150618073905.gitea4158a.el6.noarch
ovirt-engine-wildfly-overlay-001-2.el6.noarch
ovirt-engine-lib-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-setup-base-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-vmconsole-proxy-helper-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-dbscripts-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-tools-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-setup-plugin-ovirt-engine-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-webadmin-portal-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-backend-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-extensions-api-impl-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-extension-aaa-jdbc-1.0.0-0.0.master.20150616142746.git03b5d8b.el6.noarch
ovirt-image-uploader-3.6.0-0.0.master.20150128151752.git3f60704.el6.noarch
ovirt-host-deploy-1.4.0-0.0.master.20150617062845.git06a8f80.el6.noarch
ovirt-engine-wildfly-8.2.0-1.el6.x86_64
ovirt-engine-setup-plugin-ovirt-engine-common-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-setup-plugin-vmconsole-proxy-helper-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-websocket-proxy-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-setup-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-engine-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
ovirt-release-master-001-0.9.master.noarch
ovirt-engine-sdk-python-3.6.0.0-0.15.20150625.gitfc90daf.el6.noarch
ovirt-engine-cli-3.6.0.0-0.3.20150623.git53408f5.el6.noarch
ovirt-engine-setup-plugin-websocket-proxy-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch
Red Hat Enterprise Linux Server release 6.7 (Santiago)
Comment 11 errata-xmlrpc 2016-03-09 20:36:31 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/RHEA-2016-0376.html