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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
As long as it's supported by both QEMU and the guest OS,
there's really no reason not to add it.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
libvirt commit 09eb1ae0 added support for a new 'xenbus' controller
type. Add support for the controller in virtinst, including support
for the maxGrantFrames attribute.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
We're not including any input devices in the generated XML
for s390x guests, and the results is that it's not possible
to interact with them short of using the serial console or
connecting through ssh, which is fine but probably not what
is expected when graphics are present.
USB input devices are not a good fit for s390x guests: USB
requires PCI, and PCI is not widely available or used on
s390x; VirtIO devices, on the other hand, are a perfect
match since s390x guests use basically no emulated devices
and rely on VirtIO for most functionality.
https://bugzilla.redhat.com/show_bug.cgi?id=1683609
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We can use this function to figure out whether the guest OS
supports VirtIO input devices (virtio-tablet, virtio-keyboard
and virtio-mouse).
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
libvirt already does this for us, sort of: it will automatically
add a USB keyboard and mouse to ppc64 guests with graphics;
in addition, these devices are impossible to remove.
Unfortunately this results in a pretty poor experience for the
user, since the relative pointing device makes interacting with
the GUI an exercise in frustration.
As of commit 186bb479d0f4, libvirt will still add the USB
keyboard automatically but will skip the USB mouse if a USB
tablet is already present, so by explicitly including USB input
devices in the generated XML we can create guests that are
actually usable.
We can do this unconditionally, without having to worry about
what version of libvirt we're running against: if it's new
enough we'll take advantage of the fix, and if not then the
resulting guest will not be any more broken than it would have
been before.
https://bugzilla.redhat.com/show_bug.cgi?id=1683609
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
These cover the use case "I want to get an existing guest
image running in the cloud, and I need graphics".
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
These cover the use case "I want to get an existing guest
image running in the cloud, and I don't need graphics".
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We're going to add a number of tests covering the same scenario
on multiple architectures soon, so this one is no longer needed
and would in fact cause a name clash if it stayed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
If user selects specific CPU model to be configured for guest we will
automatically add CPU security features to make sure that the guest is
not vulnerable to these CPU HW bugs.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1582667
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
We will need to pass another variable into the setter so we cannot use
the property setter.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Get all CPU security features that we should enable for guests.
In order to do that we need to get CPU definition from domain
capabilities and modify the XML so it is in required format for
libvirt CPU baseline APIs. We will prefer the baselineHypervisorCPU
API because that considers what QEMU actually supports and we will
fallback to baselineCPU API if the better one is not supported by
libvirt.
This way we can figure out which of the security features are actually
available on that specific host for that specific QEMU binary.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Currently we just call libvirt API which will return all CPU models for
specific architecture known to libvirt and we offer all of them to users
in GUI. Let's switch to domain capabilities where we have more details
about these CPUs such as whether each model is usable with current QEMU
binary. If libvirt can detect the usability we will offer only CPU
models that QEMU can actually run.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
It is not True/False attribute, it can contain 'unknown' value as well
which means libvirt cannot figure out whether the CPU model is usable
with that specific QEMU binary.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
This test case is pointless, get_cpu_values() calls only libvirt API
which will return list of CPUs known to libvirt and we check whether
that list is correct.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
