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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Latest upstream release was back in 2012 and the new
libayatana-appindicator project is present in all distribution supported
by libvirt.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
has_install_phase is an ambiguous name for its intended purpose.
Really this is so API users have a way of knowing if the VM `install`
process requires 2 XML phases or not. Make that naming explicit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Trying to size the window based on VM desktop resolution does
not do the correct thing when host fractional scaling is enabled
and using spice.
The best we can do here is ask the viewer widget for its
preferred size
Signed-off-by: Cole Robinson <crobinso@redhat.com>
_adjust_viewer_size has one remaining function: when scaling and
resizeguest is disabled, do
viewer.set_size_request(*desktop_resolution), so the viewer fills
out the scrolled window and scrollbars show up.
After playing with this all a bunch, I discovered two things
* spice already behaves the way we want, so we don't need to
manually intervene. so all that is unnecessary
* vnc has an option to behave the way we want, via the
set_force_size knob
So instead lets rip it all out, and implement the VNC piece by
toggling set_force_size based on whether scaling+resizeguest is
enabled.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Move shared init to `_set_display`
* Move per class init to `_init_display`
* Move per class signal setup to `_connect_display_signals`
* Make base class call cleanup of child class via `_close`
* Drop unnecessary spice `_display_channel` handle
Signed-off-by: Cole Robinson <crobinso@redhat.com>
this doesn't change any behavior, but it makes things cleaner
by not overloading the size-allocate signal
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This does not seem to be required anymore. We get notified on
viewer size-allocate already, which seems like enough.
Rename the function to _adjust_viewer_size which is more accurate
to what it does, and adjust the callers
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This mattered when we were doing widget adjustments to maintain
scaling ratio. But nowadays it seems totally redundant: we are
basically trying to set an allocation that already happened via
the normal chain of widget events, so it's a no-op.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Checking for resolution = None is a roundabout way to check if
the console was already opened. Make that more clear
Signed-off-by: Cole Robinson <crobinso@redhat.com>
+ Don't check for redirdev devices, let the spice widget tell
us if things aren't configured correctly.
+ Remove some duplication
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We can not reliably use VM desktop resolution for host widget
sizes when the host is using desktop scaling, so don't even try.
This fixes the black bars around the VM console when scaling=never
and autoresize is disabled
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Spice has maintained aspect ratio for us forever.
GtkVnc was added in previous commit, provided since May 2021.
If user is running on an old GtkVnc, they just get potentially
stretched out viewing when scaling is enabled, so the fallback
scenario is no big deal IMO
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Right now you can select the option for an offline VM, but once
it starts up, and no spice agent is detected, the option is
set insensitive. This is a pain.
Keep the tooltip, but keep the option always selectable
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We can use this signal to be notified when VM resolution changes.
Log when we actually detect a resolution change
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Current code will take a screenshot when the 'New Snapshot'
dialog is initially launched, and then use that cached content
as the screenshot for the snapshot... which may be totally out
of date by the time the user enters all the snapshot info.
Instead, drop the snapshot preview UI in the 'New Snapshot' wizard
entirely, and use a screenshot that is fetched after the user actually
clicks 'Finish'
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is from when we used to support directly connecting to
serial console /dev/pty devices. Nowadays all serial connections
are mediated through libvirt stream APIs and we don't need to
care about SIGHUP
Signed-off-by: Cole Robinson <crobinso@redhat.com>
If the VM has implicit TPM state, use the VIR_DOMAIN_UNDEFINE_KEEP_TPM
flag to preserve that state when renaming the VM (if libvirt is new
enough).
The state is stored based on VM UUID and nothing else, and the UUID
is preserved during rename, so we don't need to do any of the same
trickery that's required for nvram duplication.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Fix console config validation for an edge case where both libvirt and
Spice/VNC TCP connection are on localhost. Transport over TCP does not
necessarily mean that libvirt connection is to a remote host.
Compare libvirt and graphics device addresses to localhost individually.
Raise an error only when guest device is bound to localhost but libvirt
connection is non-local (remote).
Validation that prevents fully local TCP seems to go back all the way to
bc13c302de4 ("console: Warn if qemu+tcp URI and listen == 127.0.0.1").
Signed-off-by: Sami Loone <sloone@forcepoint.com>
* add_q35_pcie_controllers already skips adding controllers if
any type=pci already exist, so delete the extra checking
* be more paranoid and only run the live edits when the machine
type actually changed from an expected config
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The commit db8305ad explicitly adds pcie-root and pcie root ports for q35.
If the user selects i440FX chipset instead of Q35(default) from customize
dialog, The pre-defined pcie-root and ports cause failure when starting
i440fx VM installation because they're not applicable to i440fx.
It fails with below error message:
summary=Unable to complete install: 'XML error: The PCI controller with index='0'
must be model='pci-root' for this machine type, but model='pcie-root' was found instead'
details=Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/createvm.py", line 2088, in _do_async_install
installer.start_install(guest, meter=meter)
File "/usr/share/virt-manager/virtinst/install/installer.py", line 737, in start_install
domain = self._create_guest(
File "/usr/share/virt-manager/virtinst/install/installer.py", line 679, in _create_guest
domain = self.conn.createXML(initial_xml or final_xml, 0)
File "/usr/lib64/python3.10/site-packages/libvirt.py", line 4442, in createXML
raise libvirtError('virDomainCreateXML() failed')
libvirt.libvirtError: XML error: The PCI controller with index='0' must be
model='pci-root' for this machine type, but model='pcie-root' was found instead
This patch fixes it by removing the pcie-root and ports for i440fx in
apply_overview.
Resolves: https://github.com/virt-manager/virt-manager/issues/444
Signed-off-by: Lin Ma <lma@suse.com>
internal snapshots largely only work if the VM is backed by a single
qcow2 disk. But newly supported external snapshots support other
disk formats, and multiple disks.
Drop the old validation checking. Let's just leave it up to libvirt
to give us an error at snapshot creation time
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Currently, View->Consoles disables the menu items for serial devices
when the VM is offline. This changes that behavior. This is useful,
since it allows you to pre-select serial console before starting the
VM, which can help ensure you don't miss any serial boot output.
It also makes the UI interaction more intuitive.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reproducer:
+ Start VM with 1 graphical and 1 serial console
+ Select serial console
+ Power off VM
+ Open console menu, select 'Graphical' option
+ See errors
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reproducer:
+ Enable libguestfs inspection
+ Open app and VM details 'Overview' window
+ After some time, the `Apply` button is mysteriously activated
+ Trying to switch away from the page will give 'Unapplied errors'
warning box
When libguestfs inspection completes, it triggers a signal which
will refresh the OS info details.py page. Which is fine, but we
should be limiting it to only refreshing the page if its the currently
visible one. Otherwise the `Apply` button can be activated, which
messages up app navigation
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When there's a pool with many vols (files), and user clicks on "Browse" in
VM's Virtual Disk details, the UI could stuck for up to several minutes.
By using DeviceDisk.paths_in_use_by() for bulk getting names, it could
show browser much faster.
The only thing that GtkSourceView gives us is syntax highlighting and
auto-indent. When this library is not available, we can still offer xml
editing with a plain textview with very little lost functionality.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Bring back the `Open` label for `Browse Local` option, but
preserver the SAVE dialog behavior (can enter a manual path)
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Use GtkFileChooserNative [1] instead of GtkFileChooserDialog [2]
to integrate better with the platform (e.g. use the portal
implementation when run with GTK_USE_PORTAL=1, resulting in
the KDE Frameworks implementation being used when
xdg-desktop-portal-kde is in use). Quoting from
the GtkFileChooserDialog doc [2]:
> If you want to integrate well with the platform you should use the
> GtkFileChooserNative API, which will use a platform-specific dialog if
> available and fall back to GtkFileChooserDialog otherwise.
Also replace the use of GTK_STOCK_CANCEL [3] and GTK_STOCK_OPEN [4]
which were deprecated in GTK 3.10:
Both, the `accept_label` and `cancel_label` params of
`Gtk.FileChooserNative.new` can be `None` to use the default
text ("Open", "Cancel"). [5]
Adjust the only caller (in `vmmVMWindow#_takeScreenshot`)
that was passing an explicit label/icon name for the
accept button to pass `_("_Save")` as label, rather than
the also deprecated Gtk.STOCK_SAVE [6].
(GtkFileChooserDialog has special handling for Gtk.STOCK_SAVE
etc., but that's not generally the case for native dialogs).
Rename the method param from `choose_button` to `choose_label`
to make clearer that this is a label.
[1] https://docs.gtk.org/gtk3/class.FileChooserNative.html
[2] https://docs.gtk.org/gtk3/class.FileChooserDialog.html
[3] https://docs.gtk.org/gtk3/const.STOCK_CANCEL.html
[4] https://docs.gtk.org/gtk3/const.STOCK_OPEN.html
[5] http://pygobject-doc.gitee.io/pgi-docs/Gtk-3.0/classes/FileChooserNative.html#Gtk.FileChooserNative.new
[6] https://docs.gtk.org/gtk3/const.STOCK_SAVE.htmlFixes#315
Replace Gtk.Box.add() with Gtk.Box.pack_start() to place the VTE terminal widget. This enables horizontal expansion/filling the terminal widget when resizing the serial console window.
This event is mainly to refresh the VM XML to figure out the state of
virtio channels and that should happen only for running VMs.
This affects external snapshot behavior in virtManager. If the VM is
offline and user deletes external snapshot libvirt needs to start QEMU
process to delete the snapshot. The QEMU process is started with stopped
CPUs so it is visible as online and paused. It also emits the agent
lifecycle event but there is no other domain lifecycle event so after
the snapshot deletion the VM stays paused in virtManager even if it is
already offline in libvirt.
To mitigate this behavior we can ignore agent lifecycle event for
shutoff VMs.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
