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>
- 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>
With virt-manager application, it is possible to add inactive node
devices(eg: mediated device) in host system to guest system. But it is
impossible to start a guest system with inactive node devices. Also,
it is not yet possible to start a node device with virt-manager
application. So, the user cannot use the inactive node devices.
This patch disables the "finish" button and provides a tip, when
inactive node devices are selected. So, it is not possible to add
inactive node devices to the guest system.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
https:// needs to link to the exact site, not the debian.org redirect,
otherwise we get browser cert warnings
Fixes: #360
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Commit 85307b9bd2 changed the default
value for 'accessmode' from 'passthrough' to 'mapped', but forgot to
update the documentation in the man page.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
If a domain is edited outside of virt-manager (e.g. via virsh
edit) then this is reflected in the GUI (in the domain HW details
tab). However, if domain title or description is updated outside
of virt-manager (virsh desc) then this change is not reflected.
This is simply because the corresponding event emitted by libvirt
is not listened to.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
With virt-manager application, it is possible to add inactive node
devices(eg: mediated device) in host system to guest system. But it is
impossible to start a guest system with inactive node devices. Also,
it is not yet possible to start a node device with virt-manager
application. So, the user cannot use the inactive node devices.
This patch disables the "finish" button and provides a tip, when
inactive node devices are selected. So, it is not possible to add
inactive node devices to the guest system.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
If python3-libguestfs is installed, virt-manager will use it
automatically to fetch guest OS icons, installed application lists,
and some other details.
In practice though the libguestfs integration usually doesn't work,
because most virt-manager created VMs have disks image in a location
only accessible to root, and our libguestfs usage needs the disks
accessible by the app user.
When it does work, we don't cache the results across app runs, so
libguestfs spawns lots of inspecting VMs every app startup, with
lots of log chatter and CPU spiking.
Then there's the confusion that app behavior can noticeably change
through the install of another package and an app restart.
I think it's simpler from a maintenance perspective to disable this
by default. If we fix those two big issues then maybe we can change
it back in the future
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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>
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>
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>
* 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>
Possible values are BIOS (default) and UEFI.
The firmware used is determined by libvirt unless a specific firmware is
selected from the Customize dialog.
See https://bugzilla.redhat.com/show_bug.cgi?id=1997882
It creates a lot of churn.
Adjust phantom grid rows + columns while we are at it, not sure why
those counts are suddenly wrong
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This reverts commit aaabb44ac7.
I figured out how to trigger this: it's when scaling is enabled.
To maintain VM aspect ratio, we have to constrain the size of the
viewer widget. When the widget is smaller than the VM window, the
viewport widget is visible. This change made the viewport the default
theme color, rather than black.
Problem is, in the non-scaling case, we don't shrink the viewer
widget but let it expand to fill the whole area. This is necessary
to get the 'Autoresize VM with window' option to work, but is also
simpler in the cdoe. The viewport widget is not visible, and gtk-vnc
and spice-gtk paint the non VM owned areas as black. AFAICT that's not
configurable in any way.
So after this change we have differing behavior for scaled and
non-scaled cases, which is confusing and visually kinda comes off as
a bug.
So this reverts back to the old behavior and explains all this in
a comment.
setuptools still doesn't natively provide some infrastructure we
need, but newer versions will keep 'import distutils' working until
those issues are addressed. I think we need to reorder imports to take
advantage of it though. It silences some deprecation warnings at
least
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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>
<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>
This replaces the pattern:
Guest.set_uefi_path(Guest.get_uefi_path())
With a single entrypoint
Guest.enable_uefi()
to immediately change the guest config to use UEFI, using our
default logic.
This will make it easier to change that logic in the future, like
using <os firmware='efi'> instead of hardcoded paths
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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>
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>
Strip back the logic to:
* Only try to toggle source_type=memfd and access_mode=shared
* Disable the field if guest has any <numa> config
* Disable the field if domcaps does not report virtiofs and memfd
This is the simplest future proof case, though it will exclude some
legit guest configs and some libvirt+qemu back compat.
My feeling is the <numa> stuff in particular is pretty advanced, so if
users have it configured they can toggle shared memory via the XML
without too much trouble.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Cole Robinson