Similarly to devices the guest may allow unplug of the VCPU if libvirt
is down. To avoid problems, refresh the vcpu state on reconnect. Don't
mess with the vcpu state otherwise.

s/libvirt.c/libvirt-domain.c
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

All other modes of qemuDomainSetVcpusFlags have helpers so finish the
work by splitting the regular code into a new function.

This patch also touches up the coding (spacing) style.

The live code does ugly things. Contain it in a separate function.

Setting of the maximum vcpu count is slightly semantically different
thus split it into a self-contained func.

Mention whether it was the live or persistent definition which caused an
error reported and explicitly error out in case when attempting to set
maximum vcpu count for a live domain.

Call the vcpu thread info validation separately to decrease complexity
of returned values by qemuDomainRefreshVcpuInfo.

This function now returns 0 on success and -1 on error. Certain
failures of qemu to report data are still considered as success. Any
error reported now is fatal.

The function will eventually do more useful stuff than just detection of
thread ids.

If the VM is offline we can't retrieve the runtime statistical
information. Pinning could be retrieved but there are separate APIs for
that.

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

Add support for IOThread quota/bandwidth and period parameters for non
session mode. If in session mode, then error out.  Uses all the same
places where {vcpu|emulator|global}_{period|quota} are adjusted and
adds the iothread values.

Rather than open code build the drive alias command in multiple places,
use the helper to ensure consistency.

The qemuDomainSnapshotCreateSingleDiskActive open coded generating the
disk drive alias. Let's use the common function.

As commit id 'e2b86f58' notes, when mode=agent possibly setting the
fake reboot flag to true wouldn't be necessary; however, it doesn't
"force" the issue by just ensuring the fake reboot is false, so this
patch adds the explicit setting for the reboot path.

More investigation and details can be found in commit id '8be502fd'
as well as in the archives at:

  https://www.redhat.com/archives/libvir-list/2015-April/msg00715.html

Conditional setting of the fake reboot flag should only happen for
the acpi mode shutdown path; however, for the agent mode shutdown,
the fake reboot should be cleared. This patch will essentially revert
commit id '8be502fd', but adds an explicit setting of the flag to false
when using mode=agent while also only conditionally setting the reboot
flag if the guest went away. This also avoids an issue where a shutdown
with reboot semantics is done from agent mode which sets the reboot
flag followed by a shutdown from within the guest which would result
in a reboot due to the fake reboot flag being set. The change will
also properly handle the cases described in the following archive post:

  https://www.redhat.com/archives/libvir-list/2015-April/msg00715.html

When reset was called from a domain that crashed we didn't change the
crashed state into a paused one which could confuse users.

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

Ever since virDomainCreateWithFlags() was introduced by de3aadaa
[drivers: add virDomainCreateWithFlags if virDomainCreate exists], the
domain ID retrieved with virDomainGetID() was incorrect for several
drivers after virDomainCreateWithFlags() was called. The API consumer
had to look up the domain anew to retrieve the correct ID.

For the ESX driver, this was fixed in 6139b274 [esx: Update ID after
starting a domain]. For the openvz driver, it was fixed in fd81a097
[openvzDomainCreateWithFlags: set domain id to the correct value]. The
test driver, the OpenNebula driver (removed in the meantime) and the
vbox driver were already updating the domain ID correctly in
domainCreate().

Copy over the ID in qemuDomainCreateWithFlags() to fix this for the qemu
driver, too.

Fixes: de3aadaa ("drivers: add virDomainCreateWithFlags if virDomainCreate exists")
Reported-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Tested-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

To collect all balloon statistics for all guests it was necessary to make
several libvirt requests. Now it's possible to get all balloon statiscs via
single connectGetAllDomainStats call.
Signed-off-by: NDerbyshev Dmitry <dderbyshev@virtuozzo.com>

Is necessary to call it from other contexts, such as qemuDomainGetStatsBalloon.
Signed-off-by: NDerbyshev Dmitry <dderbyshev@virtuozzo.com>

Allow using 'ssh' protocol in backing chains and later for disks
themselves.

The cur_balloon also increases/decreases with dimm hotplug/unplug.
To be consistent, adjust the value for coldplug too. This was inconsistently
taken care when cur_ballon != memory to begin with. The patch fixes it
irrespective of that.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Commit 4a585a88 introduced searching QOM device path by alias, let's use it for
memballoon too.  This may speedup the search because in most cases we will find
the correct QOM device path directly by using alias without the need for the
recursion code.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Previously, qemuDomainDetachDeviceFlags was doing two things:
handling the job and detaching devices. Now the second part is
in a new function.

This will make splitting up qemuDomainDetachDeviceFlags into two
functions easier.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Previously, qemuDomainAttachDeviceFlags was doing two things:
handling the job and attaching devices. Now the second part is
in a new function.

This change is required to make it possible to test more complex
device attachment situations, like attaching a device to both
config and live at once.

qemuCaps is no longer used anywhere in these functions,
so it can be deleted.

We want to be able to pass a NULL instead of the connection
and use this function in tests. To achieve this, the virConnectPtr
is passed instead of virDomainPtr, and the driver is a new separate
parameter.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

So we spend some time and effort constructing perfect file name
for an automatic coredump of a domain, but then just leak it and
use the domain name anyway. This is probably due to a silly
mistake that slipped even through review.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

A device with an attribute 'model', with just one model
so far:

<devices>
  ...
  <iommu model='intel'/>
</devices>

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

Allow to store driver specific data on a per-vcpu basis.

Move of the virDomainDef*Vcpus* functions was necessary as
virDomainXMLOptionPtr was declared below this block and I didn't want to
split the function headers.

Most callers make sure that it's never called with an out of range vCPU.
Every other caller reports a different error explicitly. Drop the error
reporting and clean up some dead code paths.

Few arguments of the function are not necessary any more which leads to
some cleanups. The 'uri' argument had a stray ATTRIBUTE_UNUSED.

The impls are identical and I don't have a reasonable idea where to
extract it.

This also kills yet another use of virDomainLiveConfigHelperMethod.

Use a VIR_ prefix even when it's a local helper macro. It will be later
synced with the LXC implementation.

virttype is already included in domCaps, no need to pass it separately.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Some code paths already assume that it is allocated since it was always
allocated by virDomainPerfDefParseXML. Make it member of virDomainDef
directly so that we don't have to allocate it all the time.

This fixes crash when attempting to connect to an existing process via
virDomainQemuAttach since we would not allocate it in that code path.

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

in qemuConnectDomainXMLToNative. This function was only accounting for
about 1/10 of all the allocated items in the NetDef prior to memseting
it to all 0's. On top of that, it was going to great pains to learn
the name of the bridge device, but then never doing anything useful
with it (just putting it into data.ethernet.dev, which is *never* used
when building a qemu commandline). (I think this again all started off
as code with good intentions, but it was never completed, and instead
was just Frankensteinically cargo-culted into the odd mish mash we
have today).

The resulting code is much simpler, produces exactly the same output,
and doesn't leak memory.

This patch removes the expanded and duplicated code that all sprung
out of two well-intentioned-but-useless settings of
net->data.(bridge|ethernet).ipaddr.

qemu has never supported even a single IP address in the interface
config, much less a list of them. All of the instances of "clearing
out the IP addresses" that are now in this function originated with
commit d8dbd6 "Basic domain XML conversions for Xen/QEMU drivers" in
May 2009, but even then the single "ipaddr" in the struct for
type='ethernet' and type='bridge' wasn't used in the qemu driver (only
in xen and openvz). Since then anyone who added a new interface type
also tacked on another unnecessary clearing of ipaddr, and when it was
made into a list of IPs (so far supported only by the LXC driver) this
simple setting was turned into a loop (well, multiple loops) to clear
them all.

I'm tired of mistyping this all the time, so let's do it the same all
the time (similar to how we changed all "Pci" to "PCI" awhile back).

(NB: I've left alone some things in the esx and vbox drivers because
I'm unable to compile them and they weren't obviously *not* a part of
some API. I also didn't change a couple of variables named,
e.g. "somethingIptables", because they were derived from the name of
the "iptables" command)