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>
- 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>
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>
- 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>
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>
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>
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>
* Simplify start() and end() function signature
* Drop use of 'basename' and standardize on 'text'
* Add vmmMeter.is_started()
* Add vmmMeter.set_text()
* Fix asyncjob UI to show text in the progress bar
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The current implementation of Secret Service keyring client assumes that
the last component of an item path is integer, which is not true for some
Secret Service server implementations (e.g. KeePassXC). Besides,
the Secret Service API documents advises against recording object path
(not to mentioning parsing it in any way), recommending using lookup attributes
instead[1].
This commit fixes the code to behave in more interoperable way.
- The item path (called "keyid" in code) is no longer parsed and stored anywhere.
- The secret item is looked up in the Secret Service using hvuri and machine
uuid attributes.
- /console-password with (username, keyid) is removed from GSettings
storage. Instead, only username is stored in /console-username.
[1] https://specifications.freedesktop.org/secret-service/latest/ch03.htmlResolves: #237
This makes it more clear that 'path' is really a special designation
with a bunch of complicated logic behind it. It's also easier to
grep for
Signed-off-by: Cole Robinson <crobinso@redhat.com>
And absord device building from addhardware. This moves all the
knowledge to gfxdetails, which saves sprinkling it around in other
places
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Convert to pytest style functions
* Move lots of shared code to our App class
* Reduce dogtail sleep amounts to speed up the whole testsuite
* Improve robustness in a lot of areas
Signed-off-by: Cole Robinson <crobinso@redhat.com>
As part of making virt-manager cooperate better with external viewers,
add an option to disable console autoconnect. When opening a VM window
for a running VM, you'll see a 'Connect to console' button in place
of the spice/vnc viewer. Click that and things proceed like normal.
This is useful to prevent virt-manager from disconnecting a virt-viewer
instance that's already attached to a VM
https://bugzilla.redhat.com/show_bug.cgi?id=1793876
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Move all the menu building to its own class, for clarity
* Rename the menu 'Consoles' since it contains graphical choice as well
* Strip out the VM console duplicate if it exists
* Simplify the code a bit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a quirk of libvirt that the first <device> is usually a
logical duplicate of the first <serial> device. Adjust virt-xml to
understand this quirk and remove both devices at the same time,
like we already do in virt-manager
https://bugzilla.redhat.com/show_bug.cgi?id=1685541
Signed-off-by: Cole Robinson <crobinso@redhat.com>
coreos is going to start using disk serial for ignition disk, so
setting this in the UI for distro testing will become more common
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Allows the user to tweak the XML at the destination, which is already
something that libvirt supports
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Make it explicit that all uses of this is actually the object
name. We already leaked this abstraction in several places so better
to make it explicit. This also communicates to users that this is a
field that is not immutable so it shouldn't be used as a unique key
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Cole Robinson