qemu: Use qemuDomainAdjustMaxMemLock()

Replace all uses of the qemuDomainRequiresMlock/virProcessSetMaxMemLock
combination with the equivalent qemuDomainAdjustMaxMemLock() call.

qemu: Add qemuDomainAdjustMaxMemLock()

This function detects whether a domain needs RLIMIT_MEMLOCK
to be set, and if so, uses an appropriate value.

process: Add virProcessGetMaxMemLock()

This function can be used to retrieve the current locked memory
limit for a process, so that the setting can be later restored.

Add a configure check for getrlimit(), which we now use.

process: Allow virProcessPrLimit() to get current limit

The prlimit() function allows both getting and setting limits for
a process; expose the same functionality in our wrapper.

Add the const modifier for new_limit, in accordance with the
prototype for prlimit().

build: disable vbox on cygwin

Cygwin cannot build the vbox driver yet:

  CC       vbox/libvirt_driver_vbox_impl_la-vbox_glue.lo
In file included from vbox/vbox_glue.c:27:0:
vblox/vbox_XPCOMCGlue.c:63:3: error: #error "Port me"
 # error "Port me"
   ^
In file included from vbox/vbox_XPCOMCGlue.c:45:0,
                 from vbox/vbox_glue.c:27:
vbox/vbox_XPCOMCGlue.c: In function 'tryLoadOne':
vbox/vbox_XPCOMCGlue.c:98:46: error: 'DYNLIB_NAME' undeclared (first use in this function)
         if (virAsprintf(&name, "%s/%s", dir, DYNLIB_NAME) < 0)
                                      ^
./util/virstring.h:245:31: note: in definition of macro 'virAsprintf'
                         strp, __VA_ARGS__)
       ^

Rather than trying to figure out how to get dynamic loading of
vbox to work under cygwin (since I don't even have a working vbox
setup to test whether it works), I'm going to be lazy and just
default to not even trying vbox on cygwin.

qemu: Search all nodes for shared memory access

In commit 686eb7a24f7d, the break was not considered part of the
condition, hence breaking after first node when searching.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

pci: Use virPCIDeviceAddress in virPCIDevice

Instead of replicating the information (domain, bus, slot, function)
inside the virPCIDevice structure, use the already-existing
virPCIDeviceAddress structure.

For users of the module, this means that the object returned by
virPCIDeviceGetAddress() can no longer be NULL and must no longer
be freed by the caller.

libxl: Use libxentoollog in preference to libxenctrl if available.

Upstream Xen is in the process of splitting the (stable API) xtl_*
interfaces out from the (unstable API) libxenctrl library and into a
new (stable API) libxentoollog.

In order to be compatible with Xen both before and after this
transition check for xtl_createlogger_stdiostream in a libxentoollog
library and use it if present. If it is not present assume it is in
libxenctrl.

Compile tested on Xen 4.6 and a development tree with the split in
place.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

libxl: implement virDomainGetJobStats

Introduces support for domainGetJobStats which has the same
info as domainGetJobInfo but in a slightly different format.
Another difference is that virDomainGetJobStats can also
retrieve info on the most recently completed job. Though so
far this is only used in the source node to know if the
migration has been completed. But because we don't support
completed jobs we will deliver an error.

Signed-off-by: Joao Martins <joao.m.martins@oracle.com>

libxl: implement virDomainGetJobInfo

Introduce support for domainGetJobInfo to get info about the
ongoing job. If the job is active it will update the
timeElapsed which is computed with the "started" field added to
struct libxlDomainJobObj.  For now we support just the very basic
info and all jobs have VIR_DOMAIN_JOB_UNBOUNDED (i.e. no completion
time estimation) plus timeElapsed computed.

Openstack Kilo uses the Job API to monitor live-migration
progress which is currently nonexistent in libxl driver and
therefore leads to a crash in the nova compute node. Right
now, migration doesn't use jobs in the source node and will
return VIR_DOMAIN_JOB_NONE. Though nova handles this case and
will migrate it properly instead of crashing.

Signed-off-by: Joao Martins <joao.m.martins@oracle.com>

storage: Add helper to compare logical pool def against pvs output

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

Add a new helper virStorageBackendLogicalMatchPoolSource to compare the
pool's source name against the output from a 'pvs' command to list all
volume group physical volume data on the host.  In addition, compare the
pool's source device list against the particular volume group's device
list to ensure the source device(s) listed for the pool match what the
was listed for the volume group.

Then for pool startup or check API's we need to call this new API in
order to ensure that the pool we're about to start or declare active
during checkPool has a valid definition vs. the running host.

storage: Create helper for virStorageBackendLogicalFindPoolSources

Rework virStorageBackendLogicalFindPoolSources a bit to create a
helper virStorageBackendLogicalGetPoolSources that will make the
pvs call in order to generate a list of associated pv_name and vg_name's.

A future patch will make use of this for start/check processing to
ensure the storage pool source definition matches expectations.

storage: Check FS pool source during virStorageBackendFileSystemIsMounted

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

When determining whether a FS pool is mounted, rather than assuming that
the FS pool is mounted just because the target.path is in the mount list,
let's make sure that the FS pool source matches what is mounted

storage: Refactor virStorageBackendFileSystemGetPoolSource

Refactor code to use standard return functioning with respect to setting
a ret value and going to cleanup.

storage: Create helper to generate FS pool source value

Refactor the code that builds the pool source string during the FS
storage pool mount to be a separate helper.

A future patch will use the helper in order to validate the mounted
FS matches the pool's expectation during poolCheck processing

qemu: add bootindex option to hostdev network interface commandline

when appropriate, of course. If the config for a domain specifies boot
order with <boot dev='blah'/> elements, e.g.:

     <os>
       ...
       <boot dev='hd'/>
       <boot dev='network'/>
     </os>

Then the first disk device in the config will have ",bootindex=1"
appended to its qemu commandline -device options, and the first (and
*only* the first) network interface device will get ",bootindex=2".

However, if the first network interface device is a "hostdev" device
(an SRIOV Virtual Function (VF) being assigned to the domain with
vfio), then the bootindex option will *not* be appended. This happens
because the bootindex=n option corresponding to the order of "<boot
dev='network'/>" is added to the -device for the first network device
when network device commandline args are constructed, but if it's a
hostdev network device, its commandline arg is instead constructed in
the loop for hostdevs.

This patch fixes that omission by noticing (in bootHostdevNet) if the
first network device was a hostdev, and if so passing on the proper
bootindex to the commandline generator for hostdev devices - the
result is that ",bootindex=2" will be properly appended to the first
"network" device in the config even if it is really a hostdev
(including if it is assigned from a libvirt network pool). (note that
this is only the case if there is no <bootmenu enabled='yes'/> element
in the config ("-boot menu-on" in qemu) , since the two are mutually
exclusive - when the bootmenu is enabled, the individual per-device
bootindex options can't be used by qemu, and we revert to using "-boot
order=xyz" instead).

If a greater level of control over boot order is desired (e.g., more
than one network device should be tried, or a network device other
than the first one encountered in the config), then <boot
dev='network'/> in the <os> element should not be used; instead, the
individual device elements in the config should be given a "<boot
order='n'/>

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

security_stack: remove extra Security from function names

Many of the functions follow the pattern:
virSecurity.*Security.*Label

Remove the second 'Security' from the names, it should be
obvious that the virSecurity* functions deal with security
labels even without it.

security_selinux: remove extra Security from function names

Many of the functions follow the pattern:
virSecurity.*Security.*Label

Remove the second 'Security' from the names, it should be obvious
that the virSecurity* functions deal with security labels even
without it.

security_dac: remove extra Security from function names

Many of the functions follow the pattern:
virSecurity.*Security.*Label

Remove the second 'Security' from the names, it should be obvious
that the virSecurity* functions deal with security labels even
without it.

qemuMonitorJSONEjectMedia: don't stringify the replay at all

Commit 256496e1 introduced a detection if "is locked" in error replay
from qemu monitor. Commit c4073657 fixed a memory leak, but it was
pointed out by Peter, that this could be done cleaner without
stringifing the replay.

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

pci: Use 'addr' instead of 'dev' for virPCIDeviceAddressPtr

The name 'dev' is more appropriate for virPCIDevicePtr.

qemuMonitorJSONEjectMedia: Don't leak stringified reply

The return value of virJSONValueToString() should be freed when
no longer needed. This is not the case after 256496e1.

==26902== 138 bytes in 2 blocks are definitely lost in loss record 1,051 of 1,239
==26902==    at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26902==    by 0xAA5F599: strdup (in /lib64/libc-2.21.so)
==26902==    by 0x552BAD9: virStrdup (virstring.c:726)
==26902==    by 0x54F60A7: virJSONValueToString (virjson.c:1790)
==26902==    by 0x1DF6EBB9: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2225)
==26902==    by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985)
==26902==    by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199)
==26902==    by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985)
==26902==    by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030)
==26902==    by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677)
==26902==    by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559)
==26902==    by 0x134210: remoteDispatchDomainUpdateDeviceFlags (remote_dispatch.h:10966)

==26902== 106 bytes in 1 blocks are definitely lost in loss record 1,033 of 1,239
==26902==    at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26902==    by 0xAA5F599: strdup (in /lib64/libc-2.21.so)
==26902==    by 0x552BAD9: virStrdup (virstring.c:726)
==26902==    by 0x54F60A7: virJSONValueToString (virjson.c:1790)
==26902==    by 0x1DF6EC0C: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2227)
==26902==    by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985)
==26902==    by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199)
==26902==    by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985)
==26902==    by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030)
==26902==    by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677)
==26902==    by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559)
==26902==    by 0x134210: remoteDispatchDomainUpdateDeviceFlags (remote_dispatch.h:10966)

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

qemu cgroups: move new threads to new cgroup after cpuset is set up

Moving tasks to cgroups implied sched_setaffinity. Changing the cpus in
a set implies the same for all tasks in the group.
The old code put the the thread into the cpuset inherited from the
machine cgroup, which allowed it to run outside of vcpupin for a short
while.

Signed-off-by: Henning Schild <henning.schild@siemens.com>

qemu: do not put a task into machine cgroup

The machine cgroup is a superset, a parent to the emulator and vcpuX
cgroups. The parent cgroup should never have any tasks directly in it.
In fact the parent cpuset might contain way more cpus than the sum of
emulatorpin and vcpupins. So putting tasks in the superset will allow
them to run outside of <cputune>.

Signed-off-by: Henning Schild <henning.schild@siemens.com>

util: cgroups do not implicitly add task to new machine cgroup

virCgroupNewMachine used to add the pidleader to the newly created
machine cgroup. Do not do this implicit anymore.

Signed-off-by: Henning Schild <henning.schild@siemens.com>

virNetDevMacVLanTapSetup: Drop @multiqueue argument

Firstly, there's a bug (or typo) in the only place where we call
this function: @multiqueue is set whenever @tapfdSize is greater
than zero, while in fact the condition should have been 'greater
than one'.
Then, secondly, since the condition depends on just one
variable, that we are even passing down to the function, we can
move the condition into the function and drop useless argument.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

qemu: Warn when using vhost-user without shared memory

When user configures vhost-user interface and forgets to also configure
any shared memory, the search for the root cause of non-operational
interface might take unpleasantly long time.  Let's enhance user
experience by emitting a warning in the logs.

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

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

virNetDevMacVLanTapSetup: Work around older systems

Some older systems, e.g. RHEL-6 do not have IFF_MULTI_QUEUE flag
which we use to enable multiqueue feature. Therefore one gets the
following compile error there:

  CC     util/libvirt_util_la-virnetdevmacvlan.lo
util/virnetdevmacvlan.c: In function 'virNetDevMacVLanTapSetup':
util/virnetdevmacvlan.c:338: error: 'IFF_MULTI_QUEUE' undeclared (first use in this function)
util/virnetdevmacvlan.c:338: error: (Each undeclared identifier is reported only once
util/virnetdevmacvlan.c:338: error: for each function it appears in.)
make[3]: *** [util/libvirt_util_la-virnetdevmacvlan.lo] Error 1

So, whenever user wants us to enable the feature on such systems,
we will just throw a runtime error instead.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

CVE-2015-5313: storage: don't allow '/' in filesystem volume names

The libvirt file system storage driver determines what file to
act on by concatenating the pool location with the volume name.
If a user is able to pick names like "../../../etc/passwd", then
they can escape the bounds of the pool.  For that matter,
virStoragePoolListVolumes() doesn't descend into subdirectories,
so a user really shouldn't use a name with a slash.

Normally, only privileged users can coerce libvirt into creating
or opening existing files using the virStorageVol APIs; and such
users already have full privilege to create any domain XML (so it
is not an escalation of privilege).  But in the case of
fine-grained ACLs, it is feasible that a user can be granted
storage_vol:create but not domain:write, and it violates
assumptions if such a user can abuse libvirt to access files
outside of the storage pool.

Therefore, prevent all use of volume names that contain "/",
whether or not such a name is actually attempting to escape the
pool.

This changes things from:

$ virsh vol-create-as default ../../../../../../etc/haha --capacity 128
Vol ../../../../../../etc/haha created
$ rm /etc/haha

to:

$ virsh vol-create-as default ../../../../../../etc/haha --capacity 128
error: Failed to create vol ../../../../../../etc/haha
error: Requested operation is not valid: volume name '../../../../../../etc/haha' cannot contain '/'

Signed-off-by: Eric Blake <eblake@redhat.com>

util: Fixup virnetdevmacvlan.h ATTRIBUTE_NONNULL's

Commit id '56e2171c6' removed a variable from the argument list, but
neglected to update the ATTRIBUTE_NONNULL values, so when commit id
'08da97bfb' added a couple of arguments, the values were off.

test: qemuxml2argv: Mock virMemoryMaxValue to remove 32/64 bit difference

Always return LLONG_MAX even on 32 bit systems. The limitation
originates from our use of "unsigned long" in several APIs. The internal
data type is unsigned long long. Make the test suite deterministic by
removing the architecture difference.

Flaw was introduced in 645881139b3d2c86acf9d644c3a1471520bc9e57 where
I've added a test that uses too large numbers.

qemu: Enable multiqueue for macvtaps

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

Ta-da! Now that we know how to open a macvtap device multiple
times, we can finally enable the multiqueue feature. Everything
else is already prepared (e.g. command line generation) from the
previous iteration where the feature was implemented for
TUN/TAP devices.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

virNetDevMacVLanCreateWithVPortProfile: Rework to support multiple FDs

For the multiqueue on macvtaps we are going to need to open
the device multiple times. Currently, this is not supported.
Rework the function, so that upper layers can be reworked too.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

virNetDevMacVLanTapSetup: Allow enabling of IFF_MULTI_QUEUE

Like we are doing for TUN/TAP devices, we should do the same for
macvtaps. Although, it's not as critical as in that case, we
should do it for the consistency.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

virNetDevMacVLanTapSetup: Rework to support multiple FDs

For the multiqueue on macvtaps we are going to need to open
the device multiple times. Currently, this is not supported.
Rework the function, so that upper layers can be reworked too.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

virNetDevMacVLanTapOpen: Rework to support multiple FDs

For the multiqueue on macvtaps we are going to need to open
the device multiple times. Currently, this is not supported.
Rework the function, so that upper layers can be reworked too.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

virNetDevMacVLanTapOpen: Slightly rework

There are few outdated things. Firstly, we don't need to undergo
the torture of fopen, fscanf and fclose just to get the interface
index when we have nice wrapper over that: virNetDevGetIndex.
Secondly, we don't need to have statically allocated buffer for
the path we are opening.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

virNetDevMacVLanCreateWithVPortProfile: Turn vnet_hdr into flag

So yet again one of integer arguments that we use as a boolean.
Since the argument count of the function is unbearably long
enough, lets turn those booleans into flags.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

log: include hostname in initial log message

On the very first log message we send to any output, we include
the libvirt version number and package string. In some bug reports
we have been given libvirtd.log files that came from a different
host than the corresponding /var/log/libvirt/qemu log files. So
extend the initial log message to include the hostname too.

eg on first log message we would now see:

 $ libvirtd
 2015-12-04 17:35:36.610+0000: 20917: info : libvirt version: 1.3.0
 2015-12-04 17:35:36.610+0000: 20917: info : hostname: dhcp-1-180.lcy.redhat.com
 2015-12-04 17:35:36.610+0000: 20917: error : qemuMonitorIO:687 : internal error: End of file from monitor

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

storage: Ignore block devices that fail format detection

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

Prior to commit id '98322052' failure to saferead the block device would
cause an error to be logged and the device to be skipped while attempting
to discover/create a stable target path for a new LUN (NPIV).

This was because virStorageBackendSCSIFindLUs ignored errors from
processLU and virStorageBackendSCSINewLun.

Ignoring the failure allowed a multipath device with an "active" and
"ghost" to be present on the host with the "ghost" block device being
ignored. This patch will return a -2 to the caller indicating the desire
to ignore the block device since it cannot be used directly rather than
fail the pool startup.

storage: Add debug message

I found this useful while processing a volume that wouldn't end up
showing up in the resulting list of block volumes. In this case, the
partition type wasn't found in the disk_types table.

storage: Handle readflags errors

Similar to the openflags VIR_STORAGE_VOL_OPEN_NOERROR processing, if some
read processing operation fails, check the readflags for the corresponding
error flag being set. If so, rather then causing an error - use VIR_WARN
to flag the error, but return -2 which some callers can use to perform
specific actions. Use a new VIR_STORAGE_VOL_READ_NOERROR flag in a new
VolReadErrorMode enum.

storage: Set ret = -1 on failures in virStorageBackendUpdateVolTargetInfo

While processing the volume for lseek, virFileReadHeaderFD, and
virStorageFileGetMetadataFromBuf - failure would cause an error,
but ret would not be set. That would result in an error message being
sent, but successful status being returned.

storage: Add comments for backend APIs

Just so it's clearer what to expect upon input and what types of return
values could be generated.  These were loosely copied from existing
virStorageBackendUpdateVolTargetInfoFD.

storage: Add readflags for backend error processing

Similar to the openflags which allow VIR_STORAGE_VOL_OPEN_NOERROR to be
passed to avoid open errors, add a 'readflags' variable so that in the
future read failures could also be ignored.

tests: scsihost: Use fakerootdir instead of fakesysfsdir

This updates the test program to make it consistent with recent changes
to the mock libraries, and also opens up the possibility of mocking more
than just /sys in the future.

tests: Use more specific names for variables

Instead of fakesysfsdir, which is very generic, use fakesysfspcidir and
fakesysfscgroupdir. This makes it explicit what part of the fake sysfs
filesystem they're referring to, and also leaves open the possibility of
handling files in two unrelated parts of the fake sysfs filesystem.

No functional changes.

tests: Rename LIBVIRT_FAKE_SYSFS_DIR to LIBVIRT_FAKE_ROOT_DIR

The old name is no longer accurate, since now we're using its value as
the root of the fake filesystem.

No functional changes.

tests: cgroupmock: Use the temporary directory as fake root

We might need to mock files living outside SYSFS_PREFIX later on,
so it's better to treat the temporary directory we are passed via
the environment as the root of the fake filesystem and create
SYSFS_PREFIX inside it.

The environment variable name will be changed to reflect the new use
we're making of it in a later commit.

tests: pcimock: Use the temporary directory as fake root

We might need to mock files living outside PCI_SYSFS_PREFIX later on,
so it's better to treat the temporary directory we are passed via
the environment as the root of the fake filesystem and create
PCI_SYSFS_PREFIX inside it.

The environment variable name will be changed to reflect the new use
we're making of it in a later commit.

tests: pcimock: Remove check for fakesysfsdir

init_env() will return right away if fakesysfsdir is already
initialized, so this check is redundant.

tests: scsihost: Don't set LIBVIRT_FAKE_SYSFS_DIR

The test program is not preloading any of the mock libraries that read
that environment variable, so setting it is pointless.

qemu: cgroup: Don't use priv->ncpupids to iterate domain vCPUs

Use the proper data structures for the iteration since ncpupids will be
made private later.

qemu: driver: Refactor qemuDomainHelperGetVcpus

Change some of the control structures and switch to using the new vcpu
structure.

qemu: Add helper to retrieve vCPU pid

Instead of directly accessing the array add a helper to do this.

qemu: Replace checking for vcpu<->pid mapping availability with a helper

Add qemuDomainHasVCpuPids to do the checking and replace in place checks
with it.

We no longer need checking whether the thread contains fake data
(vcpupids[0] == vm->pid) as in b07f3d821dfb11a118ee75ea275fd6ab737d9500
and 65686e5a81d654d834d338fceeaf0229b2ca4f0d this was removed.

qemu: Drop checking vcpu threads in emulator bandwidth getter/setter

The vCPU threads make sense in the counterparts that set the vCPU
bandwidth/quota, not in the emulator one. The emulator tunables are set
all the time anyways.

Drop the extra check and remove the now unneeded vm argument.

qemu: cgroup: Remove now unreachable check

Since commit 0c04906fa the check for priv->cgroup doesn't make sense as
the calls to virCgroupHasController return the same information. Remove
it and move it's comment partially to the new check.

The already spurious check was also later copied to the iothreads code.

conf: Add helper to get pointer to a certain vCPU definition

Once more stuff will be moved into the vCPU data structure it will be
necessary to get a specific one in some ocasions. Add a helper that will
simplify this task.

conf: ABI: Split up and improve vcpu info ABI checking

Extract the checking code into a separate function and prepare the
infrastructure for checking the new structure type.

conf: turn def->vcpus into a structure

To allow collecting all relevant data at one place let's make def->vcpus
a structure and then we can start moving stuff into it.

qemu: refactor qemuDomainHotunplugVcpus

Refactor the code flow so that 'exit_monitor:' can be removed.

This patch moves the auditing functions into places where it's certain
that hotunplug was or was not successful and reports errors from
qemuMonitorGetCPUInfo properly.

qemu: Refactor qemuDomainHotplugVcpus

Refactor the code flow so that 'exit_monitor:' can be removed.

This patch also moves the auditing and setting of the new vCPU count
right to the place where the hotplug happens, since it's possible that
the hotplug succeeds and adds a cpu while other stuff fails.

Lastly, failures of qemuMonitorGetCPUInfo are now reported rather than
ignored. The function retuns 0 if it "successfully" detected 0 threads.

qemu: cpu hotplug: Move loops to qemuDomainSetVcpusFlags

qemuDomainHotplugVcpus/qemuDomainHotunplugVcpus are complex enough in
regards of adding one CPU. Additionally it will be desired to reuse
those functions later with specific vCPU hotplug.

Move the loops for adding vCPUs into qemuDomainSetVcpusFlags so that the
helpers can be made simpler and more straightforward.

qemu: monitor: Remove weird return values from qemuMonitorSetCPU

Let the function report errors internally and change it to return
standard return codes.

qemu: cpu hotplug: Fix error handling logic

The cpu hotplug helper functions used negative error handling in a part
of them, although some code that was added later didn't properly set the
error codes in some cases. This would cause improper error messages in
cases where we couldn't modify the numa cpu mask and a few other cases.

Fix the logic by converting it to the regularly used pattern.

qemu: Split up vCPU hotplug and hotunplug

There's only very little common code among the two operations. Split the
functions so that the internals are easier to understand and refactor
later.

qemu: qemuDomainSetVcpusAgent: re-check agent before calling it the again

With a very unfortunate timing, the agent might vanish before we do the
second call while the locks were down. Re-check that the agent is
available before attempting it again.

qemu: Extract vCPU onlining/offlining via agent into a separate function

Separate the code so that qemuDomainSetVcpusFlags contains only code
relevant to hardware hotplug/unplug.

qemu: domain: Add helper to access vm->privateData->agent

As in commit 88dc7e0c2fb, the helper can be used in cases where the
function actually does not access anyting in the private data besides
the agent.

conf: Turn def->maxvcpus into size_t

Later on this will also be used to track size of the vcpu data array.
Use size_t so that we can utilize the memory allocation helpers.

conf: Replace read accesses to def->vcpus with accessor

conf: Move vcpu count check into helper

conf: Replace writes to def->vcpus with accessor

conf: Replace read access to def->maxvcpus with accessor

Finalize the refactor by adding the 'virDomainDefGetVCpusMax' getter and
reusing it accross libvirt.

conf: Add helper to check whether domain has offline vCPUs

The new helper will simplify checking whether the domain config contains
inactive vCPUs.

conf: Extract update of vcpu count if maxvcpus is decreased

The code can be unified into the new accessor rather than being
scattered accross the drivers.

conf: Use local copy of maxvcpus in virDomainVcpuParse

Use the local variable rather than getting it all the time from the
struct. This will simplify further refactors.

conf: Replace writes to def->maxvcpus with accessor

To support further refactors replace all write access to def->maxvcpus
with a accessor function.

libxl: copy persistent domain definition while starting a guest

We should make a copy of current definition to preserve a persistent
definition, because we later update the definition with live changes.
The live definition is discarded on domain shutdown and replaced by the
copy we make before starting the domain.

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

xen: fix timer bug found by updated test

Only 'tsc' timer allows set mode and track is valid only for 'rtc' and
'platform' timers.

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

xen: use virDomainDefPostParse for parsing XM/XL/SEXPR cofings

This change ensures to call driver specific post-parse code to modify
domain definition after parsing hypervisor config the same way we do
after parsing XML.

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

lxc: use virDomainDefPostParse for parsing LXC config string

This change ensures to call driver specific post-parse code to modify
domain definition after parsing hypervisor config the same way we do
after parsing XML.

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

vmware/vmx: use virDomainDefPostParse after parsing vmx config

This change ensures to call driver specific post-parse code to modify
domain definition after parsing hypervisor config the same way we do
after parsing XML.

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

virsh: rename vshCommandOptString to vshCommandOptStringQuiet

This function does not set an error. Make it obvious in its name
to discourage its usage without reporting an error in the caller.

security_selinux: fix indentation

security_dac: check if virSecurityDACGetIds returns negative

Use the customary check '< 0' instead of checking for non-zero.

No functional change.

Post-release version bump to 1.3.1

Release of libvirt-1.3.0

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: regenerated

Revert "libxl: implement virDomainInterfaceStats"

This reverts commit d2e5538b16e325d9095f3ccb0dac88bbd9fc98f0.

A migration regression was introduced by this commit. When migrating
a domain, its active XML is sent to the destination libvirtd, where
it is parsed as inactive XML. d2e5538b copied the libxl generated
interface name into the active config, which was being passed to the
migration destination and being parsed into inactive config. Attempting
to start the config could result in failure if an interface with the
same generated name already exists.

The qemu driver behaves similarly, but the parser contains a hack to
skip interface names starting with 'vnet' when parsing inactive XML.
We could extend the hack to skip names starting with 'vif' too, but a
better fix would be to expose these hypervisor-specific interface name
prefixes in capabilities. See the following discussion thread for more
details

https://www.redhat.com/archives/libvir-list/2015-December/msg00262.html

For the pending 1.3.0 release, it is best to revert d2e5538b. It can
be added again post release, after moving the prefix to capabilities.

rpm: explicitly enable & start virtlogd on install

When installing the libvirt-daemon RPM, we have a %post rule to
enable the libvirtd.service, virtlockd.socket and virtlogd.socket
files. This is only done, however, when the RPM is first installed,
not when upgrading RPMs. So virtlogd will not get activated on
upgrading, which is a problem as libvirt qemu driver will expect
it to be available by default.

This adds a trigger that is run when uninstalling libvirt-daemon
older than 1.3.0 that will enable & start virtlogd.socket if
libvirtd is enabled and/or started. Using the trigger rather
than %post ensures that it only runs once, allowing admins to
disable it explicitly thereafter without future upgrades
re-enabling it.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

libvirtd: enable virtlockd/virtlogd socket activation on install

When someone does 'systemctl enable libvirtd.service' we should
also enable virtlockd.socket/virtlogd.socket, so that they can
be auto-activated if libvirtd tries to access the sockets.

Without this, people have to manually enable the units themselves
via 'systemctl enable virtdlogd.socket'.

This also ensures that if distros uses  'systemctl preset' for
enabling 'libvirtd.service', then the virtdlogd.socket gets
enabled without having to wait for the distro to update their
presets file.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

logging: validate flags passed from client in virtlogd

The virtlogd RPC messages all have a flags parameter. For
sake of future error reporting we should be verifying
these are all 0 for now.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

logging: change log protocol to be more reusable

The current virtlogd RPC protocol provides the ability to
handle log files associated with QEMU stdout/err. The log
protocol messages take the virt driver, domain name and
use that to form a log file path. This is quite restrictive
as it prevents us re-using the same RPC protocol messages
for logging to char device backends where the filename
can be arbitrarily user specified. It is also bad because
it means we have 2 separate locations which have to decide
on logfile name.

This change alters the RPC protocol so that we pass the
desired log file path along when opening the log file
initially. Now the virt driver is exclusively in charge
of deciding the log filename

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

logging: preserve driver, dom name & uuid against log file

The virt driver, dom name and uuid associated with a log
file are important pieces of metadata to keep around for
sake of future enhancements to virtlogd. Currently we
discard them after opening the log file, but we should
preserve them, even across restarts.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

qemu: fix memory leak in opening log file

The qemuDomainLogContextNew method leaks the "logfile" path
on the non-virtlogd code path.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

libvirt: Update virDomainSetMemory description

virDomainSetMemory is documented to change only runtime configuration of
running domain. However, that's not true of all hypervisors supported.
Seems as though when commit id '0f2e50be5' added the current flag, the
function description should have been updated similar to when commit id
'c1795c52' updated the virDomainSetMaxMemory description. Especially since
commit id '80427f1d' updated the virsh 'setmem' description to indicate
"behavior is different depending on hypervisor."

This patch will update the description to match current functionality.

Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

qemu: Automatic SCSI controller creation in SCSI disk hotplug broken

When a SCSI disk is hotplugged to a domain that does not have the required
SCSI controller already defined and loaded the following internal error occurs

error: Failed to attach device from scsi_disk.xml
error: internal error: Could not find scsi controller with index 0 required for device

Commit 0260506c added in method qemuBuildDriveDevStr a lookup of the controller
alias. The internal error occurs because in method qemuDomainAttachSCSIDisk
the automatic creation of the potentially missing SCSI controller occurs after
calling qemuBuildDriveDevStr.

This patch reverses the calling sequence.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Stefan Zimmermann <stzi@linux.vnet.ibm.com>

qemu: include hostname in QEMU log files

Often when debugging bug reports one is given a copy of the file
from /var/log/libvirt/qemu/$NAME.log along with other supporting
files. In a number of cases I've been given sets of files which
were from different machines. Including the hostname in the QEMU
log file will help identify when the bug reporter is providing
bad information.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

rotatingfile: mark log files as close-on-exec

The log file descriptor associated with the virRotatingFile
struct should be marked close-on-exec, as even when virtlogd
re-exec's itself it expect to open the log file fresh. It
does not need to preserve the logfile handles, only the network
client FDs.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>