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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
This basically reverts this commit from virt-manager 4.0.0
```
commit 825ec644b8
Author: Cole Robinson <crobinso@redhat.com>
Date: Tue Mar 1 10:32:01 2022 -0500
installer: Do not force reboot with --cloud-init
Resolves: https://github.com/virt-manager/virt-manager/issues/189
```
After that commit, using `--cloud-init` or `--unattended` would
basically imply `--noreboot`
For some usage of `--cloud-init`, like in the initial report, this
makes sense to do. virt-install will drop you into the cloud image,
you mess without, run `poweroff`, and are surprised when virt-install
reboots the VM. I agreed, and made the change
But changing this was a bad idea.
cloud-init and unattended VMs have 2 XML phases. First XML is booting
off temporary media (the generated cloudinit iso), second XML is the
permanent boot config (booting off disk). We need to force the VM
to fully poweroff, so that the second XML config takes effect. We
make that happen with `<on_reboot>destroy</on_reboot>`, which tells
libvirt/qemu to poweroff the VM when it receives a guest reboot
notification. virt-install then defaults to restarting the VM when
it detects shutdown, to manually replicate the VM requested reboot,
but still get the second XML config to take effect.
The perennial problem with this is that, from outside the VM, we
don't know if the user inside the VM requested `poweroff` or `reboot`.
virt-install emulates the reboot behavior, and provides `--noreboot`
to override it. It's still confusing if a user puts a `poweroff`
command at the end of an anaconda kickstart file, and sees the VM
reboot, but it's been that way forever.
Except with that commit above, we flipped it for --cloud-init and
--unattended. Now, users who do `poweroff` are getting expected
behavior, but users who request `reboot` are not.
We could go further and add a `--yesreboot` option or similar. But
for consistency sake I think we should just revert that behavior,
and tell users to use --noreboot like usual.
Resolves: https://github.com/virt-manager/virt-manager/issues/497
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 wires up the guest.convert_to_vnc function to command line,
and documents it.
There's one suboption `qemu-vdagent=on|off`, defaulting to `off`
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is the beginnings of support for a `virt-xml --convert-to-vnc`
option. Take an existing VM, strip out most of the previous graphics
config, and add VNC graphics.
We try to convert over some of the shared graphic bits, like listen
and port settings, if they were previously specified.
If spice GL was enabled, we convert to egl-headless config
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Wire up guest.convert_to_q35 to the CLI. We add one suboptions,
`num_pcie_root_ports=X`, matching the pre-existing
`--controller num_pcie_root_ports=X` option
Nothing fancy here. See man page docs for details
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This function converts a PC/i400FX XML config to Q35. Mostly
this is deleting any plain PCI addresses and controllers, adding
pcie-root-ports, convert IDE -> SATA, and let libvirt fill in
the rest.
This the implementation piece. CLI additions come later
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>
We can make `--xml` fit the common xml cli option paradigm, which
less us drop a whole bunch of special handling in virt-xml
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Adjust cli.py `run_parser` and similar functions to take the
parservalue directly, rather than passing in the whole `options`
structure.
This makes it easier to reason about what the virt-xml action
functions are actually working with.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This adds an Action class which is a container for (most) of the
data we need to perform a virt-xml operation. Basically an instance
of the class represents a pairing like
--edit 1 --disk path=/foo or
--add-device --network wibble,model=virtio
etc
This is a functional no-op, but it moves the code closer to
an architecture that will allow us to perform multiple actions
with a single virt-xml command.
While doing this, we centralize most of the cli validation that is
scattered around, since it's now easier to do it in one place.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Move the validation functions out from amongst the functional XML
editing code, and into their own section. We will be adding more
code alongside in future patches.
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
bc13c302de ("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>
