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>

The udevFreeIfaceDef function in the udev interface driver
just duplicates code from virInterfaceDefFree. Delete it
and call the standard API instead.

Fix the udevGetIfaceDefVlan method so that it doesn't
store pointers to the middle of a malloc'd memory
area.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Pushed under trivial rule

Pushed under trivial rule.