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>
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>
According to libvirt documentation for host-model [1] it is safe to use
it only if 'fallback' attribute is set to 'forbid', this indicates that
the libvirt and QEMU are new enough and can safely filter list of cpu
features that will be guaranteed to be visible inside of the guest.
[1] <https://libvirt.org/formatdomain.html#elementsCPU>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
s390x guests usually detect the sclp or virtio console. The current
warning might actually break setups. Let us disable the warning.
Reported-by: Andre Wild <wild1@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.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)
When dealing with unattended installation, we safely can assume that
"--cdrom" can be treated as "--location". The reason for that is that
we'll need to, under the hooks, extract its kernel/initrd and perform an
initrd injection.
This commit makes "--unattended" work properly when combined with
"--cdrom".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
As medias may also have installer scripts associates to themselves and,
in this case, those should be considered instead the OS ones.
More than that, Libosinfo.Media provides an API that tells whether that
specific media supports installer scripts or not and this must be
checked as the first thing. In case no installer script is supported,
let's just error out and abort the installation.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's refactor get_install_script() in a way that any addition done in
order to get the install scripts from the media would be cleaner.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The installation source, which can be either "media" or "network",
should be properly set depending on whether we're installing from a
media or performing a tree based installation.
We have to mind here that any media that is set as "netinstall" variant
has to have its installation source set accordingly.
An different approach for this would be to generate the script
specifically from the media whenever a media is passed. However, IMO, it
would just add two new codepaths and having the media passed around
without a real gain against the method chosen.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's pass the media down to prepare_install_script() as it'll be used
to:
- select the preferred installation source;
- be passed down to the get_install_script() method;
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The location has to be passed down to the generate_install_script()
method whenever a tree based installation is being performed.
Although Libosinfo provides information about the URL to be used when
performing a tree based installation, cases where the users prefer to
use, for any specific reason, their own URLs should be covered as well.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
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
This doesn't seem to do anything, as we end up with with a
virtio-scsi controller anyway both when using virt-install and
when using the GUI, and it's not correct anyway because there's
nothing preventing ppc64/pseries guests from using virtio-scsi.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
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 code in _add_implied_controllers() tries to add an ibmvscsi
controller if any disk with spapr-vio address type is found;
however, regardless of the specific SCSI controller in use, all
SCSI disks will use the drive address type, so that condition
will never be triggered - which is actually for the best, since
we want to use virtio-scsi on ppc64 anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Our support.py check is not exhaustive based on libvirt code checking.
Don't reject this case so users have a chance to make it work. The
support check is really more valuable in the UI where we can screw
things up easier.
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>
Cole Robinson