Since there's a release pending, this is a bit of future proofing
if win11 pops up in a future osinfo-db without accompanying
libosinfo firmware APIs landing
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Check it for test:/// URI too
* Move the whole logic into osdict.requires_firmware_efi
* Wrap it all in an exception handler the final API breaks us
* Add some coverage exclusions since this is currently untestable
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Windows 11 only supports EFI for installation, legacy BIOS is
discontinued as an option for new installs, unless you switch into
the console and run various regedit hacks in the installer.
This is not something we expect users to do, so osinfo-db will
report:
<firmware arch="x86_64" type="efi"/>
<firmware arch="x86_64" type="bios" supported="false"/>
for Windows 11.
When seeing 'bios' with supported=false, we need to prefer EFI
firmware no matter what.
For other OS we should stil prefer BIOS, because EFI blocks the usage of
internal qcow2 snapshots until some libvirt work is done to use the new
QMP snapshot commands.
Note this relies on a new API osinfo_os_get_complete_firmware_list
just added to libosinfo in version 1.10, so for most existing OS
distros this will be dormant functionality until they rebase to
latest libosinfo APIs.
The Windows 11 entry for osinfo-db will be the first that exposes
the metadata indicating lack of BIOS support.
Related: https://github.com/virt-manager/virt-manager/issues/310
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
`sudo` throws errors and is not even required to write the `disable`
file. Also add a message to the file that it was created by us
Signed-off-by: Cole Robinson <crobinso@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>
The Guest object passed in by the user is no longer altered in place,
instead we act on copies of the original XML. We need to rework how
unattended/cloudinit device altering works a bit to handle this.
There's some XML churn because working on parsexml gives different
output ordering, but this is expected.
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>
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>
We enable default graphics for all of ppc64, but really the only
thing we have ever tested is pseries, so make that clear.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This reverts commit 20d3bf9484.
Indeed graphics does work on aarch64, but for example, fedora
server aarch64 installs don't output any graphical output and only
put data on the serial console. So we would need to be more specific
about how we enable this if we make the change.
qemu 6.1, fairly new when we added this option, has an unfortunate
bug with >= 15 root ports, so we choose 14 instead of our original 16
https://gitlab.com/qemu-project/qemu/-/issues/641
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>
Otherwise going host-passthrough -> host-model -> host-passthrough
can cause libvirt validation errors or leave unintended bits in
the XML
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>
Break out the CPU secure stuff from being inline in the class, most
of the logic there is not relevant to understanding what the
domcapabilities API provides
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>
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>
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>
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>
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>
Currently we skip the warning if the user explicitly requests
`--osinfo generic`. Upcoming changes to the defaults here will make
it tempting to specify `--osinfo generic` just to make things work,
and we want to dissuade that, so enable the warning for that case too.
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>
Have the UI push users more towards better defaults, by discouraging
the 'generic' entry and offering the 'linuxXXXX' entries when their
distro or OS version is not in the list.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Previously we tried to use a combination of distro class and version
number to produce a correct ordering that was independent of the
osinfo short ID. The original intent was to have correct ordering
for Windows entries in the virt-manager UI, since the short ID
values are all over the place.
Nowadays that doesn't really matter, since we weed out old
unsupported entries by default. And in the mean time, our current
sort method gives some weird results like interspersing silverblue
entries with fedora entries.
Using a natural/human sort is simpler and handles things pretty well.
Change the UI to sort by the OS label too which preserves some of
the good behavior of original method
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>
Cole Robinson