The current implementation calls _new_object_cb, which isn't
expected to be run from a non-main thread, and can cause crashes.
https://bugzilla.redhat.com/show_bug.cgi?id=1457170
Switch the impl to just wait for 3 seconds for the pool to show
up in our cache.
The cb_add_new_pool callback will add a newly created storage pool
into virt-manager's cache so we don't have to wait for the libvirt
event to be handled.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1435064
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Add virtuozzo hypervisor to connection list.
Add radio buttons for choosing VM or container virtualization type.
New wizard window for setting template name for containers.
When creating a storage volume, it wouldn't show up in the list
since the refresh signaling was busted.
Code was using VIR_STORAGE_POOL_EVENT_REFRESHED which was dropped
from lifecycle event type, refresh is introduced as top level
event.
We need to tweak refresh() handling to work similar to the shared
XML and status caching in libvirtobject.py: when the user manually
invokes the refresh() operation, and storage events are set up,
we just invoke the refresh() but let the event loop handle
refreshing the cache.
This fixes a backtrace when invoking a manual refresh via the
host details dialog
When new pool objects appear, we call refresh() on them, to ensure
we have the latest data (in case manual changes were made to the
storage pool directory behind libvirt's back, which is quite common).
However with the storage event support, this results in lots of
REFRESHED signals during initial connection startup, which kick
off redundant object polling.
Avoid storage REFRESHED events if they come in before the connection
is finished starting up to skip this redundant polling.
Otherwise this triggers some event calls and results in double
polling during connection startup. Doesn't cause any issues, just
spams the logs and needless libvirt calls
In case that libvirtd is stopped, we could receive another type of error
from libvirt "libvirtError: internal error: client socket is closed".
This one is usually reported from local connection.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
pygobject doesn't seem to choke on debug_leak_check anymore, so we
can use it to find object leaks. just doing a few for now since it's
generally not a big deal.
It happens every now and then that a libvirt bug means calling XMLDesc
on an object will always fail. For example:
https://bugzilla.redhat.com/show_bug.cgi?id=1225771
We don't handle this very well and it can bleed into many other parts of
the code in a bad way. So if the initial polling of the object fails,
blacklist it entirely and ignore it for all future polling.
It's largely the same, but now
- The code is better organized
- The UI is much more streamlined, only showing relevant fields when
required.
- We warn about the hostname/URI cases that we know libvirt will error on
- Drop some of the attempts at being smart, and just mimic what libvirt
will do.
We tried to split up status vs XML refreshing, but they are tied together
in various ways (like the runtime XML changes when a VM starts). This
was breaking console connecting when starting a VM
All major drivers either support it, or don't support save at all,
so I think we can safely drop it. If people still need it they can
get by with virsh.
We've had multiple requests over the years for something similar. People
might have to connect to multiple IP addresses, or really large hostnames,
that become difficult to distinguish in the UI.
Add a field in the host details page that allows setting a custom name,
and store it in gsettings.
Unify all the callers, and use some UI ellipsizing to handle
crazy long hostnames.
This drops the conn name collision prevention stuff which can be
useful when you have lots of similar connection names. But upcoming
patches will make it mostly redundant.
Chen Hanxiao