libxl: support interface type=network

Add support for <interface type='network'> in the libxl driver.
libxl: limit support for specifying an interface script

Generally, <interface> ... <script> is only supported for
type='ethernet'.  Due to the long and pervasive use of

  <interface type='bridge'>
    ...
    <script path='foo'/>
  </interface>

in Xen domain configuration, it was agreed to allow the use
of <script> with type='bridge' for backwards compatibility.  See
the following discussion thread

http://www.redhat.com/archives/libvir-list/2013-April/msg00755.html

This patch limits the use of <script> to interface types ethernet
and bridge, raising an unsupported config error if <script> is
specified for all other interface types.

While at it, use VIR_ERR_CONFIG_UNSUPPORTED instead of
VIR_ERR_INTERNAL_ERROR when reporting unsupported interface types.
storage: encryption: Add deep copy function for storage encryption
util: seclabel: Add deep copy function for device labels
util: storagefile: Introduce helper to free storage source perms

It will also be reused later.
util: Don't require full disk definition when getting imagelabels

The image labels are stored in the virStorageSource struct. Convert the
virDomainDiskDefGetSecurityLabelDef helper not to use the full disk def
and move it appropriately.
security: Sanitize type of @migrated in virSecurityManagerRestoreAllLabel

Also remove one spurious ATTRIBUTE_UNUSED guarding the @migrated
argument.
security: Rename virSecurityManagerSetImageLabel to *Disk*

I'm going to add functions that will deal with individual image files
rather than whole disks. Rename the security function to make room for
the new one.
interface: report link state for bonds and vlans too

The interface state for bonds and vlans does seem to reflect the state
of the underlying physical devices, at least in some cases, so it
makes sense to allow reporting it (netcf now does).

The link state/speed for bridge devices is meaningless though, so we
don't even look for it.
interface: move parsing of bridge attributes into appropriate function

For some reason the bridge stp mode and delay were put directly into
the "bridge" case of the switch in virInterfaceDefParseXML(), although
they are inside the <bridge> element, and so should be parsed in the
function created for that purpose - virInterfaceBridgeDefFormat().
interface: clean up virInterfaceDefParseXML

the switch cases for the 4 different interface types had repetitive
code which has now been pulled out as common. While touching those
lines, some extra usage of "!= NULL" etc has been eliminated to make
things more compact and inline with current coding practices.

NB: parentIfType == VIR_INTERFACE_TYPE_LAST means that this is a
toplevel interface (not a subordinate of a bridge or bond). Only
toplevel interfaces can have a start mode, mtu, or IP address element.
interface: clean up virInterfaceDefDevFormat

This modifies the formatting function of virInterface to be a proper
mirror of the parse function, including the addition of a
"parentIfType" arg so that we can decide whether or not it is
appropriate to emit the elements that are only in toplevel interfaces,
as well as the <link> element (which isn't allowed for bridge
interfaces).

Since the restructuring of the code necessarily changes the order of
some of the elements, some test case data had to be updated.
nodeinfo: Introduce @arch to linuxNodeInfoCPUPopulate

So far, we are doing compile time decisions on which architecture is
used. However, for testing purposes it's much easier if we pass host
architecture as parameter and then let the function decide which code
snippet for extracting host CPU info will be used.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
virNodeParseNode: Propagate host architecture

As in previous commit, there are again some places where we can do
runtime decision instead of compile time. This time it's whether the
'topology/physical_package_id' is allowed to have '-1' within or not.
Then, core ID is pared differently on s390(x) than on the rest of
architectures.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
nodeinfotest: Print error if cpuinfo file can't be opened

Currently, we are opening the cpuinfo file via fopen() which if fails
doesn't print any error message. We should do that instead.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
virNodeParseSocket: Take ARM into account

The virNodeParseSocket() function tries to get socked ID from
'topology/physical_package_id' file. However, on some architectures
the file contains the -1 constant which makes in turn libvirt think
the info extraction was unsuccessful. If that's the case, we need to
overwrite the obtained integer with zero like we are doing for other
architectures.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
cpu_arm: Support all ARM processors we know about

So far three ARM processor families are known to libvirt,
however the cpu driver knows only about one of them. This
make host initialization on the other two fail:

2014-06-17 13:35:41.419+0000: 6840: info : libvirt version: 1.2.6
2014-06-17 13:35:41.419+0000: 6840: error : cpuNodeData:342 : this function is not supported by the connection driver: cannot get node CPU data for armv6l architecture
2014-06-17 13:35:41.433+0000: 6840: warning : virQEMUCapsInit:943 : Failed to get host CPU

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
libxl: Use cooperative resume for migration

Migration code specifies the problematic non-cooperative resume mode
which is a known issue with Xen's libxl [1].  Instead, use the better
supported cooperative mode.

Without this, guests BUG() in xen_irq_resume after failing to bind
still-bound event channels.

[1] http://bugs.xenproject.org/xen/bug/30
Split out CCW address allocation

Just code movement and rename.
Properly check the return value of CCWAddressAsString

It returns NULL on failure. Checking if the negation of it
is less than zero makes no sense. (Found by coverity after moving
the code)

In another case, the return value wasn't checked at all.