In the pre-NUMA ages pinning a vCPU to all pCPUs was eaqual to deleting
the pinning info. Now it does not entirely work that way. Pinning a vCPU
to all pCPUs might be a desired operation. Additionally removal of the
pinning will result into using the default pinning information at the
next boot which might be different from all vcpus.

This patch removes the false assumption that we should remove the
pinning after pinning to all vCPUs and tweaks the documentation for
virsh.

A later patch will implement a new flag for the virDomainPinVcpuFlags
API that will allow to remove the pinning in a sane way.

While we probably won't see machines with more than 65536 cpus for a
while lets store the cpu count as an integer so that we can avoid quite
a lot of overflow checks in our code.

Since the returned structure uses "unsigned long" for memory sizes add a
few overflow checks to notify the user in case we are not able to
represent given values.

When qemu does not support the balloon event the current memory size
needs to be queried. Since there are two places that implement the same
logic, split it out into a function and reuse.

Refactor the function to return the bitmap instead of an integer and the
inner workings so that they make more sense.

This patch also fixes possible segfault on old systems that was
introduced by commit:

commit f1a43a8e
Author: Hu Tao <hutao@cn.fujitsu.com>
Date:   Fri Sep 14 15:46:59 2012 +0800

    use virBitmap to store cpu affinity info

Get rid of the unnecessary allocation and copying of the bitmap and
clean up some unnecesary temporary variables.

Reuse the function so that we can get rid of a lot of temporary
allocations.

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.

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

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.

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

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>

So far, we are not reporting if numatune was even defined. The
value of zero is blindly returned (which maps onto
VIR_DOMAIN_NUMATUNE_MEM_STRICT). Unfortunately, we are making
decisions based on this value. Instead, we should not only return
the correct value, but report to the caller if the value is valid
at all.

For better viewing of this patch use '-w'.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

For a domain configured using the host cdrom, we should taint the domain
due to problems encountered when the host and guest try to control the tray.

Since af2a1f05,
qemuDomainGetNumaParameters() returns invalid value for a running
guest.  The problem is that it is getting the information from cgroups,
but the parent cgroup is being left alone since the mentioned commit.
Since the running guest's XML is in sync with cgroups, there is no need
to look into cgroups (unless someone changes the configuration behind
libvirt's back).  Returning the info from the definition fixes a bug and
is also a cleanup.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1221047Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

For some reason a union (_virNodeDevCapData) that had only been
declared inside the toplevel struct virNodeDevCapsDef was being used
as an argument to functions all over the place. Since it was only a
union, the "type" attribute wasn't necessarily sent with it. While
this works, it just seems wrong.

This patch creates a toplevel typedef for virNodeDevCapData and
virNodeDevCapDataPtr, making it a struct that has the type attribute
as a member, along with an anonymous union of everything that used to
be in union _virNodeDevCapData. This way we only have to change the
following:

  s/union _virNodeDevCapData */virNodeDevCapDataPtr /

and

  s/caps->type/caps->data.type/

This will make me feel less guilty when adding functions that need a
pointer to one of these.

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

And move it to qemu_domain.[ch] because this API is QEMU-only.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Treat pinning an IOThread via API as if someone added an IOThread to
ensure the iothreadid doesn't cause the guest to disappear

Otherwise we might allow coldplugging a device
that uses an address that is already occupied, creating
an unstartable domain.

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

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

When cold-plugging an RNG device but something fails in
qemuDomainAssignAddresses, we will double free the RNG device.
Once a device is plugged into the domain, we should set the
device pointer to NULL to fix this issue.

...
5  0x00007fb7d180ac8a in virFree at util/viralloc.c:582
6  0x00007fb7d1895cdd in virDomainRNGDefFree at conf/domain_conf.c:19786
7  0x00007fb7d1895d99 in virDomainDeviceDefFree at conf/domain_conf.c:2022
8  0x00007fb7b92b8baf in qemuDomainAttachDeviceFlags at qemu/qemu_driver.c:8785
9  0x00007fb7d190c5d7 in virDomainAttachDeviceFlags at libvirt-domain.c:8488
10 0x00007fb7d23af9d2 in remoteDispatchDomainAttachDeviceFlags at remote_dispatch.h:2842
...
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Since libvirt doesn't call to update the new balloon size in qemu add
code that will handle tweaking of the size of the current balloon
statistic until qemu reports the new size using the event.

Use the new domain list collection helpers to avoid going through
virDomainPtrs.

This additionally implements filter capability when called through the
api that accepts domain list filters.

Extend it to a universal helper used for clearing lists of any objects.
Note that the argument type is specifically void * to allow implicit
typecasting.

Additionally add a helper that works on non-NULL terminated arrays once
we know the length.

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

So, imagine you've issued an API that involves guest agent. For
instance, you want to query guest's IP addresses. So the API acquires
QUERY_JOB, locks the guest agent and issues the agent command.
However, for some reason, guest agent replies to initial ping
correctly, but then crashes tragically while executing real command
(in this case guest-network-get-interfaces). Since initial ping went
well, libvirt thinks guest agent is accessible and awaits reply to the
real command. But it will never come. What will is a monitor event.
Our handler (processSerialChangedEvent) will try to acquire
MODIFY_JOB, which will fail obviously because the other thread that's
executing the API already holds a job. So the event handler exits
early, and the QUERY_JOB is never released nor ended.

The way how to solve this is to put flag somewhere in the monitor
internals. The flag is called @running and agent commands are issued
iff the flag is set. The flag itself is set when we connect to the
agent socket. And unset whenever we see DISCONNECT event from the
agent. Moreover, we must wake up all the threads waiting for the
agent. This is done by signalizing the condition they're waiting on.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Running shutdown with mode agent on a shutoff domain gives cryptic
error message:

    virsh # shutdown --mode agent gentoo
    error: Failed to shutdown domain gentoo
    error: Guest agent is not responding: QEMU guest agent is not connected

After this patch, the error is more clear:

    virsh # shutdown --mode agent gentoo
    error: Failed to shutdown domain gentoo
    error: Requested operation is not valid: domain is not running
Reported-by: NMartin Kletzander <mkletzan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Coverity points out that qemuMonitorGetAllBlockStatsInfo could return a
-1 and thus not fill in 'stats' (leaving it NULL). Then the call to
qemuMonitorBlockStatsUpdateCapacity will dereference it.

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

Jump to endjob instead of cleanup to fix this deadlock.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Now that we have macros for exclusive flags and flag requirements we can
use them to cleanup the code for setvcpus and error out for all wrong
flag combination.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Since the qemu capabilities are not initialized for offline VMs the
caller might get suboptimal error message:

$ virsh blockjob VM PATH --bandwidth 1
error: unsupported configuration: block jobs not supported with this QEMU binary

Move the checks after we make sure that the VM is alive.

The !modern code path needs to call qemuBlockJobEventProcess directly.
the modern code path will call it via qemuBlockJobSyncWait.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>