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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
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.
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>
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>
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>
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>
<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 a746150bef5298187214dadeb55bdf045bd7a265.
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 aa772f01e124) 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>
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>
