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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This will test spice related changes. Follow up patches will change this
behavior to remove spice related devices.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The libvirt test driver supports more APIs now, so we are getting
a different error message.
Extend the grep= string to work with both old and new libvirt
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will let us match more complex output, and match error message
differences across libvirt versions
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The test driver was broken for some time and our mdev tests were failing
on most libvirt versions. Recently this was fixed in libvirt 10.4.0 so
skip these tests unless we have new enough libvirt.
This requires extracting some mdev devices from many-devices test case.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Cover additional scenarios: direct kernel boot, use of cloud-init,
installation from CDROM and unattended installation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
I have no idea if the generated config is optimal, but this
at least provides a base for us to confirm when defaults change.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The libvirt test driver now has implementations for hotplug routines,
which broke string matching for one case.
Loosen it up to work for old and new libvirt versions.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This commit added support for cpu physical address bits control, It's
useful for VMs with huge amount of ram.
E.g.
--cpu Cascadelake-Server,maxphysaddr.mode=emulate,maxphysaddr.bits=46
Signed-off-by: Lin Ma <lma@suse.com>
Anything passed to --boot should imply --install no_install=yes
in the absence of other --install options. This is historically
what we've done but we regressed in 4.1.0
Resolves: https://github.com/virt-manager/virt-manager/issues/426
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Each bit here is part of the CLI API, we need to be sure we are
covering each one. Extend the test suite to hit one case we are missing
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Properly setting the metadata cache size can provide better performance
in case of using big qcow2 images.
This patch introduces two driver options:
* driver.metadata_cache.max_size
* driver.metadata_cache.max_size.unit
E.g. --disk ...,driver.type=qcow2,\
driver.metadata_cache.max_size=2,\
driver.metadata_cache.max_size.unit=MiB
BTW, Metadata cache size control is currently supported only for qcow2.
Regarding how to properly caluclate the cache size of qcow2, Please refer
to qemu's documentation.
Signed-off-by: Lin Ma <lma@suse.com>
The diff_compare rstrip() should never have been added, let's fix
it once and for all but dealing with missing newlines in the diff
helper
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It allows to set the thread pool size to optimize spawning worker threads
for the default event loop in real time environment. For example:
--iothreads defaultiothread.thread_pool_min=8,\
defaultiothread.thread_pool_max=16
Signed-off-by: Lin Ma <lma@suse.com>
These two optional attributes allow setting lower and upper boundary for
number of worker threads for given IOThread. For example:
--iothreads iothreads=2,\
iothreadids.iothread0.id=1,\
iothreadids.iothread1.id=2,\
iothreadids.iothread1.thread_pool_min=8,\
iothreadids.iothread1.thread_pool_max=16
Signed-off-by: Lin Ma <lma@suse.com>
This allows support for host/guest clipboard sharing when using vnc
guests (and possibly other graphics types in the future). This channel
is similar to the spicevmc channel, but it contains a couple additional
options to enable/disable clipboard sharing and specify the mouse mode.
In the case of spice, these settings are specified on the 'graphics'
element, but for qemu-vdagent, they are specified on the channel. For
example:
--channel=qemu-vdagent,source.clipboard.copypaste=on,source.mouse.mode=client
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Originally we thought it would be for the clouduser, but then
we changed it, and now it's ambiguous. Rename it to make the
usage clear, and add an alias to keep any users working
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* 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>
Via the virt-manager UI we aren't converting relative path to
absolute path, even though we do it internally when needed.
We were benefiting from this in the test suite in some ways, so we
need to adjust tests to strip out the dev dir on XML comparison
Signed-off-by: Cole Robinson <crobinso@redhat.com>
And move the path to not be rooted in /dev, which doesn't make
sense for a directory pool, and triggers some special /dev handling
in virtinst that we don't want in the common testing path.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It _is_ type=logical, so make it clear in the naming. Plus we
already have a type=disk pool named pool-disk
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This adds the power of --xml to individual device options. For example
this makes it easier to make custom XML changes for a single --disk
device from both virt-install and virt-xml
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a virt-xml option to refresh a VM to use the latest machine
type version for the machine type it's currently using. Ex:
pseries-2.11 -> pseries
pc-q35-5.0 -> q35
This is useful for when qemu deprecates and removes the machine type
out from under you, or to pick up bug fixes.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Libvirt defaults to PCIe for arm32/aarch64 and riscv -M virt too.
Rename q35_pcie_root_ports to num_pcie_root_ports and extend the
logic to those archs too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It's generally not as valuable for non-x86 where we don't have the
history of supporting non-virtio OSes, but as time goes on it will
likely become more relevant for non-x86 arches, so let's make this
change now to get ahead of it.
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>
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>
