Connect dialog from remote-viewer is now in its own file.
Most other dialog also have their own files.
This will make changing the dialog into a window easier.
Renamed connect_dialog to remote_viewer_connect_dialog.
This is part of a small re-factoring that will have all connection
errors, when we won't be able to connect regardless of what changes on
the remote host, being treated by virt_viewer_app_initial_connect(),
avoiding weird behaviors as we have nowadays (like more than one error
dialog being shown or having the virt-viewer waiting forever for a guest
that will never show up).
Related: rhbz#1085216
Since the error is propagated to the main, report the error there.
To make it work GError VIRT_VIEWER_ERROR_FAILED is set for all
failing states and it is reported using virt_viewer_app_simple_message_dialog().
This applies for:
libvirt authentication dialog (e.g. virt-viewer --attach guest)
'recent connection' dialog (e.g. remote-viewer)
'vm choose' dialog when connecting without specifying the vm name
This is done by using a new GError VIRT_VIEWER_ERROR_CANCELLED.
If a remote oVirt VM don't specify a port/secure port number, we'd still
try to pass it down to spice-gtk, which would then complain that 0 (the
default value) isn't a valid port number.
This commit make sure we filter out the default port/secure-port value
and pass NULL to spice-gtk instead when we get these values.
When using ovirt://, the foreign menu will only be shown in the primary
window after getting notified about OvirtForeignMenu::files (ie when
it managed to fetch some ISO files to show in the foreign menu).
However, for secondary windows, the foreign menu will be added to the
window even if there are no files to show. This commit makes sure we
destroy the window foreign menu whenever it would be empty.
When parsing info returned by oVirt REST API, the hostname should be
present. However, I recently run remote-viewer against a buggy oVirt
instance where the hostname was missing. This commit handles better this
situation by displaying an error message and exiting.
VMs managed by oVirt can be hidden behind a proxy. This commit allows
remote-viewer to make use of this information when it's available
A recent oVirt instance is needed so that it's available through the
REST API, as well as libgovirt 0.3.3 or newer.
With older oVirt/libgovirt versions, the worst that can happen is a
runtime warning in the console, and an impossibility to connect to VMs
behind a proxy, so this commit is not raising the minimum libgovirt
requirement.
It is deprecated since govirt 0.3.1 (and virt-viewer already depends on
govirt 0.3.2).
Silences:
(remote-viewer:19420): libgovirt-WARNING **: Passing a full http:// or https:// URI to ovirt_proxy_new() is deprecated
(remote-viewer:19420): libgovirt-WARNING **: Passing an URI ending in /api to ovirt_proxy_new() is deprecated
This error type isn't really an error, it is used to skip error report
code. The functions can simply return FALSE on failure, without GError
set, to indicate that program should quit normally.
When a user tries to connect to ovirt without specifying
VM name (remote-viewer ovirt://ovirt.example.com) or with
wrong VM name a list of available virtual machines is shown,
and the user may pick a machine he wants to connect to.
The oVirt foreign menu support reused some existing bits from the older
SPICE controller foreign menu code. However, this controller code is
only built when spice-gtk support is built, while the oVirt foreign menu
code could be used with VNC as well. Trying to build the ovirt foreign
menu code without spice-gtk causes build issues due to missing
functions, or missing declarations, ...
The libgovirt/spice-gtk code which is entangled is the code to update
the foreign menu when its content changes, or when a new window is
opened. Making the oVirt-specific code independant from the
spice-gtk-specific code is not too complicated, but this comes at the
expense of a bit of code duplication, but this is only simple code
iterating over the GHashTable storing the opened windows.
Resolves: rhbz#1127156
When the .vv file has an [ovirt] section, we should try to create a foreign
menu out of it. This will allow remote-viewer to offer a menu to change the
currenty inserted cdrom.
Contrary to the ovirt:// case when we already have fetched an OvirtAPI
and OvirtVm instance in order to get the SPICE/VNC connection details,
when working from a .vv file, we'll need to get them from the REST API.
Authentication should happen through the JSESSIONID cookie, if that
fails we want to give up on using the foreign menu, so we don't need to
set up authentication callbacks.
The 'path' part of the URI will always start with a '/' when present as
this is what separates it from the hostname. When rebuilding the final
URI, the current code inserts a '/' by itself between the hostname and
the path, which results in URIs with an extra '/':
https://ovirt.example.com//some/path/api
This is not only cosmetic as this can cause issues with cookie handling
if libgovirt accesses //some/path/api while the cookie is set for
/some/path/api.
When the user launches remote-viewer with an ovirt URI of the form
ovirt://user@host/vmname
Pre-populate the authentication dialog with the specified username. We
don't support specifying the password on the commandline, since that is
a potential security risk.
rhbz#1061826
Coverity warns that 'type' can sometimes be used or free after already having
been freed. This can happen when open_recent_dialog is true and we jump back up
to the retry_dialog label. To prevent this, make sure the freed variables are
set to NULL after freeing.
Recent spice servers send the guest vm name and uuid to the client. We can use
these values to display the proper vm name in the window title if a title is not
specified on the commandline. We can also be smarter about the title in
virt-viewer as well.
If a title is specified on the comamndline (-t/--title=foo), we use that. If not,
we fall back to the vm name. If that is empty, we fall back to the uri of the
connection.
Comparison between old behavior and new behavior
Using new spice-server
Command Old title New title
------- --------- ---------
remote-viewer -t xyz spice://host:port xyz xyz
remote-viewer spice://host:port spice://host:port <vmname>
virt-viewer <vmname> <vmname> <vmname>
virt-viewer <uuid> <uuid> <vmname>
Using old spice-server
Command Old title New title
------- --------- ---------
remote-viewer -t xyz spice://host:port xyz xyz
remote-viewer spice://host:port spice://host:port spice://host:port
virt-viewer <vmname> <vmname> <vmname>
virt-viewer <uuid> <uuid> <vmname>
remote-viewer behaviour is currently inconsistent in the connection dialog:
if the user enters a valid URI, but then remote-viewer fails to connect
to it, then we'll show again the connection dialog through a call
to virt_viewer_app_start() in remote_viewer_deactivated(). If instead we
enter an invalid URI in the connection dialog, then remote-viewer will
report an error and quit.
This commit makes sure in the latter case, we report the error and show
again the connection dialog. The user can press 'Cancel' in the
connection dialog to get out of remote-viewer as in this case, we
return directly FALSE rather than going through the cleanup: label
and looping.
remote_viewer_deactivated() can be calling virt_viewer_app_start()
without checking whether it returns TRUE or FALSE. It returns FALSE
when it was not successful (when it failed to parse the URI to connect
to for example, or whe the user presses Cancel in the connection dialog).
This means that if the user starts remote-viewer, enters a valid URI
in the connection dialog to which it cannot connect to
(spice://example.com:999) and then presses Cancel in the connection
dialog that appears after the connection failure, then remote-viewer
will be sitting there with an empty window doing nothing.
This commit ensures we chain to the parent class when
virt_viewer_app_start() returns FALSE, which causes remote-viewer to
exit.
When using the connection dialog, if the user picks an invalid
URI first causing a failed connection, and then picks/enters a valid
URI, remote-viewer window title will be set to the first invalid URI,
not to the second one which was entered.
As the user may have specified a window title to use on the command
line (-t option), we need to be careful not to override that when
setting the window title on the second attempt.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1024309
Remove the distinction between --full-screen and --full-screen=auto-conf. Just
make --full-screen behave like auto-conf did. There's really no advantage to
having two slightly different fullscreen startup modes.
The CA certificate to use to authenticate the various hosts in
an oVirt instance can be fetched from https://ovirt.example.com/ca.crt.
However, the gio API we are using does not seem to be checking the
server-side certificate of ovirt.example.com before connecting to it,
which could lead to man-in-the-middle attacks. Now that the CA
certificate to use can be specified from the command line using
--ovirt-ca-file, we can remove this automatic fetching of the CA
certificate.
libgovirt 0.3.0 and newer can be passed from the commandline a CA
certificate to use during SSL communications. This commit adds support
for this option to remote-viewer.
When starting remote-viewer with no argument, a connection dialog
is shown. If the URI the user types in this dialog as trailing
or leading spaces, then connection will fail because remote-viewer
will keep them as if they were significant.
This commit makes sure we remove spaces at the beginning/end of
the URI before trying to use it.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1024199
For some VMs, setting host subject on SpiceSession is needed to
be able to connect to it using SPICE/SSL. Until recently, this
was not exposed in oVirt REST API/libgovirt. Since
oVirt 3.2/libgovirt 0.1.0, the host subject is available, this
patch makes use of it.
This should fix connection to oVirt VMs that were migrated to a
different host than the one they were started on.
The controller "auto-display-res" flag should be use to reconfigure
guest to match client configuration. This is what the
--fullscreen=auto-conf option is already made for.
https://bugzilla.redhat.com/show_bug.cgi?id=967154
