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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
This reverts commit 66fe00ddee.
Turns out it's not that simple. Indeed libvirt sets the default
when no <vcpus> XML is present, but if you do --vcpus cpuset=X
libvirt will error that there's no vcpu value set. So for back
compat and generate safety let's keep setting it.
It was disabled with commit 2aca20141e back in 2015, but
these days we have it enabled for all other architectures and
there doesn't seem to be a good reason for s390x to keep being
the outlier.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
This uses the same logic as virt-manager. The name is mostly
derived from --os-variant naming, but we have fallback defaults too.
Print the name to stdout so users are informed about what we are
doing.
This puts all the default resource setting in one place, and the
only place that was depending on it, as virt-manager explicitly sets
the values on its own. This will be used in future patches to add
more default setup and report the values to the user
Policy is a 4-byte bitfield used to turn on/off certain behaviour within
the SEV firmware. For a detailed table of supported flags, see
https://libvirt.org/formatdomain.html#launchSecurity.
Most of the flags are related to advanced features (some of them don't
even exist at the moment), except for the first 2 bits which determine
whether debug mode should be turned on and whether the same key should
be used to encrypt memory of multiple guests respectively.
>From security POV, most users will probably want separate keys for
individual guests, thus the value 0x03 was selected as the policy
default.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Introduce both the launchSecurity XML and parser classes. While at it,
add launchSecurity as a property instance to the Guest class too.
The parser requires the 'type' argument to be mandatory since in the
future it will determine different code paths, therefore
'--launchSecurity foo=bar' is incorrect.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This adds the following suboptions to configure the <domain><vcpus>
list:
- vcpus.vcpu[0-9]*.id
- vcpus.vcpu[0-9]*.enabled
- vcpus.vcpu[0-9]*.hotpluggable
- vcpus.vcpu[0-9]*.order
The latter is for triggering <genid/> bool XML, which tells libvirt
to auto-allocate a UUID. The cli isn't really XML conformant but
I can't think of anything better that is self advertising
Right now we have:
* memory -> ./currentMemory
* maxmem -> ./memory
* hotplugmaxmem -> ./maxMemory
Which is just a mess to know what we might be really setting behind
the scenes. Rename the properties to match the XML element name, and
adjust all users to the new names. cli options aren't changed though
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>
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>
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>
