These functions will handle PCIe devices and their link capabilities
to query some info about it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The block commit code looks for an explicit base file relative
to the discovered top file; so for a chain of:
  base <- snap1 <- snap2 <- snap3
and a command of:
  virsh blockcommit $dom vda --base snap2 --top snap1
we got a sane message (here from libvirt 1.0.5):
error: invalid argument: could not find base 'snap2' below 'snap1' in chain for 'vda'

Meanwhile, recent refactoring has slightly reduced the quality of the
libvirt error messages, by losing the phrase 'below xyz':
error: invalid argument: could not find image 'snap2' in chain for 'snap3'

But we had a one-off, where we were not excluding the top file
itself in searching for the base; thankfully qemu still reports
the error, but the quality is worse:
  virsh blockcommit $dom vda --base snap2 --top snap2
error: internal error unable to execute QEMU command 'block-commit': Base '/snap2' not found

Fix the one-off in blockcommit by changing the semantics of name
lookup - if a starting point is specified, then the result must
be below that point, rather than including that point.  The only
other call to chain lookup was blockpull code, which was already
forcing the lookup to omit the active layer and only needs a
tweak to use the new semantics.

This also fixes the bug exposed in the testsuite, where when doing
a lookup pinned to an intermediate point in the chain, we were
unable to return the name of the parent also in the chain.

* src/util/virstoragefile.c (virStorageFileChainLookup): Change
semantics for non-NULL startFrom.
* src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Adjust caller,
to keep existing semantics.
* tests/virstoragetest.c (mymain): Adjust to expose new semantics.
Signed-off-by: NEric Blake <eblake@redhat.com>

For block devices used as snapshot source the new snapshot code would
set the reuse flag. This inhibits to take snapshot without specially
preparing the block image before taking the snapshot.

Fortunately this is not a regression as only the new way of specifying
snapshot source is affected.

For the followin snapshot XML:
 <domainsnapshot>
   <disks>
     <disk name='vda' type='block'>
       <driver type='qcow2'/>
       <source dev="/dev/andariel/testsnap" />
     </disk>
   </disks>
 </domainsnapshot>

You'd get:
error: internal error: unable to execute QEMU command 'transaction': Image is not in qcow2 format

After this patch the snapshot is created successfully.

We create a 'lease_new' when we are adding new lease entry, then later
in the code we add the 'lease_new' into a 'leases_array_new' which
leads into the crash because we double free the 'lease_new'.

To prevent the double free we set the 'lease_new' to NULL after
successful append into the 'leases_array_new'.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

When virBhyveProcessStart() fails, it tries to unload
a guest that could have been already loaded using
bhyveload(8) to make sure not to leave it hanging in memory.

However, we could fail before loading a VM into memory,
so 'bhyvectl --destroy' command will fail and print
an error message that looks confusing to users.

So ignore errors when running this in cleanup.

virBhyveProcessStart() calls bhyveNetCleanup() if it fails. However,
it might fail earlier than networks are allocated, so modify
bhyveNetCleanup() to check if net->ifname is not NULL before
going further with the cleanup.

bhyveBuildNetArgStr() calls virNetDevTapCreateInBridgePort() and
passes tapfd = NULL, but tapfdSize = 1. That is wrong, because
if virNetDevTapCreateInBridgePort() crashes after successfully
creating a TAP device, it'll jump to 'error' label, that
loops over tapfd and calls VIR_FORCE_CLOSE:

   for (i = 0; i < tapfdSize && tapfd[i] >= 0; i++)

In that case we get a segfault.

As the bhyve code doesn't use tapfd, pass NULL and set tapfdSize to 0.

Report VIR_ERR_NO_STORAGE_VOL instead of a system error when lstat
fails because the file doesn't exist.

Fixes this problem in virt-install:

  https://bugzilla.redhat.com/show_bug.cgi?id=1108922Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>

Automatically allocate PCI addresses for devices instead
of hardcoding them in the driver code. The current
allocation schema is to dedicate an entire slot for each devices.

Also, allow having arbitrary number of devices.

The kernel's more broken than one would think. Various drivers report
various (usually spurious) values if the interface is in other state
than 'up' . While on some we experience -EINVAL when read()-ing the
speed sysfs file, with other drivers we might get anything from 0 to
UINT_MAX. If that's the case it's better to not report link speed.
Well, the interface is not up anyway.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

A future patch will add two-phase block commit jobs; as the
mechanism for managing them is similar to managing a block copy
job, existing errors should be made generic enough to occur
for either job type.

* src/conf/domain_conf.c (virDomainHasDiskMirror): Update
comment.
* src/qemu/qemu_driver.c (qemuDomainDefineXML)
(qemuDomainSnapshotCreateXML, qemuDomainRevertToSnapshot)
(qemuDomainBlockJobImpl, qemuDomainBlockCopy): Update error
message.
* src/qemu/qemu_hotplug.c (qemuDomainDetachDiskDevice): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

With one of my recent patches (1c702778) libvirt's capable of
reporting NUMA node locality for PCI devices. The node ID is
stored in pci_dev.numa_node variable. However, since zero is
valid NUMA node ID, the default is -1 as it is in kernel too.
So, if the PCI device is not tied to any specific NUMA node, the
default is then NOT printed into XML. Therefore, when parsing
node device XML, the <node/> element is optional. But currently,
if it's not there, we must set sane default, otherwise after
parsing in the memory representation doesn't match the XML. We
are already doing this in other place: udevProcessPCI().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit f5869657 accidentally changed the semantics of the
virDomainBlockCommit command; where it previously looked for
an explicit top argument from the top of the chain, it now
starts from the backing file of the top.  Of course, until
we allow active commits, the only difference it makes is in
the quality of the error message, but with code for active
commit coming soon, we need to support an explicit mention
of the active layer.

* src/qemu/qemu_driver.c (qemuDomainBlockCommit): Start looking
from top of chain.
Signed-off-by: NEric Blake <eblake@redhat.com>

qemuDomainGetImageIds did not check if there was a label
in the seclabel, thus crashing on
<seclabel type='none' model='dac'/>

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

Clean up some Coverity warnings from commit id '4dc5d8f1'

Clean up code to resolve Coverity RESOURCE_LEAK's from commit id's
'632b9600' and 'b739f807'.

A network disk might actually be backed by local storage. Also the path
iterator actually handles networked disks well now so remove the code
that skips the labelling in dac and selinux security driver.

Add a helper to do all the lookup steps and remove a ton of duplicated
code.

Most of the APIs now don't reach the cleanup section when the pool
object wasn't found and thus don't need to check before unlocking it.

Rework internal pool lookup code to avoid printing the raw UUID buffer
in the case a storage pool can't be found:

 $ virsh pool-name e012ace0-0460-5810-39ef-1bce5fa5a4dd
 error: failed to get pool 'e012ace0-0460-5810-39ef-1bce5fa5a4dd'
 error: Storage pool not found: no storage pool with matching uuid à¬à`X9ï_¥¤Ý

The rework is mostly done by switching the lookup code to the newly
introduced helper virStoragePoolObjFromStoragePool

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

Resolve two Coverity issues introduced by commit id '9b8d6e1e'
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit baafe668 introduced new leaseshelper with a crash of freeing
env string. Calling 'getenv()' inside 'virGetEnvAllowSUID()' may
return a static string and we definitely should not free it.

The author probably want to free the copy of that string.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

When saving domain with relabel=no, the file that gets created must have the
context set anyway.  That way restore can be successful without the need of
relabelling the file.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

Since commit d69415d4, vmware version is parsed from both stdout and
stderr. This patch makes version parsing work even if there is garbage
(libvirt debug messages for example) in the command output.

Add test data for this case.

If we're compiling on non-Linux platform, the virNetDevGetLinkInfo()
is a dummy function which barely logs debug message that getting link
info is not supported. However, while the debug message was prepared
for printing the interface name too, I actually forgot to pass the
variable which resulted in build error on platforms like mingw or
FreeBSD.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

While exposing the info under <interface/> in previous patch works, it
may work only in cases where interface is configured on the host.
However, orchestrating application may want to know the link state and
speed even in that case. That's why we ought to expose this in nodedev
XML too:

virsh # nodedev-dumpxml net_eth0_f0_de_f1_2b_1b_f3
<device>
  <name>net_eth0_f0_de_f1_2b_1b_f3</name>
  <path>/sys/devices/pci0000:00/0000:00:19.0/net/eth0</path>
  <parent>pci_0000_00_19_0</parent>
  <capability type='net'>
    <interface>eth0</interface>
    <address>f0:de:f1:2b:1b:f3</address>
    <link speed='1000' state='up'/>
    <capability type='80203'/>
  </capability>
</device>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the previous commit the helper function was prepared, so now
we can wire it up and benefit from it. The Makefile change is
required because we're including virnedev,h which includes
virnetlink.h which tries to include netlink/msg.h. However this
file is not under /usr/include directly but is dependent on libnl
used.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The purpose of this function is to fetch link state
and link speed for given NIC name from the SYSFS.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Currently it is not possible to determine the speed of an interface
and whether a link is actually detected from the API. Orchestrating
platforms want to be able to determine when the link has failed and
where multiple speeds may be available which one the interface is
actually connected at. This commit introduces an extension to our
interface XML (without implementation to interface driver backends):

  <interface type='ethernet' name='eth0'>
    <start mode='none'/>
    <mac address='aa:bb:cc:dd:ee:ff'/>
    <link speed='1000' state='up'/>
    <mtu size='1492'/>
    ...
  </interface>

Where @speed is negotiated link speed in Mbits per second, and state
is the current NIC state (can be one of the following:  "unknown",
"notpresent", "down", "lowerlayerdown","testing", "dormant", "up").
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 8ba0a58f introduced a compiler warning that I hit during
a run of ./autobuild.sh:

../../src/nodeinfo.c: In function 'nodeCapsInitNUMA':
../../src/nodeinfo.c:1853:43: error: 'nsiblings' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         if (virCapabilitiesAddHostNUMACell(caps, n, memory,
                                           ^

Sure enough, nsiblings starts uninitialized, and is set by a call
to virNodeCapsGetSiblingInfo, but that function fails to assign
through the pointer if virNumaGetDistances fails.

* src/nodeinfo.c (nodeCapsInitNUMA): Initialize nsiblings.
Signed-off-by: NEric Blake <eblake@redhat.com>

Jim Fehlig reported a regression found by libvirt-TCK tests:

> ~ # perl /usr/share/libvirt-tck/tests/qemu/100-disk-encryption.t
...
> ok 4 - defined persistent domain config
> # Starting inactive domain config
> libvirt error code: 1, message: internal error: unable to execute QEMU command
> 'cont': 'drive-ide0-0-1'
> (/var/cache/libvirt-tck/300-disk-encryption/demo.qcow2) is encrypted

Commit 2279d560 converted a boolean into a pointer with the intent of
transferring that pointer out of a temporary object into the caller's
data structure.  The temporary structure meant that meta->encryption
was always NULL on entry, so we could get away with blindly allocating
the pointer when the header said so.  But later, commit 8823272d
tweaked things to do backing chain detection in-place, rather than via
a temporary object; this has the net result that meta->encryption can
be non-NULL on entry.  Not only did this turn the latent behavior into
a memory leak, it is also a behavior regression: blindly allocating a
new pointer wipes out what secrets we already knew about the chain,
making it impossible to restart the domain.

Of course, no one in their right mind should be relying on qcow2
encryption - it is fundamentally flawed.  And sadly, the TCK tests
don't get run often enough, and this shows that our virstoragetest
does not exercise encrypted images at all.  Otherwise, we could
have avoided a release containing this regression.

* src/util/virstoragefile.c (virStorageFileGetMetadataInternal):
Don't nuke an already-existing encryption.
Signed-off-by: NEric Blake <eblake@redhat.com>

clang complains about possibly uninitialized variable:

vbox/vbox_snapshot_conf.c:1355:9: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
    if (!(xPathContext = xmlXPathNewContext(xml))) {
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So init 'ret' with NULL.

Now that qemu 2.0 allows commit of the active layer, people are
attempting to use virsh blockcommit and getting into a stuck
state, because libvirt is unprepared to handle the two-phase
commit required by qemu.

Stepping back a bit, there are two valid semantics for a
commit operation:

1. Maintain a 'golden' base, and a transient overlay. Make
changes in the overlay, and if everything appears to work,
commit those changes into the base, but still keep the overlay
for the next round of changes; repeat the cycle as desired.

2. Create an external snapshot, then back up the stable state
in the backing file. Once the backup is complete, commit the
overlay back into the base, and delete the temporary snapshot.

Since qemu doesn't know up front which of the two styles is
preferred, a block commit of the active layer merely gets
the job into a synchronized state, and sends an event; then
the user must either cancel (case 1) or complete (case 2),
where qemu then sends a second event that actually ends the
job.  However, until commit e6bcbcd3, libvirt was blindly
assuming the semantics that apply to a commit of an
intermediate image, where there is only one sane conclusion
(the job automatically ends with fewer elements in the chain);
and getting stuck because it wasn't prepared for qemu to enter
a second phase of the job.

This patch adds a flag to the libvirt API that a user MUST
supply in order to acknowledge that they will be using two-phase
semantics.  It might be possible to have a mode where if the
flag is omitted, we automatically do the case 2 semantics on
the user's behalf; but before that happens, I must do additional
patches to track the fact that we are doing an active commit
in the domain XML.  Later patches will add support of the flag,
and once 2-phase semantics are working, we can then decide
whether to relax things to allow an omitted flag to cause an
automatic pivot.

* include/libvirt/libvirt.h.in (VIR_DOMAIN_BLOCK_COMMIT_ACTIVE)
(VIR_DOMAIN_BLOCK_JOB_TYPE_ACTIVE_COMMIT): New enums.
* src/libvirt.c (virDomainBlockCommit): Document two-phase job
when committing active layer, through new flag.
(virDomainBlockJobAbort): Document that pivot also occurs after
active commit.
* tools/virsh-domain.c (vshDomainBlockJob): Cover new job.
* src/qemu/qemu_driver.c (qemuDomainBlockCommit): Explicitly
reject active copy; later patches will add it in.
Signed-off-by: NEric Blake <eblake@redhat.com>

All snapshots information will be deleted from the vbox XML, but
differencing disks will be kept so the user will be able to redefine the
snapshot.

The machine is unregistered and its vbox XML file is changed in order to
add snapshot information. The machine is then registered with the
snapshot to redefine.

This structure contains the data to be saved in the VirtualBox XML file
and can be manipulated with severals exposed functions.
The structure is created by vboxSnapshotLoadVboxFile taking the
machine XML file.
It also can rewrite the XML by using vboxSnapshotSaveVboxFile.

It will be needed for the future patches because we will
redefine snapshots

This fixes startup of a domain with:
<seclabel type='none' model='dac'/>
on a host with selinux and dac drivers and
security_default_confined = 0

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

The qemu driver always adds these options to the qemu commandlines,
but the commandline parser didn't recognize them, so sending a
libvirt-generated qemu commandline to its own argvtoxml would always
result in a warning message and a qemu namespace added to the
xml. Since the options don't add any functionality to the domain, they
should just be ignored (similar to -S).

Note that we can't yet add a test for this to qemuargv2xmltest,
because we would have to add QEMU_CAPS_NODEFCONFIG and
QEMU_CAPS_DEVICE to the capabilities for any corresponding
xml2argvtest, and QEMU_CAPS_DEVICE would necessitate having support
for parsing a memballoon device in order for qemuargv2xmltest to
pass. So we wait to add a test for -nodefconfig and -nodefaults until
after adding support for parsing -device virtio-balloon-*.

4d06af97 introduced a possible memory
leak of the memory allocated into the "cpu" pointer in
parallelsBuildCapabilities in the case "nodeGetInfo()" would fail right
after the allocation. Rearrange the code to avoid the possibility of the
leak.

Found by Coverity.