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.

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>

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>

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.

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.

Cleanup code in prlsdkLoadDomain doesn't take into account the fact
if private domain structure along with freeing function is assigned
or not. In case it is, we shouldn't call it manually because
virDomainObjListRemove calls it and frees pdom.
Also, allocated def structure should be freed only if it's not
assigned to domain. Otherwise it will be called twice: one time by
virDomainObjListRemove and the second by prlsdkLoadDomain itself.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

It is better to get all necessary parameters and check them on newly
created configuration before actually creating a domain with them or
applying them to an existing domain.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

To silence Coverity just add a 'p &&' in front of the check in
networkFindUnusedBridgeName after the strchr() call.  Even though
we know it's not possible to have strchr return NULL since the only
way into the function is if there is a '%' in def->bridge or it's NULL.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Even though it's been pointed out they are false positives:

http://www.redhat.com/archives/libvir-list/2015-May/msg00301.html

and

http://www.redhat.com/archives/libvir-list/2015-May/msg00302.html

these still show up as Coverity issues. In order to silence Coverity
add an 'sa_assert' prior to check failure.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Coverity points out it's possible for one of the virCommand{Output|Error}*
API's to have not allocated 'output' and/or 'error' in which case the
strstr comparison will cause a NULL deref
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Build with gcc 4.8 fails with:

bhyve/bhyve_monitor.c: In function 'bhyveMonitorIO':
bhyve/bhyve_monitor.c:51:18: error: missing initializer for field 'tv_sec' of 'const struct timespec' [-Werror=missing-field-initializers]
     const struct timespec zerowait = {};

Explicitly initialize zerowait to fix the build.

Fixes build problems on x86_64-cygwin host for aarch64 target:
  CC       lxc/libvirt_driver_lxc_impl_la-lxc_monitor_protocol.lo
In file included from lxc/lxc_monitor_protocol.c:7:0:
lxc/lxc_monitor_protocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory

  CC       rpc/libvirt_setuid_rpc_client_la-virnetmessage.lo
In file included from rpc/virnetmessage.h:24:0,
                 from rpc/virnetmessage.c:26:
rpc/virnetprotocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory

  CC       lxc/libvirt_lxc-lxc_monitor_protocol.o
In file included from lxc/lxc_monitor_protocol.c:7:0:
lxc/lxc_monitor_protocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>

If the firewalld backend wasn't available and libvirt decides to try
setting up a "direct" backend, it checks for the presence of iptables,
ip6tables, and ebtables. If they are not found, a message like this is logged:

  error : virFirewallValidateBackend:193 : direct firewall backend
          requested, but /usr/sbin/ip6tables is not available:
          No such file or directory

But then at a later time if an attempt is made to use the virFirewall
API, failure will be indicated with:

  error : virFirewallApply:936 : out of memory

This patch changes virFirewallApply to first check if a firewall
backend hadn't been successfully setup, and logs a slightly more
informative message in that case:

  error : virFirewallApply:940 : internal error:
          Failed to initialize a valid firewall backend

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

If an SRIOV PF is offline, the kernel won't complain if you set the
mac address and vlan tag for a VF via this PF, and it will even let
you assign the VF to a guest using PCI device assignment or macvtap
passthrough. But in this case (the PF isn't online), the device won't
be usable in the guest.

Silently setting the PF online would solve the connectivity problem,
but as pointed out by Dan Berrange, when an interface is set online
with no associated config, the kernel will by default turn on IPv6
autoconf, which could create unexpected security problems for the
host. For this reason, this patch instead logs an error and fails the
operation.

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

Originally filed against RHEL6, but present in every version of
libvirt until today.

-1 is just an internal placeholder and is meaningless to output in the XML.

commit ffc40b63 changed uniond _virNodeDevCapData into a typedef
named virNodeDevCapData with a struct that contains the union as well
as a type enum. This change necessitated changing every reference to
"caps->type" into "caps->data.type", but the author of that patch
failed to test a build "WITH_HAL". This patch fixes the one place in
the hal backend that needed changing.

Due to a kernel commit (b4b8f770e), cpuinfo format has changed on
ARMs. Firstly, 'Processor: ...' may not be reported, it's
replaced by 'model name: ...'. Secondly, the "Processor" string
may occur in CPU name, e.g. 'ARMv7 Processor rev 5 (v7l)'.
Therefore, we must firstly look for 'model name' and then for
'Processor' if not found.
Moreover, lines in the cpuinfo file are shuffled, so we better
not manipulate the pointer to start of internal buffer as we may
lost some info.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Not every chardev is plugged onto virtio-serial bus. However, the
code introduced in 89e991a2 assumes that. Incorrectly.
With previous patches we have three options where a chardev can
be plugged: virtio-serial, USB and PCI. This commit fixes the
detach part. However, since we are not auto allocating USB
addresses yet, I'm just marking the place where appropriate code
should go.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Not every chardev is plugged onto virtio-serial bus. However, the
code introduced in 89e991a2 assumes that. Incorrectly.
With previous patches we have three options where a chardev can
be plugged: virtio-serial, USB and PCI. This commit fixes the
attach part.  However, since we are not auto allocating USB
addresses yet, I'm just marking the place where appropriate code
should go.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Implementation is pretty straight-forward. Of course, not all qemus
out there supports the device, so new capability is introduced and
checked prior each use of the device.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Like usb-serial, the pci-serial device allows a serial device to be
attached to PCI bus. An example XML looks like this:

  <serial type='dev'>
    <source path='/dev/ttyS2'/>
    <target type='pci-serial' port='0'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
  </serial>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Old compilers whine:
src/util/virutil.c: In function 'virMemoryMaxValue':
src/util/virutil.c:2612: error: declaration of 'ulong' shadows a global declaration [-Wshadow]
/usr/include/sys/types.h:151: error: shadowed declaration is here [-Wshadow]

s/ulong/capped/ to work around the problem

Base-64 encode the password and pass it to the guest agent
via the 'guest-set-user-password' command.

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

For setting passwords of users inside the domain.

With the VIR_DOMAIN_PASSWORD_ENCRYPTED flag set, the password
is assumed to be already encrypted by the method required
by the guest OS.

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

Using joinable threads does not help anything, but it can lead to memory
leaks.

When a worker thread exits, it decreases nWorkers or nPrioWorkers and
once both nWorkers and nPrioWorkers are zero (i.e., the last worker is
gone), quit_cond is signaled. When freeing the pool we first tell all
threads to die and then we are waiting for both nWorkers and
nPrioWorkers to become zero. At this point we already know all threads
are gone. So the only reason for calling virThreadJoin of all workers is
to free the memory allocated for joinable threads. If we avoid
allocating this memory, we don't need to take care of freeing it.

Moreover, any memory associated with a worker thread which died before
we asked it to die (e.g., because virCondWait failed in the thread)
would be lost anyway since virThreadPoolFree calls virThreadJoin only
for threads which were running at the time virThreadPoolFree was called.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Most virDomainDiskIndexByName callers do not care about the index; what
they really want is a disk def pointer.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>