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're going to slightly change how the device is handled in
a minute, and we want to make sure we don't break existing
functionality while doing so.
Note that the existing singleton-config-* test cases already
provide coverage for both enabling and disabling the memory
balloon in virt-install.
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
ALLSTORES was implicitly using dict() ordering. This exposed
a bug in our code on debian ci which was nice, but it should
be deterministic. Hardcode the ordering
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
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.
--install kernel_args=X acts like --extra-args. If
kernel_args_overwrite=yes is also specified, it overwrites whatever
default kernel args we would have used for the install method.
This adds a field in gsettings and preferences UI to enable
XML editing. It's off by default. The XML tab page is still visible,
but the textview is not editable, and there's a warning at the top:
XML editing is disabled in 'Preferences'.
Only enable it if you know what you are doing.
When the setting is enabled, the warning goes away and the textview
is editable. This puts a roadblock up for people that don't know what
they are doing, but still advertises the feature and keeps the
UI surface difference fairly small between on/off states.
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
These include platform checks - libvirt & QEMU - as well as
configuration - SEV is only supported with UEFI.
Another configuration requirement made in this patch is Q35 machine,
since ADM recommends Q35 in their setups even though SEV can work with
the legacy PC machine type, but we'd have to turn on
virtio-non-transitional for all virtio devices with some other potential
pitfalls along the way.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The data in question are 'cbitpos' denoting which addressing bit is the
encryption bit and 'reduced_phys_bits' denoting how many physical
address space we lose by turning on the encryption. Both of these are
hypervisor dependent and thus will be the same for all the guest
residing on the same host, but need to be specified for future migration
purposes.
But given we can probe them from domain capabilities, we don't need the
user to provide them and thus enhancing cli user experience. This
requires a new _SEV domaincapabilities XML class to be created so that
we can query the specific properties.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
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>
Rather than editing existing Intel domain capabilities by hand, use
capabilities from a real AMD HW. We're later going to use these to fill
in SEV platform specific data automatically.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
And pass it down to treemedia, which acts on our script wrapper
object. This is conceptually a bit simpler because we can see in
one place what data feeds the script build process, depending on
installer props
* Make all API calls go through the _OsMedia object
* Move most of the unattended specific processing to unattended.py
* Rename requires_internet to is_netinst to clarify what it is checking
SupportCache.check_support(SUPPORT_FOOBAR, args) becomes
SupportCache.foobar(args)
And SupportCache absorbs the caching infrastructure from
VirtinstConnection.
For now we add some hackery to hide the API change from callers, but
this will be undone in the next patch
The 'secure' option is processed after the model is already set.
CPU security options are resolved while setting CPU model so we need
to know the 'secure' option value before we set the CPU model.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The memory hotplug changes only work on libvirt 5.3.0, among a few
other pieces. Still do the XML compare but skip domain define if
the new check_version_define comparison fails.
The <domain> XML it alters is called <seclabel>, and security is
really generic sounding. Add the alias and switch the documentation
over to prefer --seclabel
Add some cli infrastructure and testsuite magic to track whether
a cli suboption and cli alias is triggered. This makes it harder
to accidentally add cli option regressions.
We make some exceptions for shared options, requiring them to only
be tested once, otherwise trying to test all address options for
every device will be a giant pain.
There can be more than 1 <memoryBacking><hugepages><page> element.
Adjust the cli options to match:
- hugepages.page[0-9]*.size
- hugepages.page[0-9]*.unit
- hugepages.page[0-9]*.nodeset
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
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
This violates our typical XML hierarchy, but that's how it's modeled
internally in libvirt, and these properties are shared among all
charsource users.
Re-use CharSource, just like libvirt does internally. Adjust all
callers to match. Rename type -> backend_model while we are here,
because type is ambiguous
Move all ./source handling into CharSource, which will be reused by
other device classes as well. This requires us to add ../ handling
into our xmlapi xpath engine
Name and forward mode config are always visible. ipv4, ipv6, and
domain name are under their own expanders which are collapsed by
default.
This will fit better with the XML editor pattern and reduce the
urge to squeeze more UI elements into the now smaller wizard
