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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We will no longer have `rpm` target with meson. That should not be an
issue as users can run `meson dist -C build` and
`rpmbuild -tb build/meson-dist/virt-manager-{version}.tar.xz`.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The reason we fork by default, is to force ssh to invoke
ssh-askpass when a password is required, rather than prompt on
a terminal no one is looking at. There's a more thorough
explanation here:
https://github.com/virt-manager/virt-manager/issues/731
With SSH_ASKPASS_REQUIRE=force, we now have a way to force ssh
to use askpass in the above scenario, when ssh and libvirt are new
enough.
The default forking behavior has caused maintenance pain in the
past, and is currently causing issues on macos:
https://github.com/virt-manager/virt-manager/issues/620
Let's flip the default to `--no-fork`. The VIRT_MANAGER_DEFAULT_FORK
env variable is there as an escape hatch incase I really miscalculated.
I don't expect many people are depending on use of askpass either
way, or if they are, they are launching virt-manager from their
desktop and not a terminal, which already gives us the correct
behavior AFAICT>
My suspicion is barely anyone will notice, which is why
I'm ok with changing this now, despite the libvirt support being
brand new.
If this doesn't raise any issues, then we can eventually drop
the forking behavior all together.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
openssh 8.4p1 released in Sep 2020 finally added a feature
to force using SSH_ASKPASS instead of prompting on the commandline
for password, if a password would be required.
https://man.openbsd.org/ssh.1#SSH_ASKPASS_REQUIRE
Getting this behavior is basically what our whole fork dance is
about. Now we can do it with an environment variable
Let the user override it from the environment though, so there's
an escape hatch incase this causes unforseen problems
Signed-off-by: Cole Robinson <crobinso@redhat.com>
- drop all the architectures (and thus building only on x86_64):
virt-manager has no architecture-specific installation bits, and thus
it builds in the same way on every architecture; hence no need to
explicitly test on various architectures
- test on all the supported Fedora versions (Rawhide included): this way
it is possible to check that older versions are still supported, at
least when building
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
- use a single translatable message, instead of splitting the text in
two; it helps translators to have the full context/text
- improve the language a bit
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Drop our hardcoded model lists, and just ask libvirt to fill in
a model for us. Add an entry to the combo box so users can type
in a non-default value if they want one.
Long term libvirt should be providing all this info to us via
domcapabilities
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Currently `--panic default` for aarch64 doesn't even request
a `<panic/>` device due to quirky xmlbuilder behavior. Fix that,
but more generally just leave model empty and let libvirt fill it
in for us.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a special convenience option for filling in `type=hostdev`
config using the same format of lookup string that can be
passed to `--hostdev`
Fixes: https://github.com/virt-manager/virt-manager/issues/500
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This just covers the common PCI case with these new options
source.address.type=
source.address.domain=
source.address.bus=
source.address.slot=
source.address.function=
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I think this is a better default than the current `Only when
Fullscreen`, which is the same as `Never` for VM windowed mode.
I wrote my reasoning here:
https://github.com/virt-manager/virt-manager/issues/747
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Fix no longer valid URL fragments, wrap at 80th column, remove dots that
follow only a few links.
Signed-off-by: Grzegorz Szymaszek <gszymaszek@short.pl>
This is essentially what it has always behaved as, but making it
explicit in the code will now trigger the extra warnings when
detect=on is also used.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Using `detect=on,name=OSNAME` is good for CI safety, incase
a new distro tree has a regression with detection, or if testing
against a new distro that osinfo-db doesn't know about.
But virt-install should still try to inform the user that detection
failed, and suggest filing a bug if the user expected it to work.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The require= behavior should be AUTO for this case, but the
way we were previously initializing variables made this OFF.
I don't think this was intentional. We should have changed
this when we started defaulting to `detect=on`
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It's kinda hard to follow the logic here. cli require= can only be
on|off or unset, but we use an internal 'auto' value which seems
like it can come from the cli.
Try to clean it up with enum like values.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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>
This basically reverts this commit from virt-manager 4.0.0
```
commit 825ec644b859b99d6f9f155b04ef3ac07eca1fc2
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>
