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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- 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>
The code previously was just encoding the same defaults as libvirt,
which doesn't really add anything.
Instead, let's prefer type='emulator' model='tpm-crb', which
gives the most modern virtualization friendly config. When we don't
know if that will work, we mostly leave things up to libvirt to fill
in.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add extra PCIe root ports to enable q35 device hotplug to work out
of the box. A typical modern linux guest has 7-8 PCI devices added
by default, so this gives plenty of wiggle room.
The smart thing to do would be to count the attached PCI devices
and add 4-5 extra, but that takes more work and isn't trivial.
The number can be overridden on the cli with:
--controller q35_pcie_root_ports=X
Use =0 to go back to the old behavior.
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>
This was previously discussed here:
https://listman.redhat.com/archives/virt-tools-list/2020-September/msg00017.html
For the x86 + hvm case, failure to specify an --osinfo/--os-variant
OS, and failure to detect an OS from install media, will now throw
a big error:
```
--os-variant/--osinfo OS name is required, but no value was
set or detected.
This is now a fatal error. Specifying an OS name is required
for modern, performant, and secure virtual machine defaults.
If you expected virt-install to detect an OS name from the
install media, you can set a fallback OS name with:
--osinfo detect=on,name=OSNAME
You can see a full list of possible OS name values with:
virt-install --osinfo list
If your Linux distro is not listed, try one of generic values
such as: linux2020, linux2018, linux2016
If you just need to get the old behavior back, you can use:
--osinfo detect=on,require=off
Or export VIRTINSTALL_OSINFO_DISABLE_REQUIRE=1
```
The thread goes into more detail, but basically, for x86 VMs at least,
it's unlikely you will _ever_ want the default 'generic' behavior,
which gives gives no virtio, no PCIe, no usb3, IDE disks, slow
network devices, etc.
Many people use virt-install in scripts and CI, and this may now
cause breakage. The environment variable is there to help them
get things back to normal as quick as possible, but it will still
noisy up their logs with the warning to hopefully get them to make
a useful change to their virt-install invocations.
This is limited to x86, since that's where most of our defaults
historically differ, and where we can depend on libosinfo to give
the most accurate device info. This may be relevant to change for
other KVM architectures in the future.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We are about to change the some defaults around os handling. Let's
start recommending the nicer named --osinfo more, since new error
messages are going to promote it a bit as well
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I'm still seeing blog posts that recommend using
--os-type linux --os-variant XXX
Which has been a no op for a long time but is mostly harmless.
Current git would make this an error condition, but that's too
disruptive IMO. Just print a warning
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The canonical tool for this is `osinfo-query os`, which we still
reference in the man pages and in the list output.
However, we are about to make missing --os-variant fatal for common
usage, and I don't want to force users to install an extra tool just
to figure out what an acceptable --os-variant value is.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This recommendation came from an internal discussion. The cases are
* For block storage. This means guest requests are passed through
to the host device, which seems a more reasonable default than
ignoring them
* For sparse disk images we will create. discard=unmap helps preserve
the sparseness of the disk image. If a user requests non-sparse, they
are likely more concerned with performance than saving disk space,
so we leave the default as is. We limit this to disk images we will
create, since that's the easiest case to check, and it's less clear
if we should change the behavior here for an arbitrary existing
disk image.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
<os firmware='efi'> is the libvirt official way to do what we
historically implement with `--boot uefi`, and UEFI setup in
virt-manager.
Let's prefer libvirt's official method if the support is advertised
in domcapabilities.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We were not correctly accounting for the internal representation of
some fields, and just trying to a string comparison. We need to be
a bit smarter than that
Fixes: https://github.com/virt-manager/virt-manager/issues/356
Signed-off-by: Cole Robinson <crobinso@redhat.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>
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>
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 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>
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>
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>
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>
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>
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`
