The 1.2.0 release of GtkVnc introduces support for remote desktop
resize. This is also supported in QEMU >= 6.0.0 when using virtio-gpu.
This introduces support for resize without forcing a new min version of
GtkVnc by just checking for existance of the new API. We don't attempt
to check if the current QEMU instance supports resize, as we gracefully
degrade - the guest simply won't resize and will be rendered as before.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
I haven't seen the implementation that needs prompt confirmation here,
though, so I haven't really tested it. The code path is pretty much the
same as in Delete, though, which I did test.
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
First, Item.Delete never accepted any arguments, so this code likely
never worked.
Second, Item.Delete might return a Prompt object, which client
is supposed to call if keyring wants to confirm deletion.
This is the first version that universally treats a None value as
bool False. Most recent code changes have been developed against this
version of pygobject, and several backwards incompatible None usages
have slipped in, and I suspect there's more lurking.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The code doesn't work as expected. From python documentation:
x and y
is the same as
x if not x or y
so in the code if for some reasone `dev` is None the value stored in
`sensitive` will be None as well.
No the code itself works with pygobject >= 3.31.3 where they allowed
None as a valid boolean value, but with older versions it will fail
with this error message:
TypeError: Argument 1 does not allow None as a value
Resolves: https://github.com/virt-manager/virt-manager/issues/226
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This pops up randomly sometimes for reasons I can't determine yet.
logging this will help narrow it down when it does crop up
Signed-off-by: Cole Robinson <crobinso@redhat.com>
- Prefer ayatana if it's available, since that's the modern library
- Fix some pylint and code coverage issues
Signed-off-by: Cole Robinson <crobinso@redhat.com>
AyatanaAppIndicator3 is the successor or AppIndicator3 it uses the same API for the time being
Just try to load AyatanaAppIndicator3 in addition of AppIndicator3
Fixes: #181
Make it work more like gfxdetails. The problem with the current
approach is that it requires effectively rebuilding the whole device
to match the original device when we want to edit a single field,
which is error prone.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
If something would normally be shown only in a label, just
hide the row entirely. This was interesting for viewer XML
properties before we had the XML editor, but now it doesn't
add much
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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>
Leaked connection may mean the app keeps libvirtd socket activated
daemon running for longer than necessary, so it's useful to report
this
Signed-off-by: Cole Robinson <crobinso@redhat.com>
On a fresh install where no previous connection has been made a
non-root user starting virt-manager won't find the installed libvirtd
because the location is not in the user path.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Charles Arnold <carnold@suse.com>
We were leaving the ISO field populated with whatever the old value
was. This is likely useful in some cases but it's consistent with
how we handle fields in the rest of the wizard, and has some weird
interaction with OS detection
Fixes: #159
Signed-off-by: Cole Robinson <crobinso@redhat.com>
delete and createvm tests launch a dialog which obstructs the
manager UI. The location can be kinda random, and it might obstruct
selecting the connection in the manager window. Go back to using
the drag() window pattern to make this more deterministic
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>
Commit 1689ebb25 removed what I thought was an unused audio
handle in the spice viewer code, but apparently it does
something. Strangely some VMs work fine (linux, windows 7),
but my windows 10 VMs need this to actually get audio.
No clue what that's all about
https://bugzilla.redhat.com/show_bug.cgi?id=1881080
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Don't process events when the window isn't showing
* Only update console/details if that tab is actually selected.
Otherwise in some corner cases we can connect to the VM console
while on the details page
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is an awkward place to put it, and I'm pretty sure it's not
even useful in the non-events case nowadays due to improved
libvirtobject.py infrastructure
Signed-off-by: Cole Robinson <crobinso@redhat.com>
In weird corner cases this can trigger tracebacks, if the boot
page is refreshed while the hardware list changed underneath us.
This is a step in the direction of unwinding it.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Historically we have not advertised host-passthrough because it was
not recommended for general usage. That stance is softening,
tools like gnome-boxes already set it as the default, and users
continue to ask about it.
We may change the default in virt-manager but it will take more
discussion. This is a tiny move in the direction of hiding it less
than we already do.
Drop the label for host-model and call it by its libvirt XML name,
since otherwise it's hard to tell which combo choice is for each
value
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Inspired by some discussion from here:
https://bugzilla.redhat.com/show_bug.cgi?id=1759454
Most libvirt storage volume creation doesn't actually do anything
with allocation, besides interpreting cap == alloc and cap != alloc.
The exceptions are zfs volumes, and raw file volumes. But it's unclear
what the usecase is for the latter at all.
This drops the allocation spinner and adds checkbox in its place
'Allocate entire volume now'. When enabled, it sets cap == alloc.
We only show this for file volumes. For qcow2 it defaults to unselected
(sparse), for all others it defaults to selected. If it's not showing,
it defaults to selected.
Bundled with this change is showing this field for qcow2, where
we previously only allowed nonsparse here. Libvirt and qemu-img
support non-sparse qcow2 these days.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1759454
See 15a6a7e210
The idea behind virt-manager's sparse vs nonsparse default, is that if
the user selected 'raw' for as the default image format, assume they
want to maximize performance, so fully allocate the disk.
qcow2 didn't support anything except sparse, so the sparse=True vs
sparse=False made no difference. So we always set sparse=False
Then qcow2 grows non-sparse support, and virt-manager is suddenly
defaulting to it, which is not the intention.
Default to sparse when requested format isn't raw
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is another preference that was added before anyone ever asked
for it. I'm fine with suggesting users remove the device manually
if they don't want it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Remove the preference option to disable this. This was added with
the initial usbredir support because I was afraid people would
complain. They did complain, but only about the auto redir behavior
of the spice client. We still have a toggle to disable that behavior
If people don't want usbredir devices, I'm comfortable telling
them to remove them manually, or use virt-install
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>
This is hiding useful stuff. It was enabled once upon a time because
it was too noisy but let's see if it gets bad like the past
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Instead of using the title of the dialog and prepending the connection
label, create a new title as a single string. This way it is possible to
translate this title as single sentence.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use a single label to show the single sentence describing the available
space on the storage pool. This avoids the use of 3 different labels,
partially translated separately, and whose content cannot be moved.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Latest libvirt uses socket activation, so libvirtd.service in
offline state does not indicate a problem necessarily.
Also on Fedora nowadays we have a weak RPM dependency on
libvirt-daemon which we didn't in the past.
Both things combine to make this code less useful and less accurate,
so let's remove most of it.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Cole Robinson