Bug 1128763 - [RFE] move .vv files generation to backend, return .vv file in REST API when requesting VM ticket with "Accept: application/x-virt-viewer" header
Summary: [RFE] move .vv files generation to backend, return .vv file in REST API when ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Tomas Jelinek
QA Contact: Shira Maximov
URL:
Whiteboard:
Depends On:
Blocks: 1132506
TreeView+ depends on / blocked
 
Reported: 2014-08-11 13:55 UTC by David Jaša
Modified: 2019-08-15 03:57 UTC (History)
18 users (show)

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.
Clone Of:
Environment:
Last Closed: 2016-03-09 20:36:31 UTC
oVirt Team: Virt
Target Upstream Version:
sherold: Triaged+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 0 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 37972 0 master MERGED engine: Phase 1: Move console options to backend Never
oVirt gerrit 37973 0 master MERGED frontend: Phase 2: Make console clients use ConsoleOptions Never
oVirt gerrit 37974 0 master MERGED engine: Phase 3: Configuring ConsoleOptions on backend Never
oVirt gerrit 37975 0 master MERGED engine: Phase 4: Query for generating console descriptor Never
oVirt gerrit 39057 0 master MERGED restapi: Phase 5: Add graphics console representation Never
oVirt gerrit 39058 0 master ABANDONED restapi: Phase 5: Retrieve console descriptor file Never

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


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