The controller element supports non-disk controller types too.

https://bugzilla.redhat.com/show_bug.cgi?id=960958

Make the Xen domain stats / peek and node memory driver
methods unconditionally call the sub-drivers which are
guaranteed to be open.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call into the XenD or XM drivers for autostart
handling, since they are guaranteed to be open

Make the Xen domain scheduler parameter methods directly
call into XenD or Xen hypervisor drivers
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make the domain attach/dettach driver methods directly call
into either the XenD or XM drivers
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make the domain define/undefine driver methods directly call
into either the XenD or XM drivers
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Directly call either the XenD or XM driver when starting
a persistent domain
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Directly call either XenD or the XM driver for handling
domain define operations.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

All the migration code is done by the XenD subdriver which
can be assumed to always be present
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The xenUnifiedDomainGetXMLDesc driver can assume that
the XM and XenD drivers are always present
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call the XenD APIs for save/restore, since that
driver will always be open.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make the xenUnifiedDomainGetInfo and xenUnifiedDomainGetState drivers
call the correct sub-driver APIs directly.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Simplify the Xen memory limit driver methods to directly call
the most appropriate sub-driver
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The xenGetHostname entry point in the xenUnifiedDriver table
was unused.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make xenUnifiedDomainGetOSType directly call either the
xenHypervisorDomainGetOSType or xenDaemonDomainGetOSType
method depending on whether the domain is active or not.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call the xenDaemonDomainDestroyFlags API
since the XenD driver is always available.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make the xenUnifiedDomainShutdownFlags and xenUnifiedDomainReboot
driver methods unconditionally call the XenD APIs for shutdown
and reboot. Delete the unreachable impls in the XenStore driver.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Update xenUnifiedDomainSuspend and xenUnifiedDomainResume to
unconditionally invoke the XenD APIs for suspend/resume. Delete
the impls in the hypervisor driver which was unreachable.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call xenDaemonLookupByUUID, since the XenD
driver must always be present.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally invoke the xenHypervisorLookupDomainByID,
xenHypervisorLookupDomainByUUID or xenDaemonLookupByName
for looking up domains. Fallback to xenXMDomainLookupByUUID
and xenXMDomainLookupByName for legacy XenD without inactive
domain support
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call xenDaemonCreateXML in the
xenUnifiedDomainCreateXML driver, since the XenD
driver is always present.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The XenStore driver is mandatory, so it can be used unconditonally
for the xenUnifiedConnectListDomains & xenUnifiedConnectNumOfDomains
drivers. Delete the unused XenD and Hypervisor driver code for
listing / counting domains
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call into xenHypervisorGetMaxVcpus and
xenDaemonNodeGetInfo respectively, since those drivers
are both mandatory
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The hypervisor driver is mandatory, so the the call to
xenHypervisorGetVersion must always succeed. Thus there
is no need to ever run xenDaemonGetVersion
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There is no point iterating over sub-drivers since the user
would not have a virConnectPtr instance at all if opening
the drivers failed. Just return 'Xen' immediately.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Since the Xen driver was changed to only execute inside libvirtd,
there is no scenario in which it will be opened from a non-privileged
context. Thus all the code dealing with opening the sub-drivers can
be simplified to assume that they are always privileged.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The Xen driver uses a macro GET_PRIVATE as a supposed shorthand
for 'xenUnifiedPrivatePtr priv = (xenUnifiedPrivatePtr) (conn)->privateData'.
It does not in fact save any lines of code, and obscures what is
happening. Remove it, since it adds no value.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Some of the Xen sub-drivers have checks against the
VIR_CONNECT_RO flag. This is not required, since such
checks are done at the top level before the driver
methods are invoked
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The Xen hypervisor driver checks for 'priv->handle < 0' and
returns -1, but without raising any error. Fortunately this
code will never be executed, since the main Xen driver always
checks 'priv->opened[XEN_UNIFIED_HYPERVISOR_OFFSET]' prior
to invoking any hypervisor API. Just remove the redundant
checks for priv->handle
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>