Always force a network selection. If we have to fall back to
manual bridge UI because nothing else exists, show a warning.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This case should be exceedingly rare, and we already show
a visual warning about 'no network'. So let's drop this
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The versions we are warning about are all over 4 years old, and
these warnings were initially just informative to help users know
when the config wasn't going to work. Drop most of it. Still warn
in the UI when a VM misconfig will prevent spice GL from working
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We need to wire up some craziness to make path permission
searching fail, but this is a critical area to get correct
so it is worth it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Don't have the caller call a validate function, they all catch
errors anyways. Let the build step raise error if there's a problem
Drop some validation checks that libvirt should be performing for us
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I don't think many, if any, people are using virt-manager with
openvz. Drop the specific handling the filesystem UI, users can use
the raw XML editor if they need special behavior
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Basically all non-domain objects just need to check to see
if status changed, which will also refresh the XML if
a change occurs. This all works to ensure we are initializing
XML at tick time
Signed-off-by: Cole Robinson <crobinso@redhat.com>
All drivers that support the listAll APIs, which we depend on,
also are new enough to support isActive, so stop checking support
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The intent is this would select the newly created pool in the
UI after the user creates it. With async events though this
is racy and doesn't tend to work as expected.
It's fixable but it would likely require hanging around for
a period of time waiting for the signal to fire, which
takes more work. Just drop it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We only showed it for disk pools, and it determined whether we
partition the device or not. I don't think this gets much
usage and there are much better tools for that job. If users
aren't sure what they are doing they can lose data.
Drop the UI, which always defaults to build=False for disk
pools, and expect the user to partition the device themselves.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will let us test some difficult code paths in the uitests.
Rework the `--test-options first-run` behavior to use a temporary
keyfile rather than the memory backend, to unify the code paths
Signed-off-by: Cole Robinson <crobinso@redhat.com>