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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit aaabb44ac7.
I figured out how to trigger this: it's when scaling is enabled.
To maintain VM aspect ratio, we have to constrain the size of the
viewer widget. When the widget is smaller than the VM window, the
viewport widget is visible. This change made the viewport the default
theme color, rather than black.
Problem is, in the non-scaling case, we don't shrink the viewer
widget but let it expand to fill the whole area. This is necessary
to get the 'Autoresize VM with window' option to work, but is also
simpler in the cdoe. The viewport widget is not visible, and gtk-vnc
and spice-gtk paint the non VM owned areas as black. AFAICT that's not
configurable in any way.
So after this change we have differing behavior for scaled and
non-scaled cases, which is confusing and visually kinda comes off as
a bug.
So this reverts back to the old behavior and explains all this in
a comment.
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>
<os firmware='efi'> is the libvirt official way to do what we
historically implement with `--boot uefi`, and UEFI setup in
virt-manager.
Let's prefer libvirt's official method if the support is advertised
in domcapabilities.
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>
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>
https://listman.redhat.com/archives/virt-tools-list/2022-January/msg00012.html
On xen, a guest reboot will trigger a non-error viewer-disconnected
signal, but we treat it like an error, which makes it difficult to
reconnect to the VM console.
If there's no error message raised, treat the disconnect like a
non-error cases.
Signed-off-by: Cole Robinson <crobinso@redhat.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>
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>
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>
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>
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>
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>
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>
This uncovered some areas in details.py we weren't handling that
the search view unselects the current selection
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Move the VM status and viewer open checks into the default page
path as well, otherwise opening the details dialog for an offline
VM attempts to connect to the inactive VM console and logs backtraces
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>
- Add ui/console.ui for console-pages and below
- Add move auth and graphics unavailable pages to a new subnotebook
- Move all the menubar handling up into vmwindow
- Clarify the control flow as much as I can come up with
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Right now this is tied to widget focus, which is too strong. This
changes it so that say clicking on the window title or toolbar then
allows the user to use Alt+F to trigger the File menu for example.
This roughly matches how virt-viewer works
https://bugzilla.redhat.com/show_bug.cgi?id=1824480
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>
Share the UI for changing all these disk properties:
- shareable
- readonly
- removable
- cache
- discard
- detect zeroes
Move them all under the 'Advanced options' expander in details, and
add the checkbox options to the addhardware wizard.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Refactor the internals to cleanly separate the pieces that fill in
the UI, and the pieces that react to UI state to dynamically show/hide
fields.
Improve spice GL warnings while he are here, and several other minor
fixes
Signed-off-by: Cole Robinson <crobinso@redhat.com>
RAM is rarely changed from the default
heads does not have any explicit virt-manager support
and both are viewable from the XML editor.
So remove the explicit fields for them
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>
In all modern local cases we will be using openFD to get a direct
file descriptor from the VM, so this code should never be triggered
nowadays
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Privatize a bunch of stuff
* Make public API explicit
* Add a few minor public APIs to avoid accessing internal state
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Privatize a lot of stuff
* Separate out many callbacks as thin wrappers around the real code
* Simplify registering EDIT_ handlers
* Organize things better
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is pretty obscure, and if it's problematic then libvirt
or qemu should be throwing an error or otherwise reporting it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Don't have the caller call a validate function, they all catch
errors anyways. Let the build step raise error if there's a problem
Drop some validation checks that libvirt should be performing for us
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Commit <15a9502b7b7a263c4d66ff2b3f31c209f58fe0b4> fixed firmware
detection but incorrectly. It will always show only "UEFI" even if
the firmware auto-selection is not used because the function is_uefi()
checks both the old style and the new auto-selection.
We have to check only for the auto-selection option.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Use single strings with proper placeholders for texts, so there is no
need to join together bits of translated texts.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Turn the menu labels into GTK accelerator strings, so we can parse them
to convert them into a proper user representation.
There is a small behaviour change: the menu items do not have mnemonics
anymore by default.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
It seems that the index is optional, so use a proper string for this
case.
Fixes commit 00fa636682 in this file.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Do not split the error messages and the error details, but rather use a
single string with proper placeholders. This avoids string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use whole strings for the labels of disks, including the bus (if
available), and the index.
There are still generic fallbacks for the disk types not explicitly
handled.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Shortcut all the checks, and directly return the whole string (index
included) to show for floppies.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use a single string with a placeholder for the path to avoid a string
puzzle.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use placeholders for the bus name, and the index; the latter is part of
the string, to avoid a string puzzle.
Also use vmmAddHardware.disk_pretty_bus() to get the proper translated
string of a bus.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use a proper string with placeholders for the controller name and index,
to avoid string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use separate strings for the path case, and for the generic case (i.e.
the version), to avoid string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use a separate string in case it has an associated device to avoid a
string puzzle.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Split the handling of serial, parallel, and console in their own cases,
as the common code is less than the non-common one.
Use separate strings in case the port number is available to avoid
string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Translate the labels for a NIC, both when a MAC address is available and
when it is not.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use separate string in case we have the channel name, and in case we
have the channel type.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
* Add CSS data in config.py and install it
* Strip out all hardcoded colors and use style class annotations
* Fix colors to be more theme appropriate to fix dark theme look
Signed-off-by: Cole Robinson <crobinso@redhat.com>
So that the callback doesn't need to be passed into the init function,
and vmmDetails can call that function directly
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Move the opencoded impl out of virt-manager details.py and into
virtinst, since this is entirely about XML comparison. Add tests for
it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
portgroups are a way to group logical chunks of settings inside
a <network> object. They are a quite advanced feature that I expect
many few users are using, and the ones that are using it are certainly
advanced enough to edit the XML directly.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is pretty obscure, and requires a large amount of UI surface
to handle correctly. Users can use the XML editor if they know they
need or want this.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* disk: bus editing: maybe keep this for the customize wizard, but
it should go away for existing disks, changing it for an existing VM is
definitely a 'shoot yourself in the foot' type of thing for most users
"""
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* UI maxmem and maxcpu notions, and related memballoon and cpu hotplug
operations. These have been in the UI forever but I'm not sure people
actually use them. cpu hotplug has always been a mess, and unless the
user plans ahead by setting a high maxmem value ballooning is only good
for reducing memory. These all sound like advanced usage to me that
just confuses the typical usecase of adding more mem or vcpus to an
offline VM. And the hotplug operations with virsh are simple to invoke.
So I'd like to drop this from the UI
"""
The remaining field sets both max and current memory in the
inactive XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* UI maxmem and maxcpu notions, and related memballoon and cpu hotplug
operations. These have been in the UI forever but I'm not sure people
actually use them. cpu hotplug has always been a mess, and unless the
user plans ahead by setting a high maxmem value ballooning is only good
for reducing memory. These all sound like advanced usage to me that
just confuses the typical usecase of adding more mem or vcpus to an
offline VM. And the hotplug operations with virsh are simple to invoke.
So I'd like to drop this from the UI
"""
The remaining UI field now sets both maximum and current VCPU
allocation.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* network virtualport configuration: this is some really obscure
stuff for configuring VEPA for macvtap devices. I don't think it gets
any usage in practice. I think a smaller subset of this UI is shared
with openswitch config but I believe it's just a single field, we
could keep that even though I don't think many people use it either
"""
This removes it all. The openvswitch piece was not properly wired
up anyways, since it requires setting virtualport type for a bridge.
For users that know they need that, they can add it via the XML
editor.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
The default driver_io value we use seems to be sufficient. It's very
rare to hear that users need to change the value to something
different, and if they do, they are advanced enough users that can
edit the XML directly IMO.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We have lots of spapr-* pretty printing and some magic handling
spread around the codebase. These devices have fallen out of favor
and are rarely used, so drop the special handling
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is another advanced feature with a limited appeal. Users that
know they need this can set it directly with the XML editor
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a very advanced field that is only shown for a quite
advanced disk device='lun' config. Users that know they need this
can easily set the value via the XML editor
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* disk: storage format: this was from before the days when we
storage-ified everything and we could get the disk format wrong, telling
qemu it has a raw image when it's qcow2. shouldn't be needed anymore for
normal virt usage
"""
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* disk: serial: I know this is useful in some cases but seems quite
obscure. I think the XML editor is fine unless there's some common
usecase I'm missing
"""
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was discussed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
tlsPort is an advanced config feature. With the XML editing support,
it's less important to have this as a first class UI element. Users
that know they need this setting can set it directly in the XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Removing this was discussed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
For a decade, qemu and xen and virt-manager work together to
make setting a manual keymap redundant. Advertising it in the UI does
more harm than good, because users may think they need to specify
one when in the vast majority of cases it will give worse behavior.
With the XML editing UI, users still have a way to do this by hand
if they really know what they are doing.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
