If python3-libguestfs is installed, virt-manager will use it
automatically to fetch guest OS icons, installed application lists,
and some other details.
In practice though the libguestfs integration usually doesn't work,
because most virt-manager created VMs have disks image in a location
only accessible to root, and our libguestfs usage needs the disks
accessible by the app user.
When it does work, we don't cache the results across app runs, so
libguestfs spawns lots of inspecting VMs every app startup, with
lots of log chatter and CPU spiking.
Then there's the confusion that app behavior can noticeably change
through the install of another package and an app restart.
I think it's simpler from a maintenance perspective to disable this
by default. If we fix those two big issues then maybe we can change
it back in the future
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
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
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>
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>
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>
This was added in 2014 per user request but we never exposed it in the
UI. This is fairly advanced needs from the console viewer IMO and is
better left to console specific tools like virt-viewer, per our
DESIGN.md
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The bash completion file is not a script to be executed directly, but
it is sourced by bash. Hence, remove its shebang.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Fedora has switched to Weblate for translations:
https://fedoraproject.org/wiki/L10N/Translate_on_Weblate
* Remove zanata.xml
* Adjust CONTRIBUTING and appdata links to point to Fedora's weblate
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Starting from version 0.19.6, gettext has native capabilities to extract
from, and merge back translations in AppStream files.
Hence, use xgettext to extract messages, and msgfmt to create AppStream
files with translations; because of this, there no more need to prefix
with underscore the tags to be translated.
Update the gettext required version in INSTALL.md.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Starting from version 0.19, gettext has native capabilities to extract
from, and merge back translations in desktop files.
Hence, use xgettext to extract messages, and msgfmt to create a desktop
file with translations; because of this, there no more need to prefix
with underscore the keys to be translated.
Update the gettext required version in INSTALL.md.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
This adds a field in gsettings and preferences UI to enable
XML editing. It's off by default. The XML tab page is still visible,
but the textview is not editable, and there's a warning at the top:
XML editing is disabled in 'Preferences'.
Only enable it if you know what you are doing.
When the setting is enabled, the warning goes away and the textview
is editable. This puts a roadblock up for people that don't know what
they are doing, but still advertises the feature and keeps the
UI surface difference fairly small between on/off states.
The most of content of this file comes from the output of the command '
register-python-argcomplete $MY-SCRIPT', plus some changes.
For the details about argcomplete, Please refer to
https://pypi.org/project/argcomplete/ or
https://github.com/kislyuk/argcomplete
With this patchset, Users can use completion in bash.
ex:
$ virt-xml --<TAB><TAB>
$ virt-install --disk <TAB><TAB>
$ virt-install --panic model=isa,<TAB><TAB>
$ virt-install --controller model=virtio-scsi,ty<TAB><TAB>
Signed-off-by: Lin Ma <lma@suse.com>
Rather than key it on the library being available. Makes it much
easier to test both modes of behavior.
Fix up a few inspection bugs while I'm in the area, and convert
it to be more singleton like.
We've had multiple requests over the years for something similar. People
might have to connect to multiple IP addresses, or really large hostnames,
that become difficult to distinguish in the UI.
Add a field in the host details page that allows setting a custom name,
and store it in gsettings.
This path hits the qemu monitor, and leads to the virt-manager UI being
locked up when performing asynchronous tasks like creating a snapshot.
So make it opt in for people that want it.
Add a preference for changing the default CPU mode/model. The options are:
- default (whatever virt-manager chooses as the default)
- hypervisor default (no <cpu> block, what we've always done)
- nearest host cpu model (just the 'model' from caps->host->cpu)
- copy host cpu (the entire <cpu> block from caps->host)
The setting only applies to KVM guests, not tested with anything else.
The default is left as is for now (hypervisor default).
copy host CPU will one day use mode='host-model', when it does what
we want. At that point we will probably make it the default
Similar to how we allow disabling disk/net polling, not sure yet what
effect it might have on remote connections, so best to add this option
just to be safe.
Unlike disk/net stats, we enable this checking by default.