* libvirt fills in cbitpos and reducedPhysBits for us
* libvirt errors if type is missing
* libvirt errors if host/qemu doesn't support sev
So drop it all. This simplifies testing because we don't need
sev domcaps in place just to generate the XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Otherwise going host-passthrough -> host-model -> host-passthrough
can cause libvirt validation errors or leave unintended bits in
the XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
- Move most xml suboption testing to many-devices test
- Clarify every specific bit we are testing in the singleton tests
- Consolidate/drop/reduce a lot of tests
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When libvirt and qemu are new enough, use host-passthrough for the
CPU default. Nowadays this is recommended over host-model for most
end user usage where migration isn't a critical feature.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
host-copy was the old default, but it's fundamentally flawed. Since
we switched to host-model default a few years back, it's not advertised
in the docs or selectable via virt-manager any more.
Have it print a warning and invoke host-model-only
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Strip back the logic to:
* Only try to toggle source_type=memfd and access_mode=shared
* Disable the field if guest has any <numa> config
* Disable the field if domcaps does not report virtiofs and memfd
This is the simplest future proof case, though it will exclude some
legit guest configs and some libvirt+qemu back compat.
My feeling is the <numa> stuff in particular is pretty advanced, so if
users have it configured they can toggle shared memory via the XML
without too much trouble.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When setting CPU defaults we want to force create the topology even if
the user has not specified anything. In particular this allows for
overriding the QEMU defaults, to expose vCPUs as cores instead of
sockets which is a much saner default for Windows.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In real world silicon though it is rare to have high socket/die counts,
but common to have huge core counts.
Some OS will even refuse to use sockets over a certain count.
Thus we prefer to expose cores to the guest rather than sockets as the
default for missing fields.
This matches a recent change made in QEMU for new machine types
commit 4a0af2930a4e4f64ce551152fdb4b9e7be106408
Author: Yanan Wang <wangyanan55@huawei.com>
Date: Wed Sep 29 10:58:09 2021 +0800
machine: Prefer cores over sockets in smp parsing since 6.2
Closes: https://github.com/virt-manager/virt-manager/issues/155
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The product of sockets * dies * cores * threads must be equal to the
vCPU count. While libvirt and QEMU will report this error scenario,
it makes sense to catch it in virt-install, so we can test our local
logic for setting defaults for topology.
This exposes some inconsistent configurations in the test suite.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Any missing values in the topology need to be calculated based on the
other values which are set.
We can take account of fact that 'total_vcpus' treats any unset values
as being 1 to simplify the way we set topology defaults.
This ensures that topology defaulting takes account of dies.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It is always permitted to set dies==1 regardless of architecture or
machine type. The only constraint is around setting values > 1, for
archs/machines that don't support the dies concept.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add the ability to set the ioapic driver using the --features argument:
$ virt-install --features ioapic.driver=qemu ...
This results in the following xml:
<features>
...
<ioapic driver="qemu"/>
</features>
This is required in order to install a guest with >255 cpus. Such a
configuration requires an iommu with extended interrupt mode enabled,
which in turn requires IOMMU interrupt remapping to be enabled, which in
turn requires a split I/O APIC.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
The code was only checking the manual approach to enabling UEFI, not the
modern automatic approach.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Shuffling bits of code around, adding comments and grouping CLI options
to make the code easier to read and understand at a glance.
Brings the ordering of XML options in line with libvirt's own output as
implemented in `src/conf/cpu_conf.c` and `src/conf/numa_conf.c`.
This includes support for the following options:
* numa.interconnects.latency[0-9]*.initiator
* numa.interconnects.latency[0-9]*.target
* numa.interconnects.latency[0-9]*.cache
* numa.interconnects.latency[0-9]*.type
* numa.interconnects.latency[0-9]*.value
* numa.interconnects.latency[0-9]*.unit
* The same suboptions for `numa.interconnects.bandwith[0-9]*`
Note that the cache= attribute is only explicitly defined for <latency>
nodes in the documentation. However, since <latency> and <bandwidth>
nodes are otherwise identical, the docs also don't explicitly forbid it
for <bandwidth> nodes, and libvirt happily accepts XML that does specify
it for for <bandwidth> nodes, this implements the cache= attribute for
<bandwidth> elements as well.
This includes support for the following options:
* numa.cell[0-9]*.cache[0-9]*.level
* numa.cell[0-9]*.cache[0-9]*.associativity
* numa.cell[0-9]*.cache[0-9]*.policy
* numa.cell[0-9]*.cache[0-9]*.size.value
* numa.cell[0-9]*.cache[0-9]*.size.unit
* numa.cell[0-9]*.cache[0-9]*.line.value
* numa.cell[0-9]*.cache[0-9]*.line.unit
This includes support for the following options:
* `emulatorsched.scheduler`
* `emulatorsched.priority`
* `iothreadsched.iothreads`
* `iothreadsched.scheduler`
* `iothreadsched.priority`
This includes support for the following options:
* `shares`
* `period`
* `quota`
* `global_period`
* `global_quota`
* `emulator_period`
* `emulator_quota`
* `iothread_period`
* `iothread_quota`
libvirt 7.2.0 introduced support for a list of firmware features
that should or should not be present. Libvirt takes these into
account when auto-selecting a firmware. Currently supported features
are `enrolled-keys` and `secure-boot`.
Implement kvm.poll-control.state to `virt-install --feature`. It requires
libvirt >= v6.10.0.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Han Han <hhan@redhat.com>
This adds the following suboptions to configure <cputune>:
- vcpusched.vcpus
- vcpusched.scheduler
- vcpusched.priority
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
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>
Cole Robinson