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>
The virtiofs in domcapabilities is used as a proxy to tell us whether
libvirt is new enough to allow bare memory access mode=shared', So We
enable/disable this checkbox according to it.
When we configure shared memory access, If the 'memfd' is available in
domcaps, We configure VM to use it as memory backend because it doesn't
need addtional host setup for vhost-user devices, Otherwise use 'file'
as backend.
If all of numa nodes explicitly defined memAccess=shared, We mark this
checkbox as checked even if virtiofs isn't exposed in domcapabilities.
In this case:
- It doesn't matter what the value of access mode of memoryBacking is
because access mode of memoryBacking will be overridden per numa node
by memAccess attribute.
- Although the checkbox is disabled, the checked checkbox presents actual
status about shared memory access to users.
Signed-off-by: Lin Ma <lma@suse.com>
Linux memfd memory backend doesn't require any host setup, We prefer to
use it as the simplest memory XML adjustments to make virtiofs works.
Signed-off-by: Lin Ma <lma@suse.com>
Check whether virtiofs is exposed in domcapabilities, We can use it as a
proxy for 'libvirt is new enough to allow bare memory access mode=shared'
as well.
Signed-off-by: Lin Ma <lma@suse.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>
This address string decomposing is strictly and virt-* cli feature.
Move it to cli.py to make that explicit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Apparently nodedev drm XML can link to a parent device that we can't
look up?
We shouldn't be trying to do the full address string compare anyways,
so just try the name lookup, which would improve the error here too
Fixes: #328
Signed-off-by: Cole Robinson <crobinso@redhat.com>
https://listman.redhat.com/archives/virt-tools-list/2022-January/msg00012.html
On xen, a guest reboot will trigger a non-error viewer-disconnected
signal, but we treat it like an error, which makes it difficult to
reconnect to the VM console.
If there's no error message raised, treat the disconnect like a
non-error cases.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
... with the 'hypervisor default' address. In this case, we need to
force set port=-1 in the XML, to make the changes actually stick
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The sync_vcpus_topology method will sometimes set the self.vcpus prop,
but other times leave it unset. This is confusing an unhelpful
behaviour. Both callers have logic to set the self.vcpus prop
to a default value of sync_vcpus_topology failed to do so. It makes
more sense to just pass this default value in.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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>
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>
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>
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>
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>
Cole Robinson