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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
Add support for starting the domain. By default, first the domain is
defined and then started. If the `--start` is used in combination with
`--no-define` a transient domain is created without persisting the
changes in the persistent domain definition.
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 `--no-define` argument. It's mutually exclusive to the `--define`
argument and later on it allows the user to start a domain
transiently.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Use the newly introduced method `reorder_boot_order` for setting
the boot index of a device. This ensures that all other boot order
values of domain guest definition are adjusted accordingly.
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>
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>
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>
Add a check if device boot order is supported to
Parser(Network|Disk|Redirdev|...) and throw an exception if not.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Introduce set_prop helper function. It will be used in the next patch.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Refactor get_prop since it will be used in the next patches at other
places as well.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
The original code for this was about version 0.7.3, but a refactor
accidentally changed it to 0.7.9 which is a libvirt version that
doesn't exist. Fix it
