We do not need to pass a zero-filled buffer as an argument,
the function can allocate its own.

Return -1:
* on all failures of fdatasync. Instead of propagating -errno
  all the way up to the virStorageVolWipe API, which is documented
  to return 0 or -1.
* after a partial wipe. If safewrite failed, we would re-use the
  non-negative return value of lseek (which should be 0 in this case,
  because that's the only offset we seek to).

MemLock is already used in other modules and, while still an
abbreviation, is not ambiguous.

When the function changes the memory lock limit for the first time,
it will retrieve the current value and store it inside the
virDomainObj for the domain.

When the function is called again, if memory locking is no longer
needed, it will be able to restore the memory locking limit to its
original value.

We increase the limit before plugging in a PCI hostdev or a memory
module because some memory might need to be locked due to eg. VFIO.

Of course we should do the opposite after unplugging a device: this
was already the case for memory modules, but not for PCI hostdevs.

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

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

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.

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().

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.

In commit 686eb7a2, the break was not considered part of the
condition, hence breaking after first node when searching.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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.

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: NIan Campbell <ian.campbell@citrix.com>

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: NJoao Martins <joao.m.martins@oracle.com>

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: NJoao Martins <joao.m.martins@oracle.com>

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.

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.

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

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

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

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

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.

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.

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.

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: NPavel Hrdina <phrdina@redhat.com>

The name 'dev' is more appropriate for virPCIDevicePtr.

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: NMichal Privoznik <mprivozn@redhat.com>

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: NHenning Schild <henning.schild@siemens.com>

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: NHenning Schild <henning.schild@siemens.com>

virCgroupNewMachine used to add the pidleader to the newly created
machine cgroup. Do not do this implicit anymore.
Signed-off-by: NHenning Schild <henning.schild@siemens.com>

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: NMichal Privoznik <mprivozn@redhat.com>

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=1266982Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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: NMichal Privoznik <mprivozn@redhat.com>

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: NEric Blake <eblake@redhat.com>

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

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 64588113 where
I've added a test that uses too large numbers.

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: NMichal Privoznik <mprivozn@redhat.com>

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: NMichal Privoznik <mprivozn@redhat.com>

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: NMichal Privoznik <mprivozn@redhat.com>

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: NMichal Privoznik <mprivozn@redhat.com>