For CPU modes other then "custom" there is no model so we should not
check the suffix of model name.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
VM configured with mode="host-model" will have the CPU definition
expanded once the VM is started. Libvirt will try to use the closest
CPU model with some features enabled/disabled.
The issue is that there are some models that include spec-ctrl or ibpb
features and they will not appear in the explicit list of features and
virt-manager will not correctly detect if all security features are
enabled or not. As a workaround we can check the suffix of CPU model to
figure out which security features are enabled by the model itself.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Given that we bumped deps to fairly modern distros with the
python3 change, I think this is safe. gtk 3.22 is from sep 2016, it's
in debian9 and fedora 25+, which seems fine for our needs.
If USB support is available, we can use USB input devices too.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Unlike other features we have enabled earlier, this one requires
version checks because RISC-V guests have only started using PCI
by default very recently, and we can't have USB without PCI.
More specifically, we need QEMU commit d6c1bd4a2237 (included
in 4.0.0) and libvirt commit 7c48fb08e0cd (included in 5.3.0).
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
QXL, on the other hand, is still x86-only for some reason.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The default machine at the QEMU level is spike_v1.10, but most
people will really want to use the virt machine type instead.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
These test cases mirror thoses we already have for all other
architectures.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
RISC-V doesn't support KVM yet, so we are forced to use TCG
on x86 until that's working.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
By default we copy CPU security features to the guest if specific CPU
model is selected. However, this may break migration and will affect
performance of the guest. This adds an option to disable this default
behavior.
The checkbox is clickable only on x86 and only on host where we can
detect any CPU security features, otherwise a tooltip is set to notify
users that there is nothing to copy.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We will call this function multiple times so it makes sense to cache the
result so we don't have to call libvirt APIs every time we will check
what security features are available on the host.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This will allow users to override the default behavior of virt-install
which copies CPU security features available on the host to the guest
XML if specific CPU model is configured.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
These features are only recommended to be enabled since they improve
performance of the VMs if security features are enabled.
pcid is a very useful perf feature, but missing in some silicon
so not portable.
pdpe1gb lets the guest use 1 GB pages which is good for perf
but again not all silicon can do it.
amd-ssbd is a security feature which fixes the same SSBD flaws as the
virt-ssbd feature does. virt-ssbd is usable across all CPU models
affected by SSBD, while amd-ssbd is only available in very new silicon.
So virt-ssbd is the bette rchoice.
amd-no-ssb just indicates that the CPU is not affected by SSBD, so not
critical to expose. I expect a future named CPU model will include that
where appropriate.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
systemd in fedora30 has some new security restriction about non-root
owned directories. Initrd inject would tickle this because the cpio
archive would cause the root dir in the initrd to be owned by the
uid that launched virt-install.
Pass --owner=+0:+0 to cpio to force root ownership
Suggested-by: James Szinger <jszinger@gmail.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1686464
The Windows unattended installation is quite similar to the Linux one
with a few major differences:
- It uses floppy injection instead of initrd injection
- Yes, it does. Then we have to create a floppy, add the device and,
when finishing the installation, remove the device;
- There's no InstallerTreeMedia in the game making us end up duplicating
some code in the Installer class as:
- keeping track of files that have to be cleanup up;
- actually cleaning up the files;
- generating the install script
Apart from that, some obvious differences in the scripts where already
done in a previous commit, but those were basically:
- Not using /dev/*da as a target disk, but use "C" instead;
- Set the product-key
- Explicitly set the injection method as "floppy"
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add unattended data to the Installer class as it's going to be
used whenever a Windows unattended installation is performed.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's have a way to keep track of unattended files that are going to be
used when performing a unattended installation of a Windows guest so we
can clean them up whenever the installation is done.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
A floppy device is going to be used when performing a unattended
installation in a Windows guest.
In order to have it done cleanly, let's mimic the what's already
existent for dealing with cdrom devices used during installation.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The main differences are:
- Windows unattended installation will be performed via "floppy"
injection instead of "initrd";
- Windows target disk must be a letter ("C", in our case);
- Windows requires a product-key to be passed
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Similar to perform_initrd_injections(), which is used by Linux(es)
unattended installations, perform_floppy_injections() is going to be
used by Windows(es) unattended installations.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
In case there's no self.osinfo_media, it means the installation won't
happen from the media itself, so it should return "True" (as in, it
requires internet).
Returning "False", though, should be done when no "netinst" variant was
found (but we do have a media).
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Some distros (as Fedora, RHEL, and CentOS) require a bigger amount of
RAM during network installation than the recommended amount to run the
system.
In order to properly have it set, let's take advantages of the libosinfo
network-install resources API and change the guest amount of ram for the
installation.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
By using OsinfoMedia.requires_internet() we ensure this logic is not
spread in our codebase and also keep _OsinfoIter internal to osdict.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Consequently, let's:
- rename urldetect::get_osinfo_media() to get_os_media()
- rename the installertreemedia::_LocationData::osinfo_media to os_media
- rename unattended::prepare_install_script's media argument to os_media
- and also rename media to os_media on its internal
_get_installation_source() method
- rename osdict::get_install_script's media argument to os_media
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
In order to properly do a unattended installation of some medias (as net
installers), we have to check whether the media requires or not
internet. Doing so by checking its variant is not the most beautiful way
(as variants do not have a set of predefined names), but that's the best
that can be done with the current state of osinfo-db.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The OsMedia class is a wrapper around OsinfoMedia and will help us
to keep the logic of dealing with media related stuff from inside
osdict.py
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
get_network_install_resources() is going to be used when performing a
network based installations where more RAM is needed during the
installation time than the recommended one, which is the case of some
distros as CentOS, RHEL, (some versions of) Silverblue and (some
versions of) Fedora.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
If a VM is defined and never started the nvram file might not exist and
in that case it's created by libvirt automatically on the first start.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1679018
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Using 'virt-install --disk size=X' implicitly uses pool=default. If
a pool named 'default' exists we use that; if not, and a pool using
the default path exists under a different name, we attempt to use
that as well, and if that doesn't exist, we create pool=default
The second case is broken, so if there's no pool=default and eg.
pool=FOO points to /var/lib/libvirt/images, we still attempt to
look up pool=default which understandably fails
https://bugzilla.redhat.com/show_bug.cgi?id=1692489
Pavel Hrdina