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.

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

Original commit id 'cbde3589' indicates that the cache file would be
discarded if either the QEMU binary or libvirtd 'ctime' changes; however,
the code only discarded if the QEMU binary time didn't match or if the
new libvirtd ctime was later than what created the cache file.

Since many factors come into play with 'ctime' adjustments (including
perhaps turning back the hands of time), change the logic to also force
a refresh if the ctime of libvirt is different than what's in the cache.

The github project was renamed from libvirtproject to libvirt

Recent changes to the -M/--machine processing code in qemuParseCommandLine
caused Coverity to determine there was a possible resource leak with how
the 'list' is managed. Rather than try to add virStringFreeList calls
everywhere - just promote list to the top of the variables and free it
within the error processing code. Also required a couple of other tweaks
in order to avoid double free's.

Commit id '73eda710' added virDomainKeyWrapDefParseXML which uses
virXPathNodeSet, but does not handle a -1 return thus causing a possible
loop condition exit problem later when the return value is used.

Change the logic to return the value from virXPathNodeSet if <= 0

Only set directory permissions at pool build time, if:

- User explicitly requested a mode via the XML
- The directory needs to be created
- We need to do the crazy NFS root-squash workaround

This allows qemu:///session to call build on an existing directory
like /tmp.

The XML parser sets a default <mode> if none is explicitly passed in.
This is then used at pool/vol creation time, and unconditionally reported
in the XML.

The problem with this approach is that it's impossible for other code
to determine if the user explicitly requested a storage mode. There
are some cases where we want to make this distinction, but we currently
can't.

Handle <mode> parsing like we handle <owner>/<group>: if no value is
passed in, set it to -1, and adjust the internal consumers to handle
it.

- Don't redocument the permissions fields for backingstore, just point to
  the volume docs.
- Clarify that owner/group are inherited from the parent directory at
  volume create/pool build time.
- Clarify that <permissions> fields report runtime values too