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>
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>
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>
Add `reorder_boot_order` method to Guest class. It sets the boot order
of the passed `dev` to `boot_index` and adapts all other boot indices
of the guest accordingly.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Apart from the fact, that 'virtio' is not a valid scsi controller model
the 'has_virtio_scsi' variable is not needed at all. It is used only
in one condition where both 'has_any_scsi' and 'has_virtio_scsi' has to
be false which can happen only if there is no 'scsi' controller defined
by user.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
A `KeyError` indicates that the `boot_order` input was
invalid. Therefore we shouldn't ignore this error silently.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Don't exclude redirected devices since they're also bootable. They
won't clutter the UI of virt-manager as we're excluding them
explicitly for the UI in the `get_bootable_devices` method defined in
virtManager/domain.py.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Move set boot order responsibility to guest XML builder.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Add 'get_boot_order' method. This method has an optional parameter for
getting the legacy boot order defined in the OS node of the domain
definition.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Move get boot order methods to guest XML builder. For this we must
replace self.get_bootable_devices() with
self.get_bootable_devices(exclude_redirdev=True) in the
_get_device_boot_order and set_device_boot_order to have no
functionality change.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Move use_device_boot_order to guest XML builder and rename it into
'set_device_boot_order'.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Add a method to the Guest XMLBuilder for getting all bootable devices
of the guest definition with the option to exclude the redirdevs in
the returned list.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Move (find_compare)_device functions to guest.py as it will be used
there in an upcoming patch.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.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>
There's been various discussions about changing the x86 default
from 'pc' to 'q35' over the years, but it's unlikely to happen
at the qemu or libvirt level for compatibility reasons. So
let's start using it for new enough OS that support it.
This switch says: if we detect a rhel host, use special version
checks that match rhel backports. This pattern sucks. The way
forward is to have libvirt advertise the bits that are supported,
through domcapabilities. Then virt-manager/virtinst can react
as appropriate.
This is just a big nasty commit.
Turn the OS inspection page into an always available page that
shows the libosinfo name from the domain metadata XML. Use oslist.py
and have it absorb more of the common behavior needed by create.py
and details.py. Add UI tests for it all
Don't rely on libvirt's default. This makes any XML changes more
explicit, and can help other parts of the code that may depend on
a machine type being encoded
Rather than forcing API users to go through the capabilities APIs.
This lets us simplify things in virt-install quite a bit, and is
needed for smarter machine type defaults
This changes all the callers to invoke start_install directly on the
Installer object. We still stash the installer instance inside the
guest object in create.py, just for simplicity
Andrea Bolognani