In some setups, it is useful to have Spice input, clipboard, audio, etc.,
but not video, for instance when doing GPU passthrough -- one can
interact inside the VM via Spice rather than USB passthrough, and use
a plugged-in monitor or alternate VM viewers like Looking Glass[1] for
video.
It is already possible to specify a "none" video device by manually
typing into the "Model" combobox and hitting "Apply". Yet, this is
unintuitive. Despite being documented everywhere GPU passthrough is
brought up, in the Looking Glass community we still get ~daily support
requests from users who couldn't figure out how to disable Spice video.
This patch makes "None" an explicit option in the video model combobox,
in the hopes that this is more straightforward for users to get right.
[1]: https://looking-glass.io/
Signed-off-by: Tudor Brindus <contact@tbrindus.ca>
Via the virt-manager UI we aren't converting relative path to
absolute path, even though we do it internally when needed.
We were benefiting from this in the test suite in some ways, so we
need to adjust tests to strip out the dev dir on XML comparison
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is the only one that we get notified when the XML changes,
so it's the only one we can be certain is up to date. Users have
gotten confused about out of date spice info here:
https://bugzilla.redhat.com/show_bug.cgi?id=2027867
Signed-off-by: Cole Robinson <crobinso@redhat.com>
- Remove most use of deprecated stock icons. Without it the UI will
be a lot more ugly in Fedora 36
- Remove deprecated ImageMenuItem usage, convert to regular MenuItem
- Remove most embedded button images
Signed-off-by: Cole Robinson <crobinso@redhat.com>
If the user selects virtiofs when editting or adding a new VM, and
we don't detect that they have shared memory enabled, show
a warning label in the UI pointing them to the Memory screen.
It would be nicer if we did this for them, but to get that totally
correct would require both duplicating libvirt's shared memory
detection logic, and some surgery to the addhw wizard. This is good
enough for now
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We only ever show mapped vs squashed, and the difference is pretty
advanced, so if users need it they can use the XML editor. Upcoming
virtiofs support will also make handling this field more complicated
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Split out tpmdetails.py, following the pattern of fsdetails.py. This
adds more UI editing fields for an already attached TPM.
Move the model and version under an 'Advanced options' expander,
since we should be getting this correct by default.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Adjust the UI to leave the box checked for both host-model and
host-passthrough, but host-passthrough is now what it means when
the user selects it. host-model can still be selected via the
CPU model drop down list
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Have the UI push users more towards better defaults, by discouraging
the 'generic' entry and offering the 'linuxXXXX' entries when their
distro or OS version is not in the list.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Previously we tried to use a combination of distro class and version
number to produce a correct ordering that was independent of the
osinfo short ID. The original intent was to have correct ordering
for Windows entries in the virt-manager UI, since the short ID
values are all over the place.
Nowadays that doesn't really matter, since we weed out old
unsupported entries by default. And in the mean time, our current
sort method gives some weird results like interspersing silverblue
entries with fedora entries.
Using a natural/human sort is simpler and handles things pretty well.
Change the UI to sort by the OS label too which preserves some of
the good behavior of original method
Signed-off-by: Cole Robinson <crobinso@redhat.com>
- Move tooltip to the tree row instead of the finish button
- Some style cleanups
- Add a hack so we can hit it in the test suite
Signed-off-by: Cole Robinson <crobinso@redhat.com>
With virt-manager application, it is possible to add inactive node
devices(eg: mediated device) in host system to guest system. But it is
impossible to start a guest system with inactive node devices. Also,
it is not yet possible to start a node device with virt-manager
application. So, the user cannot use the inactive node devices.
This patch disables the "finish" button and provides a tip, when
inactive node devices are selected. So, it is not possible to add
inactive node devices to the guest system.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
If a domain is edited outside of virt-manager (e.g. via virsh
edit) then this is reflected in the GUI (in the domain HW details
tab). However, if domain title or description is updated outside
of virt-manager (virsh desc) then this change is not reflected.
This is simply because the corresponding event emitted by libvirt
is not listened to.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
With virt-manager application, it is possible to add inactive node
devices(eg: mediated device) in host system to guest system. But it is
impossible to start a guest system with inactive node devices. Also,
it is not yet possible to start a node device with virt-manager
application. So, the user cannot use the inactive node devices.
This patch disables the "finish" button and provides a tip, when
inactive node devices are selected. So, it is not possible to add
inactive node devices to the guest system.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
After checking with qemu devs, this option is not really recommended
for common usage and doesn't get used much in practice. So I don't
think it is suitable for the UI
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Make it clear in code and UI that this is x86 only. Other arches
either require UEFI (aarch64) or don't support it
* Drop the internal 'bios' values since we don't handle them and may
not want them anyways, since when win11 support lands we will need
to explicitly throw an error if the user tries to force bios
* Add UI tests
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Possible values are BIOS (default) and UEFI.
The firmware used is determined by libvirt unless a specific firmware is
selected from the Customize dialog.
See https://bugzilla.redhat.com/show_bug.cgi?id=1997882
This reverts commit aaabb44ac7.
I figured out how to trigger this: it's when scaling is enabled.
To maintain VM aspect ratio, we have to constrain the size of the
viewer widget. When the widget is smaller than the VM window, the
viewport widget is visible. This change made the viewport the default
theme color, rather than black.
Problem is, in the non-scaling case, we don't shrink the viewer
widget but let it expand to fill the whole area. This is necessary
to get the 'Autoresize VM with window' option to work, but is also
simpler in the cdoe. The viewport widget is not visible, and gtk-vnc
and spice-gtk paint the non VM owned areas as black. AFAICT that's not
configurable in any way.
So after this change we have differing behavior for scaled and
non-scaled cases, which is confusing and visually kinda comes off as
a bug.
So this reverts back to the old behavior and explains all this in
a comment.
Let users choose libvirt's os.firmware=efi setting in the UI, putting
it about the firmware path list, since it's the preferred default
these days.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
<os firmware='efi'> is the libvirt official way to do what we
historically implement with `--boot uefi`, and UEFI setup in
virt-manager.
Let's prefer libvirt's official method if the support is advertised
in domcapabilities.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This replaces the pattern:
Guest.set_uefi_path(Guest.get_uefi_path())
With a single entrypoint
Guest.enable_uefi()
to immediately change the guest config to use UEFI, using our
default logic.
This will make it easier to change that logic in the future, like
using <os firmware='efi'> instead of hardcoded paths
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I removed Portgroup UI in 4c3c53f773 release 3.0.0, but there's been
a steady stream of requests to bring it back. It seems it's commonly
used with some certain openvswitch config.
Maint burden isn't too bad. Let's bring it back
Fixes: https://github.com/virt-manager/virt-manager/issues/169
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Strip back the logic to:
* Only try to toggle source_type=memfd and access_mode=shared
* Disable the field if guest has any <numa> config
* Disable the field if domcaps does not report virtiofs and memfd
This is the simplest future proof case, though it will exclude some
legit guest configs and some libvirt+qemu back compat.
My feeling is the <numa> stuff in particular is pretty advanced, so if
users have it configured they can toggle shared memory via the XML
without too much trouble.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The virtiofs in domcapabilities is used as a proxy to tell us whether
libvirt is new enough to allow bare memory access mode=shared', So We
enable/disable this checkbox according to it.
When we configure shared memory access, If the 'memfd' is available in
domcaps, We configure VM to use it as memory backend because it doesn't
need addtional host setup for vhost-user devices, Otherwise use 'file'
as backend.
If all of numa nodes explicitly defined memAccess=shared, We mark this
checkbox as checked even if virtiofs isn't exposed in domcapabilities.
In this case:
- It doesn't matter what the value of access mode of memoryBacking is
because access mode of memoryBacking will be overridden per numa node
by memAccess attribute.
- Although the checkbox is disabled, the checked checkbox presents actual
status about shared memory access to users.
Signed-off-by: Lin Ma <lma@suse.com>
Both these windows versions are now longer supported, and UEFI isn't
the default, so I don't think this hack is much needed anymore
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Apparently nodedev drm XML can link to a parent device that we can't
look up?
We shouldn't be trying to do the full address string compare anyways,
so just try the name lookup, which would improve the error here too
Fixes: #328
Signed-off-by: Cole Robinson <crobinso@redhat.com>
https://listman.redhat.com/archives/virt-tools-list/2022-January/msg00012.html
On xen, a guest reboot will trigger a non-error viewer-disconnected
signal, but we treat it like an error, which makes it difficult to
reconnect to the VM console.
If there's no error message raised, treat the disconnect like a
non-error cases.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
... with the 'hypervisor default' address. In this case, we need to
force set port=-1 in the XML, to make the changes actually stick
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The MDEV devices listed in the "Add New Virtual Hardware" page, are a
concatenation of parent device name and MDEV device name, eg:
css_0_0_0014 mdev_b204c698_6731_4f25_b5f4_894614a05ec0_0_0_0014. The
parent name is duplicated in here, as the MDEV device name itself includes
a part of the parent name in libvirt version 7.8.0 and later. So, this patch
changes the MDEVs listed in "Add New Virtual Hardware" page to only display
the MDEV device
name(eg:mdev_b204c698_6731_4f25_b5f4_894614a05ec0_0_0_0014), when the
new naming convention is used.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Submitted in https://github.com/virt-manager/virt-manager/pull/241
I couldn't get this code to change the output, tested with VNC and
spice-gtk on Fedora 34 gnome-shell x11 and XFCE. Maybe it's something
theme related. But either way this doesn't seem to be useful for the
default case anyways, so let's drop it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Cole Robinson