IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
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.
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.
Remote sound works fine these days. If people want to turn the
preference off, they probably want to do it in all cases, and can
'customize before install' to alter the rest.
This unfortunately has a decent amount of fallout: add a wrapper class
in config.py that reduces much of the churn.
Another big piece is that gsettings can't accept arbitrary paths like
gconf would, everything needs to be described in the schema.
Also do a bunch more RPM spec modernizing
