Store the emulator pinning cpu mask as a pure virBitmap rather than the
virDomainPinDef since it stores only the bitmap and refactor
qemuDomainPinEmulator to do the same operations in a much saner way.

As a side effect virDomainEmulatorPinAdd and virDomainEmulatorPinDel can
be removed since they don't add any value.

In case when <vcpu ... cpuset=""> is not specified, the vcpupin array is
not guaranteed to be allocated to def->vcpus. This would cause a crash
for TCG since it does not report thread IDs for vCPUs.

We remember driver name in a new field 'drivername' within
private parallels connection structure. When a new domain
is defined we use this name to set corresponding virtType.
We set VIR_DOMAIN_VIRT_VZ for 'vz' driver and
VIR_DOMAIN_VIRT_PARALLELS for 'Parallels'.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

Though parallels:///system is still accepted we will encourage users
to use vz:///system instead.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

We need to do this because we have just added a vz driver.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

We add this connection driver just as an exact copy with different
name to keep backward compatibility.
Vz stands for Virtuozzo, which is a new name of Parallels Cloud Server.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

If 'parallels:///system' uri is specified then connection is made to
'Parallels' driver and domain type will be VIR_DOMAIN_VIRT_PARALLELS.
In case of 'vz:///system' connection is established to 'vz' driver
and domain type will be VIR_DOMAIN_VIRT_VZ.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

As soon as we keep backward compatibility we treat this constant
as synonym to VIR_DOMAIN_VIRT_PARALLELS.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

This new name and constant will be used as substitutions for parallels driver one.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

Commit id '980b265d' neglected to check for a successful status when
deciding whether to release the device address for the RNG attach thus
the address would be released even though the device was added.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Commit id '862473fa' neglected to return the status from the
qemuDomainRemoveRNGDevice call in qemuDomainRemoveDevice causing
the function to always fail when receiving an RNG device unplug
event. Additionally the domain status/state would not be updated
in the processDeviceDeletedEvent path.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

If the domain has IOThreads defined, then audit the number started
at domain startup time.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Newer binutils 'ar' has added an option 'D' for deterministic
builds, and at least on rawhide, this option is enabled by default.
But it conflicts with the 'u' optimization where the linker only
modifies libraries based on file timestamps, but can result in
different library ordering based on which files were touched last.
Thus, it results in some noisy compilation, for every CCLD line:

  CCLD     libvirt_driver_qemu_impl.la
  ar: `u' modifier ignored since `D' is the default (see `U')

Upstream automake has decided that defaulting ARFLAGS to 'cru' is
no longer beneficial, and that switching the default to 'cr' will
both silence the noise and not penalize modern build systems.

https://lists.gnu.org/archive/html/automake-patches/2015-06/msg00000.html

But rather than wait for newer automake to propagate to all systems
that already have newer binutils, we might as well just use the new
default ourselves, even on older platforms.

* configure.ac: Default AR[_]FLAGS to 'cr', not 'cru'.
Signed-off-by: NEric Blake <eblake@redhat.com>

There are now many more reasons that virSocketAddrGetRange() could
fail, so it is much more informative to report the error there instead
of in the caller. (one of the two callers was previously assuming
success, which is almost surely safe based on the parsing that has
already happened to the config by that time, but it still is nicer to
account for an error "just in case")

Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653

This loop had automatic variable definitions mixed with code. This
patch moves the definitions to the top of the function and puts
cleanup for them at the bottom. No functional change.

Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653

virSocketAddrGetRange() has been updated to take the network address
and prefix, and now checks that both the start and end of the range
are within that network, thus validating that the entire range of
addresses is in the network. For IPv4, it also checks that ranges to
not start with the "network address" of the subnet, nor end with the
broadcast address of the subnet (this check doesn't apply to IPv6,
since IPv6 doesn't have a broadcast or network address)

Negative tests have been added to the network update and socket tests
to verify that bad ranges properly generate an error.

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=985653

This was revealed when I made a cut-paste mistake in an upgrade to
virSocketAddrGetRange(), leading to failure to check for the end
address being outside of the defined network, but a negative test case
that should have caught the error instead returned success.

The problem was that testRange in sockettest.c was written so that
when it expected a failure, even an "unexpected success" would be
considered as an "expected failure" because of the way the check in
testRange was done. testRange had this:

 if (gotsize < 0 || gotsize != size) {
     return pass ? -1 : 0;
 } else {
     return pass ? 0 : -1;
 }

but all the tests that expected a failure give "-1" as the expected
size. So in a case where we expect a failure, we would have pass ==
false and size == -1. If virSocketAddrGetRange() was incorrectly
*successful* (returned some positive number), then "gotsize != size"
would be, e.g. "276 != -1", so we would take the if clause and, since
pass == false, we would return 0 (success i.e. expected failure).

The solution is that in the case where we expect failure, we should
just ignore size - virSocketAddrGetRange() must return -1 in order for
us to report "expected failure == success".

Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653

Use a for loop instead of while.

Do not opencode c_isxdigit and virHexToBin.

Use virFileReadAll which reports an error when the file is larger
than the specified maximum.

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

This will allow us to use vshError() to report errors from inside
vshCommandOpt*(), instead of replicating the same logic and error
messages all over the place.

We also have more context inside the vshCommandOpt*() functions,
for example the actual value used on the command line, which means
we can produce more detailed error messages.

vshCommandOptBool() is the exception here, because it's explicitly
designed not to report any error.

This aligns it to the other vshCommandOpt*() functions.

Use vshCommandOptUInt() instead of parsing the value as a signed
integer and checking whether it's positive afterwards.

Improve comments as well.

I missed this in the first time around, thanks Michal for noticing.

The new tests deal with numeric options of three kinds: regular,
scaled and timeouts. For each, both valid and invalid inputs
are provided, hopefully covering all cases: this should allow us
to avoid regressions when changing the relevant code in virsh.

RBD API returns negative value of errno, in that case we can silently
ignore if RBD tries to delete a non-existent volume, just like FS
backend does.

We do update pool volume object list before we actually create any
volume. If buildVol fails, we then try to delete the volume in the
storage as well as remove it from our structures. The problem is, that
any backend that supports both buildVol and deleteVol would fail in this
case which is completely unnecessary. This patch causes the update to
take place after we know a volume has been created successfully, thus no
removal in case of a buildVol failure is necessary.

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

We allocate 16 bytes for IPv4 address and 55 bytes for interface
key, therefore we should read up to 15/54 bytes and let the last byte
reserved for terminating null byte in sscanf.

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

Incorporates fixes for cross-compiling to mingw on rawhide, where
gcc 5.1 changes detection of how to properly determine PRIdMAX.
Also picks up some improvements for compilation on Mac OS X.

* .gnulib: Update to latest, for at least mingw.
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit 198cc1d3 introduced libxl-lockd and libxl-sanlock config
files but forgot to add them to the spec file.  Follow-up commit
62b18d98 added the files to daemon-driver-libxl, but missed adding
them to the daemon package when configuring libvirt
--without-driver-modules.  In addition, commit 62b18d98 added
libxl-sanlock to daemon-driver-libxl, but it should be included
in lock-sanlock when libvirt is configured --with-sanlock.

The libxl tries to check if it's running in dom0 by parsing
/proc/xen/capabilities and if that fails it doesn't load.

There's no procfs interface in Xen on FreeBSD, so this check always
fails.

In addition to checking procfs, check if /dev/xen/xenstored, that's enough to
check if we're running in dom0 in FreeBSD case.

When shrinking a volume by a certain size, instead of typing
  vol-resize volume 1G --delta --shrink
we allow the convience of specifying a negative value:
  vol-resize volume -1G --delta --shrink
getting the same results with one more character.

A negative value only makes sense as a delta. Imply the
--delta parameter if the value is negative.

Still require --shrink, because the operation is potentially
destructive.

The guest firmware provides the same functionality as the pvpanic
device, and the relevant element should always be present in the
domain XML to reflect this fact, so add it after parsing the
definition if it wasn't there already.

The guest firmware provides the same functionality as the pvpanic
device, which is not available in QEMU on pSeries, so the domain
XML should be allowed to contain the <panic> element.

On the other hand, unlike the pvpanic device, the guest firmware
can't be configured, so report an error if an address has been
provided in the XML.

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

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

commit id 'bd00e00e' neglected to add the new adapter source options
into the if condition that allowed printing the <source> XML fields.
The <adapter type='fc_host'.../> doesn't require other options in order
to be complete.