Commit ac63014c introduced a regression in the conversion of Xen
xm config to XML by emitting an empty <cmdline>.  Prior to this
commit, <cmdline> was omitted if the xm config was missing (or
contained an empty) 'extra='.

In addition to extra= xm supported a root= option which was supposed
to be incorporated into the final command line. Handle that for "virsh
domxml-from-native xen-xm". Tested with the libxl backend.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>

The function 'xmlSaveFormatFileEnc' has a last option to set
if you want to format dumped xml with whitespaces or not.

Older libxml2, the one used in RHEL6, take this option as it is
but newer libxml2 check this option if it's true or not. This
small difference somehow makes things messy on RHEL6 and generated
xml had extra new line and extra whitespaces.

We should pass 1 instead if -1 because the -1 confuses the libxml2.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

On RHEL6 the vboxsnapshotxmltest fails because of wrong xml that
is generated by libvirt. However the core issue is in the xml data
itself with the wrong indentation.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

s/QEemu/QEMU/g

The version command now takes the --daemon parameter for a while and the
output example was pretty outdated.

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

Only allow the access if it is a KVM domain which has a NIC which wants
non-userspace networking.

This addresses https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1322568Signed-off-by: NSerge Hallyn <serge.hallyn@ubuntu.com>

there is a segfault in the vbox driver when taking a snapshot in the
following functions:
- vboxDomainGetXMLDesc
- vboxSnapshotGetReadWriteDisks
- vboxSnapshotGetReadOnlyDisks

The virStorageSourcePtr in virDomainDiskDef was not correctly allocated.

(The problem stems from the fact that commit 4dc5d8f and commit bc3f5f19
were written in one order but applied in another; so each tested in
isolation passed, but the combination introduces the problem due to
changed semantics).
Signed-off-by: NEric Blake <eblake@redhat.com>

In virVBoxSnapshotConfRemoveFakeDisks and
virVBoxSnapshotConfDiskIsInMediaRegistry the disk array constructed from
all the disks would be leaked at the end of the function and on
allocation errors. Also the temporary disk list would be leaked.

Add a cleanup section and free the memory properly.

Found by coverity.

On re-allocation failure the function would leak already allocated
memory.

Coverity checks for patterns of handling return values of functions.
Some recent addition must have tripped a threshold where coverity now
complains that we usually check the return value of virUUIDGenerate but
don't do it in one place. Add a check to make coverity happy.

The cleanup path in networkBuildDhcpDaemonCommandLine could cause a
crash by freeing uninitialized pointer.

When copying entries from the old lease file into the new array the old
code would copy the pointer of the json object into the second array
without removing it from the first. Afterwards when both arrays were
freed this might lead to a crash due to access of already freed memory.

Refactor the code to use the new array item stealing helper added to the
json code so that the entry resides just in one array.

Instead of reporting an error and terminating, rewrite the file with
the newly learned info.

The value is provided via environment and causes a crash if not defined.

Add a checker to determine whether a JSON object is an array and a
helper to steal objects from a JSON array.

Use consistent formatting of function headers:
- two newlines separating functions
- function return type on separate line
- one argument per line

Commit 7c6fc394 introduced a regression in the XML produced for older
clients.  The argument at the time was that clients shouldn't be
depending on output-only data for something that is only going to
be triggered for a transient guest; but John Ferlan reported that
the automated testsuite was such a client.  It's better to be safe
than sorry by guaranteeing back-compat cruft.  Note that later
patches will be using <mirror> for active block commit, but there
we don't have to worry about back-compat.

* src/conf/domain_conf.c (virDomainDiskDefFormat): Restore old
style output when necessary.
* docs/schemas/domaincommon.rng: Validate back-compat style.
* docs/formatdomain.html.in: Update the documentation.
* tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-old.xml:
Update tests.
* tests/qemuxml2argvdata/qemuxml2argv-disk-mirror.xml: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

We have a policy of avoiding enum types in structs in our public
API, because it is possible for a client to choose compiler options
that can change the in-memory ABI of that struct based on whether
the enum value occupies an int or a minimal size.  But we missed
this for virDomainBlockJobInfo.  We got lucky on little-endian
machines - if the enum fits minimal size (a char), we still end
up padding to the next long before the next field; but on
big-endian, a client interpreting the enum as a char would always
see 0 when the server supplies contents as an int.

* include/libvirt/libvirt.h.in (virDomainBlockJobInfo): Enforce
particular sizing.
Signed-off-by: NEric Blake <eblake@redhat.com>

I noticed that the web page lacked documentation on block jobs:
http://libvirt.org/html/libvirt-libvirt.html#virDomainBlockJobType
not only for the recently added active commit, but also for all
the other job types.

* include/libvirt/libvirt.h.in (virDomainBlockJobType): Document
recent addition.
Signed-off-by: NEric Blake <eblake@redhat.com>

During guest migration, if the domain xml is bigger than 16384 which is
easily possible for a guest with good number of disks, message encode fails
for xdr_remote_domain_migrate_perform3_ret().
So, Increase the COOKIE_MAX to STRING_MAX value.
Signed-off-by: NShivaprasad G Bhat <shivaprasadbhat@gmail.com>

This new element is there to represent PCI-Express capabilities
of a PCI devices, like link speed, number of lanes, etc.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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>

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>