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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is a virt-xml option to refresh a VM to use the latest machine
type version for the machine type it's currently using. Ex:
pseries-2.11 -> pseries
pc-q35-5.0 -> q35
This is useful for when qemu deprecates and removes the machine type
out from under you, or to pick up bug fixes.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We enable default graphics for all of ppc64, but really the only
thing we have ever tested is pseries, so make that clear.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This reverts commit 20d3bf9484.
Indeed graphics does work on aarch64, but for example, fedora
server aarch64 installs don't output any graphical output and only
put data on the serial console. So we would need to be more specific
about how we enable this if we make the change.
qemu 6.1, fairly new when we added this option, has an unfortunate
bug with >= 15 root ports, so we choose 14 instead of our original 16
https://gitlab.com/qemu-project/qemu/-/issues/641
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Libvirt defaults to PCIe for arm32/aarch64 and riscv -M virt too.
Rename q35_pcie_root_ports to num_pcie_root_ports and extend the
logic to those archs too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add extra PCIe root ports to enable q35 device hotplug to work out
of the box. A typical modern linux guest has 7-8 PCI devices added
by default, so this gives plenty of wiggle room.
The smart thing to do would be to count the attached PCI devices
and add 4-5 extra, but that takes more work and isn't trivial.
The number can be overridden on the cli with:
--controller q35_pcie_root_ports=X
Use =0 to go back to the old behavior.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Historically over time it's been more likely that an issue is reported
for osinfo-db missing the usb-tablet annotation. So for example we
always enable it for the default 'generic' case. We also want to
enable it for osinfo's 'unknown' case too.
Rather than add another check for that, let's just drop the osinfo
checking entirely. Some very old OS don't support usb-tablet, but
specifying it for those cases doesn't cause issues AFAIK, and users
can override it with `--input none` if they want.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
<os firmware='efi'> is the libvirt official way to do what we
historically implement with `--boot uefi`, and UEFI setup in
virt-manager.
Let's prefer libvirt's official method if the support is advertised
in domcapabilities.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This replaces the pattern:
Guest.set_uefi_path(Guest.get_uefi_path())
With a single entrypoint
Guest.enable_uefi()
to immediately change the guest config to use UEFI, using our
default logic.
This will make it easier to change that logic in the future, like
using <os firmware='efi'> instead of hardcoded paths
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Both these windows versions are now longer supported, and UEFI isn't
the default, so I don't think this hack is much needed anymore
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The bare metal world is moving to a situation where UEFI is going to be
the only supported firmware and there will be a strong expectation for
TPM and SecureBoot support.
With this in mind, if we're enabling UEFI on a VM, it makes sense to
also provide a TPM alongside it.
Since this requires swtpm to be installed we can't do this
unconditionally. The forthcoming libvirt release expands the domain
capabilities to report whether TPMs are supported, so we check that.
The user can disable the default TPM by requesting --tpm none
https://github.com/virt-manager/virt-manager/issues/310
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The sync_vcpus_topology method will sometimes set the self.vcpus prop,
but other times leave it unset. This is confusing an unhelpful
behaviour. Both callers have logic to set the self.vcpus prop
to a default value of sync_vcpus_topology failed to do so. It makes
more sense to just pass this default value in.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This includes support for the following suboptions:
* name (<shmem name=X>)
* role (<shmem role=X>)
* model.type (<shmem><model type=X/>)
* size (<shmem><size>X)
* size.unit (<shmem><size unit=X/>)
* server.path (<shmem><server path=X/>)
* msi.vectors (<shmem><msi vectors=X/>)
* msi.ioeventfd (<shmem><msi ioeventfd=X/>)
As already done for a few architectures, let's add the default
graphics when using aarch64.
This has been tested on a NVIDIA Jetson Xavier NX SBC.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
Bhyve only supports nmdm console type, so use it instead of TYPE_PTY.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Bhyve requires explicit loader configuration. So query
domain capabilities, try to find the "official"
firmware and configure all the necessary loader options.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Add a --iommu option to configure IOMMU parameters as described in
https://libvirt.org/formatdomain.html#elementsIommu
E.g. 'virt-install --iommu model=intel,driver.aw_bits=48,driver.iotlb=on ...'
will generate the following domain XML:
<devices>
<iommu model="intel">
<driver aw_bits="48" iotlb="on"/>
</iommu>
</devices>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Menno Lageman <menno.lageman@oracle.com>
The way we set controller_model earlier, means all the virtio-scsi
allocation code is essentially never set. That code does still fix
a valid case of when trying to add a scsi device when there isn't
any remaining slots open, but that should be rare enough that I'm
fine telling the user to edit manually set up a controller themselves
first.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The Guest code isn't triggerable because of the way the cli code
was invoking it, as a <memballoon> device would always be added.
Because libvirt accepts model=none, and that's what '--memballoon none'
will translate to anyways, we don't need any special handling here
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This incorrectly always evaluates to True. But no one ever complained
so let's keep that behavior the same
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This ensures the Guest object domcaps cache is primed as well, which
prevents the CPU security features handling from constantly refetching
domcaps info.
We need to tweak the cache invalidation check in Guest to handle
some of the test suite hackery we do
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Let's add a new API to set extra drivers that can be used during
installation time when performing unattended installations. This is
needed for pre-installing virtio-win drivers on Windows guests.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
libvirt already does this for pretty much all QEMU guests, but
ARM virt guests for example don't get a memory balloon by default
at that level of the stack.
virt-manager is in a good position to make sure defaults are
consistent across architectures, and there's no downside in having
the device in the XML passed to libvirt anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We want to start adding a memory balloon automatically to
guests, but we also need to make sure that it can be explicitly
disabled at the user's request.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Init a shared log instance in virtinst/logger.py, and use that
throughout the code base, so we aren't calling directly into
'logging'. This helps protect our logging output from being
cluttered with other library output, as happens with some
'requests' usage
This helps us break that virt-install dependency: parse cli to get
arch/machine info, cli requests uefi, uefi needs to know arch machine
info. Instead just make the 'uefi' bit set a flag, that we resolve
in Guest.set_defaults once we have all the info we need.
Not sure I want to go down that route if we can avoid it. Instead
just fold the full_id support into the existing option handling.
Streamline the OSVariantData usage throughout the cli tools
Replace the unreleased --os-variant OSNAME,install=location with just
--install OSNAME
Unwind the --unattended dependency on upfront --os-variant while
we are at it, since they are all intertwined. Now we can just do:
virt-install --install OSNAME
and
virt-install --install OSNAME --unattended
We set this to True in virt-install, which will cause an explicit
error to be thrown if some part of the cli parser tries to access
osinfo before it's been set, because then we have a circular dependency
between cli config -> installer -> osinfo -> cli config
Having this at set_uefi time complicates the domain XML building
machinery, where we don't want things to have osinfo access.
Rearrange it so that editing cases call this explicitly, and
the XML builder just deals with it at the set_defaults time
