These include platform checks - libvirt & QEMU - as well as
configuration - SEV is only supported with UEFI.
Another configuration requirement made in this patch is Q35 machine,
since ADM recommends Q35 in their setups even though SEV can work with
the legacy PC machine type, but we'd have to turn on
virtio-non-transitional for all virtio devices with some other potential
pitfalls along the way.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The data in question are 'cbitpos' denoting which addressing bit is the
encryption bit and 'reduced_phys_bits' denoting how many physical
address space we lose by turning on the encryption. Both of these are
hypervisor dependent and thus will be the same for all the guest
residing on the same host, but need to be specified for future migration
purposes.
But given we can probe them from domain capabilities, we don't need the
user to provide them and thus enhancing cli user experience. This
requires a new _SEV domaincapabilities XML class to be created so that
we can query the specific properties.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Policy is a 4-byte bitfield used to turn on/off certain behaviour within
the SEV firmware. For a detailed table of supported flags, see
https://libvirt.org/formatdomain.html#launchSecurity.
Most of the flags are related to advanced features (some of them don't
even exist at the moment), except for the first 2 bits which determine
whether debug mode should be turned on and whether the same key should
be used to encrypt memory of multiple guests respectively.
>From security POV, most users will probably want separate keys for
individual guests, thus the value 0x03 was selected as the policy
default.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Introduce both the launchSecurity XML and parser classes. While at it,
add launchSecurity as a property instance to the Guest class too.
The parser requires the 'type' argument to be mandatory since in the
future it will determine different code paths, therefore
'--launchSecurity foo=bar' is incorrect.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Rather than editing existing Intel domain capabilities by hand, use
capabilities from a real AMD HW. We're later going to use these to fill
in SEV platform specific data automatically.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
And pass it down to treemedia, which acts on our script wrapper
object. This is conceptually a bit simpler because we can see in
one place what data feeds the script build process, depending on
installer props
* Make all API calls go through the _OsMedia object
* Move most of the unattended specific processing to unattended.py
* Rename requires_internet to is_netinst to clarify what it is checking
SupportCache.check_support(SUPPORT_FOOBAR, args) becomes
SupportCache.foobar(args)
And SupportCache absorbs the caching infrastructure from
VirtinstConnection.
For now we add some hackery to hide the API change from callers, but
this will be undone in the next patch
The 'secure' option is processed after the model is already set.
CPU security options are resolved while setting CPU model so we need
to know the 'secure' option value before we set the CPU model.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The memory hotplug changes only work on libvirt 5.3.0, among a few
other pieces. Still do the XML compare but skip domain define if
the new check_version_define comparison fails.
The <domain> XML it alters is called <seclabel>, and security is
really generic sounding. Add the alias and switch the documentation
over to prefer --seclabel
Add some cli infrastructure and testsuite magic to track whether
a cli suboption and cli alias is triggered. This makes it harder
to accidentally add cli option regressions.
We make some exceptions for shared options, requiring them to only
be tested once, otherwise trying to test all address options for
every device will be a giant pain.
There can be more than 1 <memoryBacking><hugepages><page> element.
Adjust the cli options to match:
- hugepages.page[0-9]*.size
- hugepages.page[0-9]*.unit
- hugepages.page[0-9]*.nodeset
This adds the following suboptions to configure the <domain><vcpus>
list:
- vcpus.vcpu[0-9]*.id
- vcpus.vcpu[0-9]*.enabled
- vcpus.vcpu[0-9]*.hotpluggable
- vcpus.vcpu[0-9]*.order
The latter is for triggering <genid/> bool XML, which tells libvirt
to auto-allocate a UUID. The cli isn't really XML conformant but
I can't think of anything better that is self advertising
All our virt-install/virt-clone compare tests aren't actually
attempting to define the XML, meaning we could be generating bogus
output. Enable it, then fix the fallout, mostly some places we are
triggering libvirt XML validation
Add char source arguments to all users:
--serial
--parallel
--console
--channel
--smartcard
--rng
--redirdev
Not all source options apply to all types, but libvirt doesn't
really discriminate, so we should do the same.
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* backend_connect_host -> backend.source.connect_host
* backend_connect_service -> backend.source.connect_service
* backend_host -> backend.source.host
* backend_mode -> backend.source.mode
* backend_service -> backend.source.service
* backend_type -> backend.type
* rate_bytes -> rate.bytes
* rate_period -> rate.period
'type', and 'device' are kept as advertised options,
due to them being commonly specified and documented
This violates our typical XML hierarchy, but that's how it's modeled
internally in libvirt, and these properties are shared among all
charsource users.
Re-use CharSource, just like libvirt does internally. Adjust all
callers to match. Rename type -> backend_model while we are here,
because type is ambiguous
Move all ./source handling into CharSource, which will be reused by
other device classes as well. This requires us to add ../ handling
into our xmlapi xpath engine
Name and forward mode config are always visible. ipv4, ipv6, and
domain name are under their own expanders which are collapsed by
default.
This will fit better with the XML editor pattern and reduce the
urge to squeeze more UI elements into the now smaller wizard
Sort out the memory property naming ambiguity on the command line.
* memory -> currentMemory
* maxmemory -> memory
* hotplugmemorymax -> maxMemory
* hotplugmemoryslots -> maxMemory.slots
To maintain back compat, we need to do some funky handling with
memory and maxmemory values. Basically if currentMemory is specfied,
we interpret them as new style, otherwise preserve the old behavior.
If an OS has a <minimum> resources section, and a <recommended>
resources section, but there's a field in the former that isn't in
the latter, currently we throw out the former field entirely. This
is the case for n-cpus for a few OS. Instead we should be using
the <minimum> ncpus value. This changes the default <vcpu> value
for a quite a few test cases.
Right now we have:
* memory -> ./currentMemory
* maxmem -> ./memory
* hotplugmaxmem -> ./maxMemory
Which is just a mess to know what we might be really setting behind
the scenes. Rename the properties to match the XML element name, and
adjust all users to the new names. cli options aren't changed though
This is some extra validation to catch some char opt combos that
libvirt doesn't explicitly reject. It's not really interesting and
dropping it simplifies the cli parsing
The original code created a new list which had True/False items. The
only case where the returned value would be False is for empty list
which never happens in real environment.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
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>
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>
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>
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>
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>
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>
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>
CPU mode is never set directly using mode attribute, instead we use
setter function with some extra logic that needs to be done.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
<controller> can have additional <driver> sub element with queues as property,
which is currently not exposed via virt-install. This commit exposes this option
similar to queues in network configuration.
(crobinso: add test case)
This reverts commit a746150bef.
See discussion:
https://www.redhat.com/archives/virt-tools-list/2019-March/msg00058.html
Apparently some debian versions struggle with this. Let's stick with
the old method until there's a sufficiently compelling reason to change
Some adjustment is required to deal with changes added by later patches
Back when this was introduced in 2014 (commit aa772f01e1) using
virtio-scsi instead of virtio-blk made sense, because virtio-pci
support on aarch64/virt was still not widely available and
virtio-mmio couldn't do hotplug.
These days, however, virtio-pci availability is something that
we can assume is present on any remotely reasonable deployment
target, so it's better to no longer behave differently than
other architectures.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We already use virtio-blk for regular disks whenever possible,
and there's no good reason not to do the same with virtio-scsi
when dealing with CDROMs instead of artificially limiting its
use to s390x and ppc64/pseries guests.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Right now we're limiting use of virtio-scsi to ppc64/pseries
and aarch64/virt guests, but there's really no reason not to
use it wherever it's available.
This results in virtio-scsi being now used on s390x, where no
other sensible SCSI controller implementation is available
anyway, and x86, where you alreayd didn't want end up using
lsilogic.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The test cases verify that:
+ --start works
+ --define --start works
+ --no-define --start works
+ --start works in combination with --add and --remove
+ combination of --start --update isn't valid
+ combination of --define --no-define --start isn't valid
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Add a test case validating mutual exclusivity of `--no-define` and
'--define' arguments.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Add a test case for `reorder_boot_order`. It verifies that the OS boot
order is removed and that all other boot order indices are adjusted
accordingly.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Refactor method for generating out file path. It will be used in a
upcoming patch.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
--unattended is currently a no-op parameter that will be used to perform
unattended installations.
For now, if someone tries to use --unattended virt-install will fail as
the option is still not supported.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of duplicating the code into CLI and GUI move it into graphics
device file which is used from both places. This also fixes a bug in
virt-xml where changing listen to address was not working.
This also changes behavior to always configure one listen type when
using CLI listen option or GUI. If user wants to modify only specific
listen type they can use listens[] options from CLI.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1565968
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
So we validate the CDROM disk contents too. This revealed we were
using a cdrom path in the test driver that was assigned as a
writeable disk to another test VM, which is a correct warning, so
fix the fallout, and ensure that we don't warn when colliding with
another cdrom device
Add kernel= and initrd= --location suboptions. These can be
used to override the default kernel/initrd and specify new
paths, relative to LOCATION.
For example, if you have an ISO that libosinfo doesn't know
about called my-unknown.iso, with a kernel at 'kernel/fookernel'
and initrd at +'kernel/fooinitrd', you can make this work with:
--location my-unknown.iso,kernel=kernel/fookernel,initrd=kernel/fooinitrd
If no disk options are passed, let's fallback to the libosinfo
recommended disk size for the OS variant.
The guest.set_capabilities_default(), build_installer() and the set of
the distro variant have been moved earlier in the code in order to fetch
the correct information from libosinfo and then set the recommended disk
size without changing much of build_guest_instance() logic.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's create a new method that defaults to libosinfo's recommended
resources (when they're available) for memory and vcpus.
It'll help us to avoid erroring out whenever virt-install is called
without specifying the memory amount, as the recommended amount of
memory would come from libosinfo.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
VSOCK sockets allow communication between virtual machines and the host they are
running on.
This patch adds vsock device support along with clitest for the new properties.
Signed-off-by: Slavomir Kaslev <kaslevs@vmware.com>
Currently osinfo-db has "unknown" entries for fedora, opensuse and
asianux. Considering this list may grow even more at some point, let's
just make the check more generic and use it for all of them instead of
keeping it for fedora only.
Changes have also been done in urldetect and tests_url, as those also
used latest_fedora_version().
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The option only works with --add-device for the time being,
so we prevent its use in all other cases.
It would be nice to have it work with --build-xml too, but
in that case the user would have to provide some extra
information that in the case of --add-device we can figure
out from the existing guest, and it's not entirely clear
whether that would even be that useful, so for now we're
not considering that case at all.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We're mostly interested in how the default bus/model for
devices are influenced by knowledge about the guest OS, but
since the whole thing requires to be connected to the QEMU
driver we might as well create a new category and leave room
for more QEMU-specific tests being added down the line.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Cole Robinson