It's really a useless hold over from the days when we manually talked
to HAL.
One semi useful bit lost in the shuffle is the option to repoll cdroms
for media. But since virt-manager allows attaching a device to the
VM regardless of whether it notices media change, this plumbing is
really overkill. If libvirt ever grows nodedev events we will get this
much easier.
If the mainloop is backed up, tick_send_signals might not run before
another conn.tick call is scheduled by the tick thread. conn.tick would
then be operating on incorrect self._vms since it was never updated.
Don't run another tick() until tick_send_signals has released a lock.
https://www.redhat.com/archives/virt-tools-list/2015-April/msg00009.html
Reported-by: Charles Arnold <carnold@suse.com>
When XEN is used, disable domain events and use polling.
On RHEL-5.9 virDomainInfo() seems to not report correctly the domain
status when called immediately after the event is received.
Solves: https://bugzilla.redhat.com/show_bug.cgi?id=1177207
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Rework things a bit to simplify everything we pass around.
The specific bug fix is making sure we update the object list in place,
otherwise the event loop detects it as the VM being deleted and closes
the details window.
This needlessly hits the network too much. The places where it's
important to have up to date info will either manually call pool
refresh, or give the user an refresh button.
And clean up the API mess while we are at it. Treat the key as an opaque
value that users shouldn't depend on.
Besides the improved code clarity and API layout, this will help diagnose
'key error' issues, since we'll see an object name instead of UUID which
is hard to trace back.
path_exists will check to ensure the volume actually survives a pool
refresh, incase it was deleted behind libvirt's back. This makes the
delete dialog happier at least.
- Run the connection
- Restart libvirtd, connection is auto closed
- Re-run the connection
- Manually stop it, see errors in the logs about unknown event IDs
We need to unconditionally clear our event ID list
If a remote network connection stalls, the tick queue becomes backed
up while we wait for the hung connection to continue. While this
happens, the queue is filled up with other requests to poll the hung
connection.
When the connection finally times out, the tick thread closes the
connection via an idle callback. However before that callback gets
a chance to run, all the other poll requests for the dead connection
are processed, all launching their own error dialog.
Mark the connection as 'closing' before conn.close is scheduled, and
use it to short circuit the tick() routine.
Even if XML didn't change. This is what we do in the non-event case.
Makes it more clear if details->apply triggers a define, but our
change didn't stick for any reason.
Otherwise this interrupts the close/cleanup routine, and the connection
never appears to disconnect in the UI. This causes error dialog spamming
when libvirtd goes down.
