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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Check whether virtiofs is exposed in domcapabilities, We can use it as a
proxy for 'libvirt is new enough to allow bare memory access mode=shared'
as well.
Signed-off-by: Lin Ma <lma@suse.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>
This address string decomposing is strictly and virt-* cli feature.
Move it to cli.py to make that explicit
Signed-off-by: Cole Robinson <crobinso@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>
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>
Although using --cpu topology.XXX is the preferred way to set topology,
it is still possible via the --vcpus parameter. For consistency, this
should support the full set of parameters, so dies needs to be added.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We should only be returning a driver_type value for volumes that
report support_format(), meaning they support file type formats like
qcow2. Any other reported format should be ignored
Dropping the check for 'unknown' value changes one test case a bit,
but it hardcodes raw which is what libvirt gives us anyways, so it's
okay
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Usually, when storage volume is attached as a disk and disk xml is filled with
default values, the "<driver type=...>" value is copied from volume's
"<format type=...>". This makes sense for volumes of storage pool of type
"dir", where format types include "raw, qcow2...".
However, the same approach cannot be used for the storage pool of type "disk".
In that case, format types include "none, linux, fat16, fat32...". Such formats
cannot be used for disk's "<driver type=...>".
Therefore, when generating disk XML for volume of storage pool type "disk",
driver type should always be "raw".
Accidentally changed in
commit 302ef1f096
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Fri Nov 26 18:51:49 2021 +0000
virtinst/osdict: add a property for the OsinfoDb object
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we've removed all internal aliases, there is no longer any
reason to keep a cache of OS objects internally. We can directly
query the DB when we need it.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce a property for accessing the generic fallback Os object, which
will be useful in future refactoring.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The code comment suggests removing the aliases after a year. It has
now been three years, so it is time for them to go.
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>
This would still be used for old osinfo (mid 2019), and only for
the case of installing 7+ year old RH distros. I think we can safely
delete it.
Signed-off-by: Cole Robinson <crobinso@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>
Any of the commands involved in injecting files into an initrd
could fail, and if that happens we should interrupt the
installation instead of proceeding as if nothing had happened.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Each OS may specify which kernel argument is needed to specify the
installation source; use it as primary source, falling back to the
current logic. This should help supporting new OSes OOTB.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Commit c6b5f22fa6 started passing the --owner argument to
cpio when injecting files into the initrd to comply with the
more strict requirements introduced by systemd starting with
Fedora 30.
However, cpio only started accepting the +uid:+gid syntax in
version 2.12, which means that the fix actually broke the
initrd inject functionality completely in RHEL 7 and other
distros that don't include a recent enough cpio.
Use the user:group syntax instead, which is understood by
all versions of cpio, including non-GNU ones.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
libvirt recently changed the nodedev names for mediated devices due to
the fact that mdevctl supports defining multiple mediated devices with
the same UUID as long as only one is active at a time. This means that
the nodedev name changed from the format 'mdev_$UUID' to the format
'mdev_$UUID_$PARENT'.
Unfortunately, virt-install was parsing the nodedev name to extract the
UUID of a mediated device. This fails with the new name format.
Fortunately, in libvirt 7.3.0, a <uuid> field was added to the xml
schema for mdev devices, so we can simply use this instead, and fall
back to the name parsing if it doesn't exist.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
For example, if both hotplugging and defining a new NIC, where we
generate the mac address, we need to use the initial generated device
XML for both operations, and not generate different MAC addresses
for each stage.
Resolves: https://github.com/virt-manager/virt-manager/issues/305
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Some test scenarios need to make sure different mac addresses would
_not_ be used in normal operations, but the test suite always generates
the same value. Add some hacks to let the test suite override the
default behavior and use incrementing addresses
Signed-off-by: Cole Robinson <crobinso@redhat.com>
If you call get_xml() on a device that's part of a Guest class,
the last element has correct indent but not the first element.
Steal the indent from the last element and prepend it to the returned
XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The libvirt test driver doesn't support hotplug. Add an env variable
to ignore failure, so we can get better test coverage here
Signed-off-by: Cole Robinson <crobinso@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
