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.

- docs/news.html.in libvirt.spec.in: update for the release
- po/*.po*: regenerate

When attempting to hotplug a virtio-serial console to a domain
that had no virtio-serial controllers (not even those that
are added by libvirt when some devices need them) at daemon startup,
report a user-friendly error:

error: Failed to attach device from console.xml
error: internal error: no virtio-serial controllers are available

instead of crashing the daemon:

Process terminating with default action of signal 11 (SIGSEGV): dumping core
 Access not within mapped region at address 0x8
   at 0x531028F: virDomainVirtioSerialAddrNext (domain_addr.c:916)
   by 0x531028F: virDomainVirtioSerialAddrAssign (domain_addr.c:1029)
   by 0x1CBF68: qemuDomainAttachChrDevice (qemu_hotplug.c:1565)
   by 0x1BCD5E: qemuDomainAttachDeviceLive (qemu_driver.c:7997)
   by 0x1BCD5E: qemuDomainAttachDeviceFlags (qemu_driver.c:8743)

Introduced in v1.2.14-30-g59033788.

Use xmlFreeDoc instead of plain xmlFree.

4 bytes in 1 blocks are definitely lost in loss record 9 of 1,084
    at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x70730D6: xmlStrndup (in /usr/lib64/libxml2.so.2.9.2)
    by 0x701E3DC: xmlNewDoc (in /usr/lib64/libxml2.so.2.9.2)
    by 0x70C39F8: xmlSAX2StartDocument (in /usr/lib64/libxml2.so.2.9.2)
    by 0x7017245: xmlParseDocument (in /usr/lib64/libxml2.so.2.9.2)
    by 0x7017606: xmlDoRead (in /usr/lib64/libxml2.so.2.9.2)
    by 0x5309DAD: virXMLParseHelper (virxml.c:742)
    by 0x5367584: virStoragePoolLoadState (storage_conf.c:1863)

libxl recently gained support for QXL video device.  Support
it in the libxl driver too.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>

A later change will use the PortAllocator for SPICE too.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

For HVM domains, vfb info must be populated in the libxl_domain_build_info
struct.  Currently this is done in the libxlMakeVfbList function, but IMO
it would be cleaner to populate the build_info vfb in a separate
libxlMakeBuildInfoVfb function.  libxlMakeVfbList would then handle only
vfb devices, simiar to the other libxlMake<device>List functions.

A future patch will extend libxlMakeBuildInfoVfb to support SPICE.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

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

The disk pool recalculates the pool allocation, capacity, and available
values each time through processing a newly created disk partition. This
created an issue with the allocation setting since the code used is shared
with the refresh path. Each path calls virStorageBackendDiskReadPartitions
which initializes the pool values and then processes the partition table
from the 'libvirt_parthelper' utility output with the only difference being
create passes a specific volume to be processed while refresh pass a NULL
indicating to process all volumes. That passed volume is check during the
virStorageBackendDiskMakeVol call to see if the current partition described
by the volume key already exists. If it exists, then no adjustments are
made to the allocation and the next entry in the output is checked.

For the create path this resulted in only the most recently created
partition size would be accounted for in the 'allocation' setting. This
patch thus checks whether the incoming volume is NULL before clearing
the pool allocation value.

Commit id '2ac0e647' for https://bugzilla.redhat.com/show_bug.cgi?id=1206521
was meant to be a generic check for the CreateVol, CreateVolFrom, and
DeleteVol paths to check if the storage backend's changed the pool's view
of allocation or available values.

Unfortunately as it turns out this caused a side effect when the disk backend
created an extended partition there would be no actual storage removed from
the pool, thus the changes would not find any change in allocation or
available and incorrectly update the pool values using the size of the
extended partition. A subsequent refresh of the pool would reset the
values appropriately.

This patch modifies those checks in order to specifically not update the
pool allocation and available for only the disk backend rather than be
generic before and after checks.

This reverts commit 2ac0e647.

There are also a couple that were very uninformatively just logging
the value of the pointer rather than the string itself:

* the "name" arg to virNodeDeviceLookupByName()
* wwnn and wwpn args to virNodeDeviceLookupSCSIHostByWWN()

All char*'s that make sense should now have their contents logged
rather than the pointer, and all %s args should now be inside
NULLSTR().

In a couple of cases, the node device driver (and the test node device
driver which likely copied it) was only logging "Node device not
found" when it couldn't find the requested device. This patch changes
those cases to log the name (and in the case when it's relevant, the
wwnn and wwpn) as well.

Virsh capabilities will list offline cpus as online when
libvirt is compiled with numactl option disabled. This
fix will list correct set of online cpus.

https://bugzilla.redhat.com/show_bug.cgi?id=1206114#c5

Reported by: zhenfeng wang <zhwang@redhat.com>

This never worked.

In 0.9.10 when this API was introduced, it was intended that
the SHRINK flag combined with DELTA would shrink the volume by
the specified capacity (to avoid passing negative numbers).
See commit 055bbf45.

When the SHRINK flag was finally implemented for the first backend
in 1.2.13 (commit aa9aa6a9), it was only implemented for the absolute
values and with the delta flag the volume is always extended,
regardless of the SHRINK flag.

Treat the SHRINK flag as a minus sign when used together with DELTA,
to allow shrinking volumes as was documented in the API since 0.9.10.

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