[libvirt] libvirt: xen: Shutdown detection fixes

The issue is easy to observe when using virt-manager as a frontend. Its main window seems to open connections for the up/down main display once and then only repeats DomainGetInfo on the same connection to check whether the instance is up or shut down. The initial open on the connection sets the domain id to -1 for inactive managed domains. And once running, the hypervisor driver returns the status. But after shutdown, the domain cannot be found by the hypervisor driver and the domain info is obtained by the xend driver. However, that expects the domain id to be -1 for inactive domains. This is not true (anymore). In testing I found that domain/status seems to be always present and better suited to check whether a domain is running or not (0 for shutdown and 2 for running, there are probably other values, too). Beside the change, which does fix this problem, the question is whether there should be a mechanism that resets domain->id to -1 when the instance is found to be shut down. And if that should happen, should it be done by any sub-driver or by the unified driver. The second problem I observed when I shut down an instance from the vnc console provided by virt-manager. As soon as the instance was down, the log produced internal errors about every second. Found this again, to be related to the unified driver approach. The call that causes the many error messages is GetVcpus. While the instance is up, the hypervisor driver returns those. But after shutdown, the domain cannot be found by that driver. The xend driver works, though. So what happens is that the hypervisor driver logs an internal error but the call succeeds because the xend driver returns successful. This generally opens the question whether a sub-driver should log any errors (at least not on error level, maybe debug)? The second patch only quiets down the one message I saw repeated that often. There are some other errors logged without any obvious problems interacting with the instances, but those are by far less often. -Stefan Please cc: me on replies as I am (yeah still) not subscribed to this m-l. Thanks.