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>

Add some more tests of what happens when we restrict a lookup
to begin at a point in the middle of a chain.  In particular,
we want to ensure that a parent is not found when starting at
the child.  This commit also demonstrates that we have a slight
difference in behavior on what parent we report when filtering
is in effect; as the determination of the parent affects the
code in block commit, exposing this in the testsuite will help
justify changes in future patches that tweak the semantics of
what lookups are allowed.

* tests/virstoragetest.c (testStorageLookup): Test user input.
(TEST_LOOKUP_TARGET): Add parameter.
(mymain): Add lookup tests.
Signed-off-by: NEric Blake <eblake@redhat.com>

The next patch will be adding tests, including adding a parameter
for testing more conditions.  For ease of review of that patch, I
want to create common context lines that don't change when the new
tests are added (it's easier to visually review additions than it
is to review an entire chunk of tests rewritten into another
larger chunk of tests).

* tests/virstoragetest.c (mymain): Add a parameter and renumber
the lookup tests.
Signed-off-by: NEric Blake <eblake@redhat.com>

Typing chain->backingStore->backingStore gets old after a while;
introduce some alias variables to make the test more compact.

* tests/virstoragetest.c (mymain): Introduce some shorthand.
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>

When the test is failing but the debug output isn't enabled the
resulting line would look ugly like and would not contain the actual
difference.

TEST: virstoragetest
      .................chain member 1!chain member 1!chain member 1!

Store the member index in the actual checked string to hide this problem

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>

Peter's review of an early version of my addition of active block
commit pointed out some issues that I was copying from the block
copy code; fix them up now before perpetuating them.

For virsh commands that manage a single API call, it's nice to have
a 1:1 mapping of options to flags, so that we can test that
lower-layer software handles flag combinations correctly.  But where
virsh is introducing syntactic sugar to combine multiple API calls
into a single user interface, we might as well make that interface
compact.  That is, we should allow the shorter command-line of
'blockcopy $dom $disk --pivot' without having to explicitly specify
--wait, because this isn't directly a flag passed to a single
underlying API call.

Also, my use of embedded ?: ternaries bordered on unreadable.

* tools/virsh-domain.c (cmdBlockCopy): Make --pivot, --finish,
and --timeout imply --wait. Drop excess ?: operators.
* tools/virsh.pod (blockcopy): Update documentation.
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>

The vcpupin command allowed specifying a negative number for the --vcpu
argument. This would the overflow when the underlying virDomainPinVcpu
API was called.

 $ virsh vcpupin r7 -1 0
 error: numerical overflow: input too large: 4294967295

Switch the vCPU variable to a unsigned int and parse it using the
corresponding function.

Also improve the vcpupin test to cover all the defects.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1101059Signed-off-by: NJincheng Miao <jmiao@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

To follow the new semantics of the vshCommandOptToU* functions convert
this one to reject negative numbers too. To allow using -1 for "maximum"
semantics for the vol-*load two bandwidth functions that use this helper
introduce vshCommandOptULongLongWrap.

To follow the new semantics of the vshCommandOptToU* functions convert
this one to reject negative numbers too. To allow using -1 for "maximum"
semantics for the two bandwidth functions that use this helper introduce
vshCommandOptULWrap. Although currently the migrate-setspeed function
for the qemu driver will reject -1 as maximum.

Use virStrToLong_uip instead of virStrToLong_ui to reject negative
numbers in the helper. None of the callers expects the wraparound
"feature" for negative numbers.

Also add a function that allows wrapping of negative numbers as it might
be used in the future and be explicit about the new semantics in the
function docs.

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

Try -fstack-protector-strong first on Linux. If that fails,
fall back to -fstack-protector-all.

This option only makes sense for -fstack-protector.
With -fstack-protector-all or -fstack-protector-strong,
functions are protected regardless of buffer size.

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

These warnings have already been added to $dontwarn.

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

Add 'Bhyve' in hypervisor list reported by 'virsh -V'
if it's compiled it.

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>

Roman Bogorodskiy reported a syntax-check failure when using
FreeBSD; complaining that:

prohibit_empty_first_line
tools/libvirt_win_icon_16x16.ico:1:
tools/libvirt_win_icon_32x32.ico:1:
tools/libvirt_win_icon_48x48.ico:1:
tools/libvirt_win_icon_64x64.ico:1:
maint.mk: Prohibited empty first line

In reality, the first 'line' of that file is NOT empty; but since
it is a binary file, awk is not required to handle it gracefully.
The simplest solution is to exempt all image files from syntax
checks in the first place - after all, we only store them in git
because they are inconvenient to regenerate, but they are not our
preferred format for making modifications, and syntax check should
only cover files that we are likely to modify.

* cfg.mk (VC_LIST_ALWAYS_EXCLUDE_REGEX): Exempt images.
(exclude_file_name_regexp--sc_prohibit_empty_lines_at_EOF): Simplify.
(exclude_file_name_regexp--sc_trailing_blank): Likewise.
Signed-off-by: NEric Blake <eblake@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>