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

Since shrinking a volume below existing allocation is not allowed,
it is not possible for a successful resize with VOL_RESIZE_ALLOCATE
to increase the pool's available value.

Even with the SHRINK flag it is possible to extend the current
allocation or even the capacity. Remove the overflow when
computing delta with this flag and do the check even if the
flag was specified.

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

It is necessary to have unpolluted screen when connecting to
parallels driver via virsh.
Otherwise a lot of unexpected output one will get on the console.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

It's not a problem at all and causes virt-manager to break down.

Note: netcf 0.2.8 and earlier generates invalid XML for a bond with no
interfaces anyway, so in that case this error in libvirt is never
reached since we fail earlier.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>

The QMP command, like the interrupt reinjection logic it's connected
to, is only implemented in QEMU when TARGET_I386 is defined, so
checking for its availability on any other architecture is pointless.

On the other hand, when we're on x86, we shouldn still make sure that
rtc-reset-reinjection is available and refuse to set the time
otherwise.

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

The code already exists there, it just modified different flags.  I just
noticed this when looking at the code.  This patch is better to view
with bigger context or '-W'.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

When we change system clock to years ago, a certain CPU may use up 100% cputime.
The reason is that in function virEventPollCalculateTimeout(), we assign the
unsigned long long result to an INT variable,
        *timeout = then - now; // timeout is INT, and then/now are long long
        if (*timeout < 0)
            *timeout = 0;
there's a chance that variable @then minus variable @now may be a very large number
that overflows INT value expression, then *timeout will be negative and be assigned to 0.
Next the 'poll' in function virEventPollRunOnce() will get into an 'endless' while loop there.
thus, the cpu that virEventPollRunOnce() thread runs on will go up to 100%.

Although as we discussed before in https://www.redhat.com/archives/libvir-list/2015-May/msg00400.html
it should be prohibited to set-time while other applications are running, but it does
seems to have no harm to make the codes more robust.
Signed-off-by: NWang Yufei <james.wangyufei@huawei.com>
Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>

Commit 7c2d65dd dropped setting default mode.

Update zfs tests accordingly.

Since commit bcd9a564 virDomainNumatuneGetMode returns the value
via a pointer rather than in the return value. The change triggered
problems with platforms where the compiler decides to use a data type of
size different than integer at the point where we typecast it.

Work around the issue by using an intermediate variable of the correct
type that gets casted back by the default typecasting rules.

If the <sysinfo type='smbios'...> ends up not formatting any sub-elements,
then rather than formatting as:

  <sysinfo type='smbios'>
  </sysinfo>

Just format it more cleanly as:

  <sysinfo type='smbios'/>
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

If the redirfilter has no usbdev sub-elements, then do not format anything
rather than formatting an empty pair of elements:

    <redirfilter>
    </redirfilter>
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Time to update to new gnulib before a release.

gcc 5.1 introduced a new -Wformat-signedness, and new gnulib now
turns it on by default.  However, it is still rather lame at the
moment, because it warns for enums, even though there is no way
to control the signeness of an enum which does not use any members
that are negative or larger than INT_MAX, and even though such an
enum would always print the same for both %d and %u:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66249

In file included from ../../src/util/virarch.c:26:0:
../../src/util/virarch.c: In function 'virArchFromHost':
../../src/util/virarch.c:180:15: error: format '%d' expects argument of type 'int', but argument 9 has type 'unsigned int' [-Werror=format=]
     VIR_DEBUG("Mapped %s to %d (%s)",

So this patch turns off the new warning as part of enabling all
other new gcc 5.1 warnings that gnulib now enables.

* .gnulib: Update to latest, in part for gcc 5.1 interaction.
* m4/virt-compile-warnings.m4: Ignore -Wformat-signedness, for now.
Signed-off-by: NEric Blake <eblake@redhat.com>

Rather than an algorithm based solely on libvirtd ctime to refresh the
capabilities add the element of the libvirt build version into the equation.
Since that version wouldn't be there prior to this code being run - don't
fail on reading the capabilities if not found. In this case, the cache
will always be rebuilt when a new libvirt version is installed.