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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
The MDEV devices listed in the "Add New Virtual Hardware" page, are a
concatenation of parent device name and MDEV device name, eg:
css_0_0_0014 mdev_b204c698_6731_4f25_b5f4_894614a05ec0_0_0_0014. The
parent name is duplicated in here, as the MDEV device name itself includes
a part of the parent name in libvirt version 7.8.0 and later. So, this patch
changes the MDEVs listed in "Add New Virtual Hardware" page to only display
the MDEV device
name(eg:mdev_b204c698_6731_4f25_b5f4_894614a05ec0_0_0_0014), when the
new naming convention is used.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.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>
Libvirt now validates that all <hostdev> elements refer to distinct host
devices. The test suite violates that constraint by trying to build a
new guest with the same USB devices added to the guest twice, to
validate the various host device syntax options.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirt now validates that all <hostdev> elements refer to distinct host
devices. The test suite violates that constraint by trying to hot-add a
device that alreadye exists in the config.
Signed-off-by: Daniel P. Berrangé <berrange@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
