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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Previously we tried to use a combination of distro class and version
number to produce a correct ordering that was independent of the
osinfo short ID. The original intent was to have correct ordering
for Windows entries in the virt-manager UI, since the short ID
values are all over the place.
Nowadays that doesn't really matter, since we weed out old
unsupported entries by default. And in the mean time, our current
sort method gives some weird results like interspersing silverblue
entries with fedora entries.
Using a natural/human sort is simpler and handles things pretty well.
Change the UI to sort by the OS label too which preserves some of
the good behavior of original method
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The canonical tool for this is `osinfo-query os`, which we still
reference in the man pages and in the list output.
However, we are about to make missing --os-variant fatal for common
usage, and I don't want to force users to install an extra tool just
to figure out what an acceptable --os-variant value is.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
After checking with qemu devs, this option is not really recommended
for common usage and doesn't get used much in practice. So I don't
think it is suitable for the UI
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This recommendation came from an internal discussion. The cases are
* For block storage. This means guest requests are passed through
to the host device, which seems a more reasonable default than
ignoring them
* For sparse disk images we will create. discard=unmap helps preserve
the sparseness of the disk image. If a user requests non-sparse, they
are likely more concerned with performance than saving disk space,
so we leave the default as is. We limit this to disk images we will
create, since that's the easiest case to check, and it's less clear
if we should change the behavior here for an arbitrary existing
disk image.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is from Gerd's suggestions here:
https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
When the guest supports it, we should use virtio. qxl is on the way
out, and the benefits are marginal and add a security and maintenance
burden.
While here, check domcaps that qxl or virtio are actually available.
Modern qemu has device modules, so device support may not be installed.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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>
This replaces the pattern:
Guest.set_uefi_path(Guest.get_uefi_path())
With a single entrypoint
Guest.enable_uefi()
to immediately change the guest config to use UEFI, using our
default logic.
This will make it easier to change that logic in the future, like
using <os firmware='efi'> instead of hardcoded paths
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We were not correctly accounting for the internal representation of
some fields, and just trying to a string comparison. We need to be
a bit smarter than that
Fixes: https://github.com/virt-manager/virt-manager/issues/356
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Strip back the logic to:
* Only try to toggle source_type=memfd and access_mode=shared
* Disable the field if guest has any <numa> config
* Disable the field if domcaps does not report virtiofs and memfd
This is the simplest future proof case, though it will exclude some
legit guest configs and some libvirt+qemu back compat.
My feeling is the <numa> stuff in particular is pretty advanced, so if
users have it configured they can toggle shared memory via the XML
without too much trouble.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Linux memfd memory backend doesn't require any host setup, We prefer to
use it as the simplest memory XML adjustments to make virtiofs works.
Signed-off-by: Lin Ma <lma@suse.com>
Check whether virtiofs is exposed in domcapabilities, We can use it as a
proxy for 'libvirt is new enough to allow bare memory access mode=shared'
as well.
Signed-off-by: Lin Ma <lma@suse.com>
Both these windows versions are now longer supported, and UEFI isn't
the default, so I don't think this hack is much needed anymore
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The bare metal world is moving to a situation where UEFI is going to be
the only supported firmware and there will be a strong expectation for
TPM and SecureBoot support.
With this in mind, if we're enabling UEFI on a VM, it makes sense to
also provide a TPM alongside it.
Since this requires swtpm to be installed we can't do this
unconditionally. The forthcoming libvirt release expands the domain
capabilities to report whether TPMs are supported, so we check that.
The user can disable the default TPM by requesting --tpm none
https://github.com/virt-manager/virt-manager/issues/310
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This address string decomposing is strictly and virt-* cli feature.
Move it to cli.py to make that explicit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The sync_vcpus_topology method will sometimes set the self.vcpus prop,
but other times leave it unset. This is confusing an unhelpful
behaviour. Both callers have logic to set the self.vcpus prop
to a default value of sync_vcpus_topology failed to do so. It makes
more sense to just pass this default value in.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When setting CPU defaults we want to force create the topology even if
the user has not specified anything. In particular this allows for
overriding the QEMU defaults, to expose vCPUs as cores instead of
sockets which is a much saner default for Windows.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In real world silicon though it is rare to have high socket/die counts,
but common to have huge core counts.
Some OS will even refuse to use sockets over a certain count.
Thus we prefer to expose cores to the guest rather than sockets as the
default for missing fields.
This matches a recent change made in QEMU for new machine types
commit 4a0af2930a4e4f64ce551152fdb4b9e7be106408
Author: Yanan Wang <wangyanan55@huawei.com>
Date: Wed Sep 29 10:58:09 2021 +0800
machine: Prefer cores over sockets in smp parsing since 6.2
Closes: https://github.com/virt-manager/virt-manager/issues/155
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The product of sockets * dies * cores * threads must be equal to the
vCPU count. While libvirt and QEMU will report this error scenario,
it makes sense to catch it in virt-install, so we can test our local
logic for setting defaults for topology.
This exposes some inconsistent configurations in the test suite.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Any missing values in the topology need to be calculated based on the
other values which are set.
We can take account of fact that 'total_vcpus' treats any unset values
as being 1 to simplify the way we set topology defaults.
This ensures that topology defaulting takes account of dies.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It is always permitted to set dies==1 regardless of architecture or
machine type. The only constraint is around setting values > 1, for
archs/machines that don't support the dies concept.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Although using --cpu topology.XXX is the preferred way to set topology,
it is still possible via the --vcpus parameter. For consistency, this
should support the full set of parameters, so dies needs to be added.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We should only be returning a driver_type value for volumes that
report support_format(), meaning they support file type formats like
qcow2. Any other reported format should be ignored
Dropping the check for 'unknown' value changes one test case a bit,
but it hardcodes raw which is what libvirt gives us anyways, so it's
okay
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Usually, when storage volume is attached as a disk and disk xml is filled with
default values, the "<driver type=...>" value is copied from volume's
"<format type=...>". This makes sense for volumes of storage pool of type
"dir", where format types include "raw, qcow2...".
However, the same approach cannot be used for the storage pool of type "disk".
In that case, format types include "none, linux, fat16, fat32...". Such formats
cannot be used for disk's "<driver type=...>".
Therefore, when generating disk XML for volume of storage pool type "disk",
driver type should always be "raw".
Accidentally changed in
commit 302ef1f09669516677d83979536617f1705e1c75
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Fri Nov 26 18:51:49 2021 +0000
virtinst/osdict: add a property for the OsinfoDb object
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we've removed all internal aliases, there is no longer any
reason to keep a cache of OS objects internally. We can directly
query the DB when we need it.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce a property for accessing the generic fallback Os object, which
will be useful in future refactoring.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The code comment suggests removing the aliases after a year. It has
now been three years, so it is time for them to go.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
