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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The commit c5a46646 asks libvirt to fill in a default panic model for us.
Now libvirt domcaps can advertise panic models, Let's fill in the panic
model combo with the advertised values.
Signed-off-by: Lin Ma <lma@suse.de>
The actual default CPU at the QEMU level is often a relatively
poor choice, which is stuck with just baseline functionality
and can sometimes not run modern guests at all.
Whenever possible, prefer maximum mode for a much nicer out of
the box experience.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
This mode has been introduced in libvirt 7.1.0 (March 2021) and
can be already used today with
--cpu mode=maximum
This is however slightly inconvenient to type and is not
consistent with the special treatment that the other modes
(host-passthrough, host-model) get.
Introduce a proper special mode for it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Scientific Linux is no longer supported as it ended with version 7 so
change it to AlmaLinux that is mentioned to be used instead.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
With setup.py we cleared po/virt-manager.pot file and created a new
fresh content using gettext.
I missed that fact when converting to meson and with the --join-existing
argument the comments for each msgid were growing with references to
their location in source files.
There is no need to clear the file and generate it again because
removing the --join-existing will end up with the same result.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Tells virt-install to not use UEFI, if it would normally default
to it.
This likely isn't too useful in practice, since all occasions we
default to UEFI require it. But it future proofs opt out in case
we ever start defaulting to UEFI in cases where BIOS still works.
Resolves: https://github.com/virt-manager/virt-manager/issues/692
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The way `--boot uefi` is implemented allows a value to be passed,
but the value is completely ignored. So `--boot uefi=off` or
`--boot uefi=FOOBAR` is treated the same as `--boot uefi`
Lets fix this by making `--boot uefi` and `--boot uefi=on` the same,
`--boot uefi=off` will be implemented later, but any other value
throws an error. This is technically an CLI break but I don't
think it's anything to worry about
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Currently we will only apply the default `--cpu mode=host-passthrough`
config when _no_ `--cpu` config is passed. But this means if a user
configures ex. cpu `<topology>`, we don't set `host-passthrough` and
they get the libvirt/qemu default baseline CPU.
Instead, only skip the default config if the user manually
specified a `mode` or `model` value directly
https://issues.redhat.com/browse/RHEL-65371
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Input XML can have non-existent disk images as long as `--preserve`
is used, or those disks are skipped for any reason. We already
handle that correctly in some cases, but others we fail. This
covers another one.
Resolves: https://github.com/virt-manager/virt-manager/issues/563
Signed-off-by: Cole Robinson <crobinso@redhat.com>
With the libvirt testdriver, we can create+start a directory
pool that points to any arbitrary host path. But this doesn't
match the behavior of the real storage driver, where pool start
will fail if the source directory doesn't exist.
Let's mock this by raising an exception if we are inside the
test suite and we see a special string in the pool XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
`--replace` will attempt to remove any existing VM with the new
clone name before performing the clone operation. There's a report
that it will fail for an existing VM with nvram, since we need
aren't doing the equivalent of `virsh undefine --nvram`
https://issues.redhat.com/browse/RHEL-65105
Making `--replace` remove nvram is easy, but it kinda breaks some
Cloner assumptions about determining ahead of time whether we
need to clone nvram or not. It's fixable but it's messy.
Also, making changes here raises the question about how we should be
handling all the other `virsh undefine` flags that have appeared over
the years.
I think it's better to leave `--replace` as is, and just document
that it's doing the simplest equivalent of
`virsh destroy` + `virsh undefine`. Anything more complicated
than that will cause the clone operation to fail, the user needs
to handle VM removal themselves.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
--reflink only works with raw images, since copying anything else
will hit the qemu-img code path in libvirt storage driver.
This can pop up more nowadays since UEFI support is using qcow2 as
well.
Let's only attempt --reflink for raw disk images. It's basically
an optimization anyways
https://bugzilla.redhat.com/show_bug.cgi?id=2256285
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Default to adding tablet+keyboard if graphics and usb are configured.
This saves us from having to duplicate the arch list.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Our logic here is poorly duplicating libvirt's postparse logic.
Notably it will try to add bus=ps2 on non-x86, and misses obscure
cases like parallels.
https://issues.redhat.com/browse/RHEL-66768
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Was erroring with 'Dist currently only works with Git or Mercurial
repos'. Seems like something about the libvirt checkout ordering
caused problems
Signed-off-by: Cole Robinson <crobinso@redhat.com>
