Commit Graph

1861 Commits

Author SHA1 Message Date
Cole Robinson
2c477f3302 domain: cpu: Use host-passthrough by default on x86
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>
2022-02-16 14:03:44 -05:00
Cole Robinson
d488472837 tests: cli: Organize the qemu/kvm section a bit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-16 12:31:52 -05:00
Cole Robinson
8eeebce4bc tests: more capabilities data cleanup
* Merge kvm-x86_64-domcaps{-q35} variants
* Add -oldfirmware for explicitly testing secboot fallback setup
* Use consistent kvm-x86_64-domcaps-* prefix

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-16 12:31:52 -05:00
Cole Robinson
0cce75addc capabilities: Remove some XML parsing we don't use
These have been used in the past, but no current code touches them,
so drop the parsing infrastructure

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-16 12:31:52 -05:00
Cole Robinson
49f54a294b virtinst: cpu: drop host-copy support
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>
2022-02-16 12:31:52 -05:00
Cole Robinson
26ecf8a5e3 virt-install: Make missing --osinfo fatal for most cases
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>
2022-02-16 12:25:13 -05:00
Cole Robinson
c57b0f7d46 tests: Add output test for --osinfo linux2020
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-12 12:56:00 -05:00
Cole Robinson
95cdbf9e8f osdict: Drop usb-tablet checking
Historically over time it's been more likely that an issue is reported
for osinfo-db missing the usb-tablet annotation. So for example we
always enable it for the default 'generic' case. We also want to
enable it for osinfo's 'unknown' case too.

Rather than add another check for that, let's just drop the osinfo
checking entirely. Some very old OS don't support usb-tablet, but
specifying it for those cases doesn't cause issues AFAIK, and users
can override it with `--input none` if they want.

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-12 12:51:05 -05:00
Cole Robinson
9c54c116fa cli: Recommend --osinfo more over --os-variant
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>
2022-02-12 11:53:09 -05:00
Cole Robinson
c2fb5ad402 tests: Add grep= annotation for every invalid test
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-12 11:53:09 -05:00
Cole Robinson
3e794d2d96 virt-install: Turn --os-type into a no op and warning
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>
2022-02-12 11:53:09 -05:00
Cole Robinson
96a40b1143 cli: Add --os-variant list option to print OS name values
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>
2022-02-12 11:53:09 -05:00
Cole Robinson
a39bd561b0 addhardware: tweak mdev inactive UI
- Move tooltip to the tree row instead of the finish button
- Some style cleanups
- Add a hack so we can hit it in the test suite

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-12 11:24:44 -05:00
Cole Robinson
6baa327d67 cli: Add --tpm active_pcr_banks support
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-03 16:33:08 -05:00
Cole Robinson
8377b7f7b6 details: Remove 'detect zeroes' UI
After checking with qemu devs, this option is not really recommended
for common usage and doesn't get used much in practice. So I don't
think it is suitable for the UI

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-03 13:50:53 -05:00
Cole Robinson
381aa4050c devices: disk: Set discard=unmap by default for some cases
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>
2022-02-03 13:42:49 -05:00
Cole Robinson
1ab6dd50be devices: video: Use virtio default more often
This is from Gerd's suggestions here:
https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/

When the guest supports it, we should use virtio. qxl is on the way
out, and the benefits are marginal and add a security and maintenance
burden.

While here, check domcaps that qxl or virtio are actually available.
Modern qemu has device modules, so device support may not be installed.

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-02-03 13:42:49 -05:00
Cole Robinson
c3e9db5f3a createvm: Tweaks to new UEFI pref
* Make it clear in code and UI that this is x86 only. Other arches
  either require UEFI (aarch64) or don't support it
* Drop the internal 'bios' values since we don't handle them and may
  not want them anyways, since when win11 support lands we will need
  to explicitly throw an error if the user tries to force bios
* Add UI tests

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-31 14:18:42 -05:00
Cole Robinson
16fecb482a cli: Add --memdev target.{current,block,requested}
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-27 09:57:20 -05:00
Cole Robinson
a489d69dc6 cli: Add virtio option driver.page_per_vq=on
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-26 17:11:56 -05:00
Cole Robinson
01f52fed97 cli: Add --launchSecurity kernelHashes=yes|no
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-26 17:08:27 -05:00
Cole Robinson
1a1bbe99f8 cloner: Improve error message about unimplemented rbd support
Fixes: https://github.com/virt-manager/virt-manager/issues/340

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-26 16:58:45 -05:00
Cole Robinson
5003f0432e details: Add os.firmware=efi in the firmware selector UI
Let users choose libvirt's os.firmware=efi setting in the UI, putting
it about the firmware path list, since it's the preferred default
these days.

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-26 13:23:27 -05:00
Cole Robinson
3013889727 guest: Use os.firmware=efi for --boot uefi, if it is supported
<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>
2022-01-26 11:59:51 -05:00
Cole Robinson
6c3b5def81 netlist: Revive portgroup UI
I removed Portgroup UI in 4c3c53f773 release 3.0.0, but there's been
a steady stream of requests to bring it back. It seems it's commonly
used with some certain openvswitch config.

Maint burden isn't too bad. Let's bring it back

Fixes: https://github.com/virt-manager/virt-manager/issues/169

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-25 16:01:17 -05:00
Cole Robinson
dfef112b2a virt-xml: Fix device lookup by integer properties
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>
2022-01-25 13:43:58 -05:00
Cole Robinson
3d915717dd tests: Add domcaps coverage for filesystem checks
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-25 12:26:14 -05:00
Cole Robinson
c9ce3ad84e tests: uitests: Add some coverage for 'Enable shared memory'
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-25 12:26:14 -05:00
Cole Robinson
f13c8d87fb guest: Remove the hyperv + uefi workaround for win7 + win2k8r2
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>
2022-01-25 12:05:45 -05:00
Cole Robinson
8896944d59 tests: Fix missing XML output from some virt-xml tests
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-25 12:05:45 -05:00
Cole Robinson
11365e6f43 tests: update x86 capabilities data
Using qemu 6.1.0 and libvirt 7.6.0 on Fedora 35

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-25 12:05:45 -05:00
Cole Robinson
b39aa1ea79 tests: Clean up URI building and naming
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-25 10:32:03 -05:00
Cole Robinson
5444bf32f5 tests: Remove unnecessary KVMIBM data
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-25 10:22:24 -05:00
Cole Robinson
adae7bf1e5 tests: Remove old rhel7 domcaps data
This doesn't hit any code path we care about anymore

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-25 10:22:15 -05:00
Daniel P. Berrangé
eb58c09f48 virtinst/guest: enable a TPM by default if UEFI is present
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>
2022-01-21 17:49:15 -05:00
Cole Robinson
4a933b0223 uitests: Test graphics port fix
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-21 13:19:57 -05:00
Daniel P. Berrangé
883419c214 virtinst: allow to force create topology from scratch
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>
2022-01-20 14:16:39 -05:00
Daniel P. Berrangé
9a578e1ac5 virtinst: prefer cores when exposing topology to the guest
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>
2022-01-20 14:16:38 -05:00
Daniel P. Berrangé
e1c8866163 virtinst: validate that the CPU topology is sane
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>
2022-01-20 14:16:38 -05:00
Daniel P. Berrangé
552759bef4 tests: re-arrange CPU topology test for clarity
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-01-20 14:16:38 -05:00
Daniel P. Berrangé
609007c9ca virtinst: make CPU topology defaulting take account of dies
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>
2022-01-20 14:16:38 -05:00
Daniel P. Berrangé
c1491ae142 virtinst: set dies in topology to 1
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>
2022-01-20 14:16:38 -05:00
Daniel P. Berrangé
7b68fe1a5e virtinst: take account of 'dies' when calc vcpu count from topology
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-01-20 14:16:38 -05:00
Daniel P. Berrangé
95eb8dda9b virtinst: add missing 'dies' parameter for --vcpus
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>
2022-01-20 14:16:38 -05:00
Cole Robinson
9e133de21a diskbackend: Restrict format->driver_type even more
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>
2022-01-19 14:21:48 -05:00
Simon Kobyda
2676640979 Disk pool volumes should be always attached as "raw" disks
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".
2022-01-19 14:11:46 -05:00
Simon Kobyda
59e24f6bb9 tests: Introduce disk attachment from pool of type 'disk' 2022-01-19 14:09:47 -05:00
Cole Robinson
acaca061be uitests: top off test coverage
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-17 17:11:18 -05:00
Cole Robinson
4f02ccd7b5 uitests: Mock virtBootstrap
It's historically flakey to keep it + skopeo + virt-sandbox
all working, let's just mock it

Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-17 15:13:12 -05:00
Cole Robinson
92c0c4e1a7 tests: Fix test coverage after osdict changes
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2022-01-17 14:51:36 -05:00