If we restart libvirtd while VM was doing external memory snapshot, VM's
state be updated to paused as a result of running a migration-to-file
operation, and then VM will be left as paused state. In this case we must
restart the VM's CPUs to resume it.
Signed-off-by: NWang King <king.wang@huawei.com>

Rather than extraneous VIR_FREE's depending on where we are in the code,
move them to the top of the loop and in the cleanup path.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Remove duplicated code - make one simple path through
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the check for an already existing vHBA to the top of the function.
No sense in first decoding a provided parent if the next thing we're going
to do is fail if a provided wwnn/wwpn already exists.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Use the ret = -1, goto cleanup, etc. rather than current hodgepodge.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If a <parent> is not supplied in the XML used to create a non-persistent
vHBA, then instead of failing, let's try to find a "vports" capable node
device and use that.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Extract out code from virNodeDeviceGetParentHost into helpers - it's
going to be reused in upcoming patches to search on more fields

Create virNodeDeviceFindVPORTCapDef in order to return a virNodeDevCapsDefPtr
of the VPORT_OPS and virNodeDeviceFindFCParentHost to use the function and
generate an error message if the device doesn't have the capability.

Also clean up the processing in virNodeDeviceGetParentHost to remove
need for goto's.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

All other entries in the release notes omit the leading period,
and so should this one in order to maintain consistency.

Commit 4b951d1e missed the fact that the
VM needs to be resumed after a live external checkpoint (memory
snapshot) where the cpus would be paused by the migration rather than
libvirt.

When generating the plain text version of the contributor
guidelines we add a ludicrous amount of vertical whitespace
in some spots. Tweak the XSLT stylesheet and regenerate the
now much better looking file.

Again, not something that I'd hit, but there is a chance in
theory that this might bite us. Currently the way we decide
whether or not to create /dev entry for a device is by marching
first four characters of path with "/dev". This might be not
enough. Just imagine somebody has a disk image stored under
"/devil/path/to/disk". We ought to be matching against "/dev/".
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Not that I'd encounter any bug here, but the code doesn't look
100% correct. Imagine, somebody is trying to attach a device to a
domain, and the device's /dev entry already exists in the qemu
namespace. This is handled gracefully and the control continues
with setting up ACLs and calling security manager to set up
labels. Now, if any of these steps fail, control jump on the
'cleanup' label and unlink() the file straight away. Even when it
was not us who created the file in the first place. This can be
possibly dangerous.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Imagine you have a domain configured in such way that you are
assigning two PCI devices that fall into the same IOMMU group.
With mount namespace enabled what happens is that for the first
PCI device corresponding /dev/vfio/X entry is created and when
the code tries to do the same for the second mknod() fails as
/dev/vfio/X already exists:

2016-12-21 14:40:45.648+0000: 24681: error :
qemuProcessReportLogError:1792 : internal error: Process exited
prior to exec: libvirt: QEMU Driver error : Failed to make device
/var/run/libvirt/qemu/windoze.dev//vfio/22: File exists

Worse, by default there are some devices that are created in the
namespace regardless of domain configuration (e.g. /dev/null,
/dev/urandom, etc.). If one of them is set as backend for some
guest device (e.g. rng, chardev, etc.) it's the same story as
described above.

Weirdly, in attach code this is already handled.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Just a name, I know, but it bothered me a lot since it does not refer
to XML.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

That way all links work even if you click them in a subdirectory.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

When updating the source file in commit bd4f4d16, I forgot
that we also store the generated plain text version in git and
didn't regenerate it.

I also missed one spot that required an additional <p> tag, so
fix both mistakes in one go.

Commit b9cc2483 introduced a new #define but neglected
to format it properly, thus breaking syntax-check.

Some of the <li> elements in the "General tips for contributing
patches" section were missing the corresponding inner <p> element,
so they ended up all lumped together.

Clang 3.9 refuses to compile the existing code with the
following error:

  util/virfirewall.c:425:20: error: passing an object that undergoes
                             default argument promotion to 'va_start'
                             has undefined behavior [-Werror,-Wvarargs]
      va_start(args, layer);
                     ^
  util/virfirewall.c:420:37: note: parameter of type 'virFirewallLayer'
                             is declared here
                     virFirewallLayer layer,
                                      ^

This happens because 'layer' is of type virFirewallLayer, which
is an enum type and not a standard type such as eg. void* or int.

To solve the issue, turn virFirewallAddRule() from a very thin
wrapper around virFirewallAddRuleFullV() to a macro that expands
to a call to virFirewallAddRuleFull() - itself a very thin wrapper
around the aforementioned virFirewallAddRuleFullV() - with no loss
of functionality or type safety.

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

If a secret was not provided for what was determined to be a LUKS
encrypted disk (during virStorageFileGetMetadata processing when
called from qemuDomainDetermineDiskChain as a result of hotplug
attach qemuDomainAttachDeviceDiskLive), then do not attempt to
look it up (avoiding a libvirtd crash) and do not alter the format
to "luks" when adding the disk; otherwise, the device_add would
fail with a message such as:

   "unable to execute QEMU command 'device_add': Property 'scsi-hd.drive'
    can't find value 'drive-scsi0-0-0-0'"

because of assumptions that when the format=luks that libvirt would have
provided the secret to decrypt the volume.

Access to unlock the volume will thus be left to the application.

Currently, bhyvexml2xmltest does only one test. We can do better.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the next patch we will need a stable mac address for
<interface/>.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

After c07d1c1c got merged it uncovered couple of broken domain
XMLs for bhyvexml2argv test. Some disk drives had incompatible
type of address configured.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

After 478ddedc a bug is fixed where we wrongly presumed loopack
device name on non-Linux systems. It's lo0. However, the fix is
not reflected in the tests which are failing now.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If the nss module is disabled we don't need to build the
supplementary library for it either.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If the nss module is disabled we shouldn't run the tests that
include it either.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The plugin depends on more modules than we currently check for,
i.e. network driver and yajl library.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the Makefile in tests/ we initialize couple of variables like
test_programs, test_libraries and test_helpers. These variables
contain all the targets that we need to build in order to run
the test suite. So we initialize test_programs and test_helpers
and then conditionally add targets to them depending on what we
are building with. Then we repeat the same process with
test_libraries. It makes no sense to have two separate if-endif
sequences.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since the internal implementation relies on a json parser being
available, it make no sense to run this test if there's none
available.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Due to nature of operations we do over the string list (more
precisely due to how virStringListRemove() works), it is not the
best idea to use dataFree callback. Problem is, on MAC address
remove, the string list remove function modifies the original
list in place. Then, virHashUpdateEntry() is called which frees
all the data stored in the list rendering @newMacsList point to
freed data.

==16002== Invalid read of size 8
==16002==    at 0x50BC083: virFree (viralloc.c:582)
==16002==    by 0x513DC39: virStringListFree (virstring.c:251)
==16002==    by 0x51089B4: virMacMapHashFree (virmacmap.c:67)
==16002==    by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352)
==16002==    by 0x50EF4FD: virHashUpdateEntry (virhash.c:415)
==16002==    by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129)
==16002==    by 0x51092D5: virMacMapRemove (virmacmap.c:346)
==16002==    by 0x402F02: testMACRemove (virmacmaptest.c:107)
==16002==    by 0x403F15: virTestRun (testutils.c:180)
==16002==    by 0x4032C4: mymain (virmacmaptest.c:205)
==16002==    by 0x405A3B: virTestMain (testutils.c:992)
==16002==    by 0x403D87: main (virmacmaptest.c:237)
==16002==  Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd
==16002==    at 0x4C2AD6F: realloc (vg_replace_malloc.c:693)
==16002==    by 0x50BB99B: virReallocN (viralloc.c:245)
==16002==    by 0x513DC0B: virStringListRemove (virstring.c:235)
==16002==    by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124)
==16002==    by 0x51092D5: virMacMapRemove (virmacmap.c:346)
==16002==    by 0x402F02: testMACRemove (virmacmaptest.c:107)
==16002==    by 0x403F15: virTestRun (testutils.c:180)
==16002==    by 0x4032C4: mymain (virmacmaptest.c:205)
==16002==    by 0x405A3B: virTestMain (testutils.c:992)
==16002==    by 0x403D87: main (virmacmaptest.c:237)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In virMacMapRemoveLocked() we have two variables: @macsList and
@newMacsList. Obviously, @newMacsList is supposed to hold pointer
to modified list but in fact it holds pointer to the old list.
It's confusing.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

7fa7fe22 updated gnulib to the latest upstream commit,
but forgot to include the corresponding bootstrap changes.

Required for the copyright year bump to keep 'make syntax-check'
happy, and also pulls in several portability fixes.

* .gnulib: Update to latest.
* bootstrap: Resync from upstream.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add the description for <physical>... One is a new feature - the API
and the other is an improvement for the volume xml output.

A CT disk statistics is reported with prefix "hdd" and we should use
it to extract data.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Before, boot devices information for CTs was always empty and we
didn't indicate that containers can boot from disk.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Virtuozzo SDK interface doesn't differ filesystems from disks and sees them as disks.
Before, we always mistakenly presented disks based on files as filesystems, which is
not completely correct. Now we are going to show either disks or filesystems depending
on a hint, which uses boot device section of VZ config. Though this information
doesn't change booting order of a CT, it is used by vz libvirt interface as a hint
for libvirt representation of disks. Since now, if we have filesystems in input xml,
then we add them to VZ booting devices list and rely on this information to show
corresponding libvirt xml.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Implicit devices like controllers are confusing for CTs and
function virDomainDefAddImplicitDevices never intended to be called
for CTs.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

This is necessary to show CTs created out of libvirt correctly.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>