Without the socket path explicitly specified, the remote driver tried to
connect to the "/system" instance socket even if "/session" was
specified in the uri. With this patch this configuration now produces an
error.

It is still possible to initiate a session connection with specifying
the path to the socket manually and also manually starting the session
daemon. This was also possible prior to this patch,

This is a minimal fix. We may decide to support remote session
connections using ssh but this will require changes to the remote driver
code so this fix shouldn't cause regressions in the case we decide to do
that.

When creating a timer/event handler reference counting is used. So it could
be possible (in theory) that libxlDomainObjPrivateFree is called with
reference counting >1. The problem is that libxlDomainObjPrivateFree leave
the object in an invalid state with ctx freed (but still having dandling
pointer). This can lead timer/event handler to core.

This patch implements a dispose method for libxlDomainObjPrivate, and moves
freeing the libxl ctx to the dispose method, ensuring the ctx is valid while
the object's reference count is > 0.
Signed-off-by: NFrediano Ziglio <frediano.ziglio@citrix.com>

Actually only those interface types are handled correctly so reject
others instead of ignoring settings (i.e. treating as bridge/ethernet
anyway).
Also allow <script/> in 'ethernet' (which should be the only
script-allowing type). Keep <script/> allowed in bridge to be compatible
with legacy 'xen' driver.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Convert input XML to migratable before using it in
qemuDomainSaveImageOpen.

XML in the save image is migratable, i.e. doesn't contain implicit
controllers. If these controllers were in a non-default order in the
input XML, the ABI check would fail. Removing and re-adding these
controllers fixes it.

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

brctl isn't used anywhere AFAICT

The legacy xen toolstack will set pygrub as the bootloader if not
specified.  For compatibility, do the same in the libxl driver
iff not using direct kernel boot.

Currently, the libxl driver reports a connection type of "xenlight".
To be compatible with the legacy Xen driver, it should return "Xen".

Note: I noticed this while testing the libxl driver on OpenStack.
After switching my Xen compute nodes to use the libxl stack, I
could no longer launch instances on those nodes since
hypervisor_type was reported as "xenlight" instead of "xen".

Use the host number as the host number when constructing the sysfs path
instead of the variable we are trying to fill.

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

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

Such machine can't be successuflly migrated unles the I/O error has
recovered and might lead to data corruption. Forbid this kind of
migration.

During a live migration the guest may receive a disk access I/O error.
In this state the guest is unable to continue running on a remote host
after migration as some state may be present in the kernel and not
migrated.

With this patch, the migration is canceled in such case so it can either
continue on the source if the I/O issues are recovered or has to be
destroyed anyways.

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

As of d7f9d827 we copy the listen
address from the qemu.conf config file in case none has been provided
via XML. But later, when migrating, we should not include such listen
address in the migratable XML as it is something autogenerated, not
requested by user. Moreover, the binding to the listen address will
likely fail, unless the address is '0.0.0.0' or its IPv6 equivalent.
This patch introduces a new boolean attribute to virDomainGraphicsListenDef
to distinguish autofilled listen addresses. However, we must keep the
attribute over libvirtd restarts, so it must be kept within status XML.

Avoid leaking virDomainDef if Prepare phase fails before it gets to
qemuMigrationPrepareAny.

This fixes a crash:
https://bugzilla.redhat.com/show_bug.cgi?id=969878

This has been disabled for years

The IN6_IS_ADDR_UNSPECIFIED macro expects pointer to sin6_addr element
instead of s6_addr element.

This patch fixes changes done in commit 29c1e913
that was pushed without implementing review feedback.

The flag introduced by the patch is changed to VIR_DOMAIN_VCPU_GUEST and
documentation makes the difference between regular hotplug and this new
functionality more explicit.

The virsh options that enable the use of the new flag are changed to
"--guest" and the documentation is fixed too.

Since this package isn't provided by any stock RH based distro. The
upstream RPMs are called VirtualBox anyways.

virProcessGetNamespaces() opens files in /proc/XXX/ns/ which will
later be passed to setns(). We have to make sure that the file
descriptors in the array are in the correct order. In particular
the 'user' namespace must be first otherwise setns() may fail
for other namespaces.

The order has been taken from util-linux's sys-utils/nsenter.c

Also we must ignore EINVAL in setns() which occurs if the
namespace associated with the fd, matches the calling process'
current namespace.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There's no sense in using virAsprintf() just to duplicate a string.
We should use VIR_STRDUP which is designed just for that.

Currently, there's a path to use the ncpuinfo variable uninitialized,
which leads to a compiler warning:

    qemu/qemu_driver.c: In function 'qemuDomainGetVcpusFlags':
    qemu/qemu_driver.c:4573:9: error: 'ncpuinfo' may be used
    uninitialized in this function [-Werror=maybe-uninitialized]
             for (i = 0; i < ncpuinfo; i++) {
             ^

This patch implements support for the "cpu-add" QMP command that plugs
CPUs into a live guest. The "cpu-add" command was introduced in QEMU
1.5. For the hotplug to work machine type "pc-i440fx-1.5" is required.

This patch adds support for agent-based cpu disabling and enabling to
qemuDomainSetVcpusFlags() API.

This patch implements the VIR_DOMAIN_VCPU_AGENT flag for the
qemuDomainGetVcpusFlags() libvirt API implementation.

This flag will allow to use qemu guest agent commands to disable
(offline) and enable (online) processors in a live guest that has the
guest agent running.

The qemu guest agent allows to online and offline CPUs from the
perspective of the guest. This patch adds helpers that call
'guest-get-vcpus' and 'guest-set-vcpus' guest agent functions and
convert the data for internal libvirt usage.

The 'online' parameter has only two possible values. Use a bool for it.

The "cmd" argument in cmdList is now used. Unmark it as unused.

A few things have changed in the VirtualBox API - some small
(capitalizations of things in function names like Ip to IP
and Dhcp to DHCP) and some much larger (FindMedium is superceded
by OpenMedium). The biggest change for the sake of this patch
is the signature of CreateMachine is quite a bit different. Using
the Oracle source as a guide, to spin up a VM with a given UUID,
it looks like a text flag has to be passed in a new argument to
CreateMachine. This flag is built in the VirtualBox 4.2 specific
ifdefs and is kind of ugly but works. Additionally, there is now
(unused) VM groups support in CreateMachine and the previous
'osTypeId' arg is currently set to nsnull as in the Oracle code.

The FindMedium to OpenMedium changes were more straightforward
and are pretty clear. The rest of the vbox template changes are
basically spelling/capitalization changes from the looks of things.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Since we have the new internal API to check for wildcard address,
we can use it instead of parsing and formatting.

This internal API checks, if passed address is a wildcard address.

iscsiadm now supports specifying hostnames in the portal argument [1]

Instead of resolving the hostname to a single IPv4 address, pass the
hostname to isciadm, allowing IPv6 targets to work.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=624437

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

Though both libvirt and QEMU's document say RTC_CHANGE returns
the offset from the host UTC, qemu actually returns the offset
from the specified date instead when specific date is provided
(-rtc base=$date).

It's not safe for qemu to fix it in code, it worked like that
for 3 years, changing it now may break other QEMU use cases.
What qemu tries to do is to fix the document:

http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg04782.html

And in libvirt side, instead of replying on the value from qemu,
this converts the offset returned from qemu to the offset from
host UTC, by:

  /*
   * a: the offset from qemu RTC_CHANGE event
   * b: The specified date (-rtc base=$date)
   * c: the host date when libvirt gets the RTC_CHANGE event
   * offset: What libvirt will report
   */

  offset = a + (b - c);

The specified date (-rtc base=$date) is recorded in clock's def as
an internal only member (may be useful to exposed outside?).

Internal only XML tag "basetime" is introduced to not lose the
guest's basetime after libvirt restarting/reloading:

<clock offset='variable' adjustment='304' basis='utc' basetime='1370423588'/>

Use virStringSplit. Change the 'error' label to 'cleanup' to prevent
memory leaks on error.

Found with 'git grep "= 1"'.