Add a "--pass-fds N,M,..." arg to the virsh start/create
methods. This allows pre-opened file descriptors from the
shell to be passed on into the guest
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Wire up the new virDomainCreate{XML}WithFiles methods in the
LXC driver, so that FDs get passed down to the init process.

The lxc_container code needs to do a little dance in order
to renumber the file descriptors it receives into linear
order, starting from STDERR_FILENO + 1.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In the following commit:

  commit 03d813bb
  Author: Marek Marczykowski <marmarek@invisiblethingslab.com>
  Date:   Thu May 23 02:01:30 2013 +0200

    remote: fix dom->id after virDomainCreateWithFlags

The virDomainCreateWithFlags remote client helper was made to
invoke REMOTE_PROC_DOMAIN_LOOKUP_BY_UUID to refresh the 'id'
of the domain, following the pattern used in the previous
virDomainCreate method impl.

The remote protocol for virDomainCreateWithFlags though did
actually fix the design flaw in virDomainCreate, by directly
returning the new domain info. For some reason, this data was
never used. So we can just use that data now instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Since they make use of file descriptor passing, the remote protocol
methods for virDomainCreate{XML}WithFiles must be written by hand.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

With container based virt, it is useful to be able to pass
pre-opened file descriptors to the container init process.
This allows for containers to be auto-activated from incoming
socket connections, passing the active socket into the container.

To do this, introduce a pair of new APIs, virDomainCreateXMLWithFiles
and virDomainCreateWithFiles, which accept an array of file
descriptors. For the LXC driver, UNIX file descriptor passing
will be used to send them to libvirtd, which will them pass
them down to libvirt_lxc, which will then pass them to the container
init process.

This will only be implemented for LXC right now, but the design
is generic enough it could work with other hypervisors, hence
I suggest adding this to libvirt.so, rather than libvirt-lxc.so
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The .ctags file specifies default options for ctags so that it does not
ignore libvirt.h.in and ignores uninteresting files. As a result, you
can just run "ctags" and navigating to a public API won't get you to a
useless entry in api.html.

Add support for creating disk-only (no memory) snapshots in esx, and
for quiescing the VM before taking the snapshot. The VMware API
supports these operations directly, so adding support to libvirt is
just a matter of setting the flags correctly when calling
VMware. VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY and
VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE are now valid flags for esx.
Signed-off-by: NEric Blake <eblake@redhat.com>

Although, having it depending on Xen >= 4.3 (by using the proper
libxl feature flag).

Xen currently implements a NUMA placement policy which is basically
the same as the 'interleaved' policy of `numactl', although it can
be applied on a subset of the available nodes. We therefore hardcode
"interleave" as 'numa_mode', and we use the newly introduced libxl
interface to figure out what nodes a domain spans ('numa_nodeset').

With this change, it is now possible to query the NUMA node
affinity of a running domain:

[raistlin@Zhaman ~]$ sudo virsh --connect xen:/// list
 Id    Name                           State
----------------------------------------------------
 23    F18_x64                        running

[raistlin@Zhaman ~]$ sudo virsh --connect xen:/// numatune 23
numa_mode      : interleave
numa_nodeset   : 1
Signed-off-by: NDario Faggioli <dario.faggioli@citrix.com>

domainGetNumaParameters has a string typed parameter, hence it
is necessary for the libxl driver to support this.

This change implements the connectSupportsFeature hook for the
libxl driver, advertising that VIR_DRV_FEATURE_TYPED_PARAM_STRING
is supported.
Signed-off-by: NDario Faggioli <dario.faggioli@citrix.com>
Cc: Eric Blake <eblake@redhat.com>

Xen 4.3 changes sysctl version to 10 and domctl version to 9. Update
the hypervisor driver to work with those.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>

Commit 75c12564 states that virGetGroupList must not be called
between fork and exec, then commit ee777e99 promptly violated
that for lxc.

Patch originally posted by Eric Blake <eblake@redhat.com>.

Reuse the buffer for getline and track buffer allocation
separately from the string length to prevent unlikely
out-of-bounds memory access.

This fixes the following leak that happened when zero bytes were read:

==404== 120 bytes in 1 blocks are definitely lost in loss record 1,344 of 1,671
==404==    at 0x4C2C71B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==404==    by 0x906F862: getdelim (iogetdelim.c:68)
==404==    by 0x52A48FB: virCgroupPartitionNeedsEscaping (vircgroup.c:1136)
==404==    by 0x52A0FB4: virCgroupPartitionEscape (vircgroup.c:1171)
==404==    by 0x52A0EA4: virCgroupNewDomainPartition (vircgroup.c:1450)

In all qemu APIs we tend to prefer qemuDomObjFromDomain over
virDomainObjListFindByUUID. But somehow the
qemuDomainGetSchedulerType left unattended.

While generating seclabels, we check the seclabel stack if required
driver is in the stack. If not, an error is returned. However, it is
possible for a seclabel to not have any model set (happens with LXC
domains that have just <seclabel type='none'>). If that's the case,
we should just skip the iteration instead of calling STREQ(NULL, ...)
and SIGSEGV-ing subsequently.

Currently, if the primary security driver is 'none', we skip
initializing caps->host.secModels. This means, later, when LXC domain
XML is parsed and <seclabel type='none'/> is found (see
virSecurityLabelDefsParseXML), the model name is not copied to the
seclabel. This leads to subsequent crash in virSecurityManagerGenLabel
where we call STREQ() over the model (note, that we are expecting model
to be !NULL).

If we don't autostart a network it's not being created.

Debian Bug http://bugs.debian.org/715200

Introduced in commit 24b08219; compilation on RHEL 6.4 complained:
qemu/qemu_hotplug.c: In function 'qemuDomainAttachChrDevice':
qemu/qemu_hotplug.c:1257: error: declaration of 'remove' shadows a global declaration [-Wshadow]
/usr/include/stdio.h:177: error: shadowed declaration is here [-Wshadow]

* src/qemu/qemu_hotplug.c (qemuDomainAttachChrDevice): Avoid the
name 'remove'.
Signed-off-by: NEric Blake <eblake@redhat.com>

The owner of this host devices should be the root user of container.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

These host devices are created for container,
the owner should be the root user of container.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

Otherwise the container will fail to start if we
enable user namespace, since there is no rights to
do mknod in uninit user namespace.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

The owner of this disk device should be the root user of container.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

lxc driver will use this function to change the owner
of hot added devices.

Move virLXCControllerChown to lxc_container.c and Rename
it to lxcContainerChown.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

These disk devices are created for container,
the owner should be the root user of container.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

Since mknod in container is forbidden, we should setup disks
on host side.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

A part of the returned monitor response was freed twice and caused
crashes of the daemon when using guest agent cpu count retrieval.

 # virsh vcpucount dom --guest

Introduced in v1.0.6-48-gc6afcb05

Not all RBD (Ceph) storage pools have cephx authentication turned on,
so "secret" might not be initialized.

It could also be that the secret couldn't be located.

Only call virSecretFree() if "secret" is initialized earlier.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

Use the virDomainSetMemoryStatsPeriodFlags() to pass a period defined by
usage of a new --period option in order to set the collection period for the
balloon driver. This may enable or disable the collection based on the value.

Add the --current, --live, & --config options to dommemstat.

Implement the new API that will handle setting the balloon driver statistics
collection period in order to enable or disable the collection dynamically.

Wire up the remote protocol

Add new API in order to set the balloon memory driver statistics collection
period in order to allow dynamic period adjustment for the virsh dommemstats to
display balloon stats data

This patch will add the qemuMonitorJSONGetMemoryStats() to execute a
"guest-stats" on the balloonpath using "get-qom" replacing the former
mechanism which looked through the "query-ballon" returned data for
the fields.  The "query-balloon" code only returns 'actual' memory.
Rather than duplicating the existing code, have the JSON API use the
GetBalloonInfo API.

A check in the qemuMonitorGetMemoryStats() will be made to ensure the
balloon driver path has been set.  Since the underlying JSON code can
return data not associated with the balloon driver, we don't fail on
a failure to get the balloonpath.  Of course since we've made the check,
we can then set the ballooninit flag.  Getting the path here is primarily
due to the process reconnect path which doesn't attempt to set the
collection period.

At vm startup and attach attempt to set the balloon driver statistics
collection period based on the value found in the domain xml file. This
is not done at reconnect since it's possible that a collection period
was set on the live guest and making the set period call would reset to
whatever value is stored in the config file.

Setting the stats collection period has a side effect of searching through
the qom-list output for the virtio balloon driver and making sure that it
has the right properties in order to allow setting of a collection period
and eventually fetching of statistics.

The walk through the qom-list is expensive and thus the balloonpath will
be saved in the monitor private structure as well as a flag indicating
that the initialization has already been attempted (in the event that a
path is not found, no sense to keep checking).

This processing model conforms to the qom object model model which
requires setting object properties after device startup. That is, it's
not possible to pass the period along via the startup code as it won't
be recognized.

Add a period in seconds to allow/enable statistics gathering from the
Balloon driver for 'virsh dommemstat <domain>'.

If users haven't configured guest agent then qemuAgentCommand() will
dereference a NULL 'mon' pointer, which causes crash of libvirtd when
using agent based cpu (un)plug.

With the patch, when the qemu-ga service isn't running in the guest,
a expected error "error: Guest agent is not responding: Guest agent
not available for now" will be raised, and the error "error: argument
unsupported: QEMU guest agent is not configured" is raised when the
guest hasn't configured guest agent.

GDB backtrace:

 (gdb) bt
 #0  virNetServerFatalSignal (sig=11, siginfo=<value optimized out>, context=<value optimized out>) at rpc/virnetserver.c:326
 #1  <signal handler called>
 #2  qemuAgentCommand (mon=0x0, cmd=0x7f39300017b0, reply=0x7f394b090910, seconds=-2) at qemu/qemu_agent.c:975
 #3  0x00007f39429507f6 in qemuAgentGetVCPUs (mon=0x0, info=0x7f394b0909b8) at qemu/qemu_agent.c:1475
 #4  0x00007f39429d9857 in qemuDomainGetVcpusFlags (dom=<value optimized out>, flags=9) at qemu/qemu_driver.c:4849
 #5  0x00007f3957dffd8d in virDomainGetVcpusFlags (domain=0x7f39300009c0, flags=8) at libvirt.c:9843

How to reproduce?

 # To start a guest without guest agent configuration
 # then run the following cmdline

 # virsh vcpucount foobar --guest
 error: End of file while reading data: Input/output error
 error: One or more references were leaked after disconnect from the hypervisor
 error: Failed to reconnect to the hypervisor

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=984821Signed-off-by: NAlex Jia <ajia@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

When using logical pools, we had to trust the target->path provided.
This parameter, however, can be completely ommited and we can use
'/dev/<source.name>' safely and populate it to target.path.

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