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>
So if the user chooses a different value from Preferences, or
app is built with a different value, default to that in Add Hardware
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I thought tqdm was available everywhere, but it does not seem like
it will be in RHEL9. Revert back to the old urlgrabber copy, now
stored in virtinst/_progresspriv.py. If we ever want to try tqdm
again, we can just revert this commit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Enable virt-manager GUI to support add, edit, remove, hot-plug and
hot-unplug of mediated devices (like DASDs, APQNs and PCIs) in virtual
server.
It is not possible to edit MDEV when a virtual server is in
running state, as this is not supported by libvirt.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
tqdm is an external library that provides a progress bar
implementation. Switch to it and drop our internal copy of the
old urlgrabber progressbar
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 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>
Shalini Chellathurai Saroja