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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
QEMU version 2.12.1 introduced a performance feature under commit
be7773268d98 ("target-i386: add KVM_HINTS_DEDICATED performance hint").
Support for this performance hint was added in libvirt 5.7.0 by commit
cb12c59dac04 ("qemu: support for kvm-hint-dedicated performance hint").
This patch extends virt-install's existing --features option to insert the
appropriate XML into the guest definition if this feature is specified
on the command line.
E.g. --features='kvm.hint-dedicated.state=on' would result
in the following XML:
<features>
...
<kvm>
<hint-dedicated state='on'/>
</kvm>
...
</features>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Menno Lageman <menno.lageman@oracle.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
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>
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
For CPU modes other then "custom" there is no model so we should not
check the suffix of model name.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
VM configured with mode="host-model" will have the CPU definition
expanded once the VM is started. Libvirt will try to use the closest
CPU model with some features enabled/disabled.
The issue is that there are some models that include spec-ctrl or ibpb
features and they will not appear in the explicit list of features and
virt-manager will not correctly detect if all security features are
enabled or not. As a workaround we can check the suffix of CPU model to
figure out which security features are enabled by the model itself.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
By default we copy CPU security features to the guest if specific CPU
model is selected. However, this may break migration and will affect
performance of the guest. This adds an option to disable this default
behavior.
The checkbox is clickable only on x86 and only on host where we can
detect any CPU security features, otherwise a tooltip is set to notify
users that there is nothing to copy.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@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>
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>
We will need to pass another variable into the setter so we cannot use
the property setter.
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>
virt-install -n blah -r 1024 --vcpu=1 --disk=/root/vm/blah.qcow2,size=10\
--network=bridge:br-public --pxe --boot=network,rebootTimeout=3
By default, in case of (first) pxe boot failure the VM will simply
stop trying.
By adding the above, VM will re-try pxe boot. ( useful when DHCP not
replys on first attempt.
Libvirt support it and VM XML will look as follow : ( 'bios rebootTimeout'
will be created under OS section. )
<os>
<type arch='x86_64' machine='pc-i440fx-rhel7.5.0'>hvm</type>
<boot dev='network'/>
<bios rebootTimeout='3'/>
</os>
(crobinso: fix it, add test case)
Allow to set some memory backing options, ex:
--memorybacking access_mode=shared,source_type=anonymous
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
