qvm-kill (and Manager) should be more defensive

[rootkovska]

While resolving some problem I manually killed a domain using xl destroy (an old habit, sorry). The domain is still being listed by visrh list and qvm-ls, but not by xl list. This causes:

1. Qubes Manager to pop up an exception and further become unusable...
2. qvm-kill failing also with the following exception:

[joanna@dom0 ~]$ qvm-kill disp1
Traceback (most recent call last):
  File "/usr/bin/qvm-kill", line 56, in <module>
    main()
  File "/usr/bin/qvm-kill", line 50, in main
    vm.force_shutdown()
  File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1989, in force_shutdown
    self.libvirt_domain.destroy()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1103, in destroy
    if ret == -1: raise libvirtError ('virDomainDestroy() failed', dom=self)
libvirt.libvirtError: internal error: Failed to destroy domain '30'

[marmarek]

Sorry, this is libvirt issue. If its internal state desynchronize with actual state, the only way (and sometimes not even enough) is to restart libvirt daemon. Other issues of this type:

• Make libvirt notice network device disconnection when backend domain is shut down #1426
• Implement facilities for handling unexpected physical removal of block devices #1082

I'll work with upstream on this, but probably after 3.1 final release.

[marmarek]

As for unusable Qubes Manager - this is duplicate of #990

[marmarek]

Generally: not our bug.