The "checkPool" is a bit different for pool with "fc_host"
type source adapter, since the vHBA it's based on might be
not created yet (it's created by "startPool", which is
involked after "checkPool" in storageDriverAutostart). So it
should not fail, otherwise the "autostart" of the pool will
fail either.

The problem is easy to reproduce:
    * Enable "autostart" for the pool
    * Restart libvirtd service
    * Check the pool's state

94f82053 added a space to the string but didn't change the buffer size.
Signed-off-by: NBing Bu Cao <mars@linux.vnet.ibm.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

For pool which relies on remote resources, such as a "iscsi" type
pool, since how long it takes to export the corresponding devices
to host's sysfs is really depended, it could depend on the network
connection, it also could depend on the host's udev procedures. So
it's likely that the volumes are not able to be detected during pool
starting process, polling the sysfs doesn't work, since we don't
know how much time is best for the polling, and even worse, the
volumes could still be not detected or partly not detected even after
the polling.  So we end up with a documentation to prompt the fact,
in virsh manual.

And as a small improvement, let's explicitly say no LUNs found in
the debug log in that case.

There are 2 issues here: First we shouldn't add "1" to the return
value of numa_max_node(), since the semanteme of the error message
was changed, it's not saying about the number of total NUMA nodes
anymore.  Second, the value of "bit" is the position of the first
bit which exceeds either numa_max_node() or NUMA_NUM_NODES, it can
be any number in the range, so saying "bigger than $bit" is quite
confused now. For example, assuming there is a NUMA machine which
has 10 NUMA nodes, and one specifies the "nodeset" as "0,5,88",
the error message will be like:

Nodeset is out of range, host cannot support NUMA node bigger than 88

It sounds like all NUMA node number less than 88 is fine, but
actually the maximum NUMA node number the machine supports is 9.

This patch fixes the issues by removing the addition with "1" and
simplifies the error message as "NUMA node $bit is out of range".
Also simplifies the comparision in the while loop by getting the
smaller one of numa_max_node() and NUMA_NUM_NODES up front.

I noticed that we allow virDomainGetVcpusFlags even for read-only
connections, but that with a flag, it can require guest agent
interaction.  It is feasible that a malicious guest could
intentionally abuse the replies it sends over the guest agent
connection to possibly trigger a bug in libvirt's JSON parser,
or withhold an answer so as to prevent the use of the agent
in a later command such as a shutdown request.  Although we
don't know of any such exploits now (and therefore don't mind
posting this patch publicly without trying to get a CVE assigned),
it is better to err on the side of caution and explicitly require
full access to any domain where the API requires guest interaction
to operate correctly.

I audited all commands that are marked as conditionally using a
guest agent.  Note that at least virDomainFSTrim is documented
as needing a guest agent, but that such use is unconditional
depending on the hypervisor (so the existing domain:fs_trim ACL
should be sufficient there, rather than also requirng domain:write).
But when designing future APIs, such as the plans for obtaining
a domain's IP addresses, we should copy the approach of this patch
in making interaction with the guest be specified via a flag, and
use that flag to also require stricter access checks.

* src/libvirt.c (virDomainGetVcpusFlags): Forbid guest interaction
on read-only connection.
(virDomainShutdownFlags, virDomainReboot): Improve docs on agent
interaction.
* src/remote/remote_protocol.x
(REMOTE_PROC_DOMAIN_SNAPSHOT_CREATE_XML)
(REMOTE_PROC_DOMAIN_SET_VCPUS_FLAGS)
(REMOTE_PROC_DOMAIN_GET_VCPUS_FLAGS, REMOTE_PROC_DOMAIN_REBOOT)
(REMOTE_PROC_DOMAIN_SHUTDOWN_FLAGS): Require domain:write for any
conditional use of a guest agent.
* src/xen/xen_driver.c: Fix clients.
* src/libxl/libxl_driver.c: Likewise.
* src/uml/uml_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/lxc/lxc_driver.c: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

Bugs have been found in the VirtualBox API C bindings. These bugs have
been fixed in versions 4.2.20 and 4.3.4. However, the changes in the
C bindings are incompatible with the vbox_CAPI_v4_2.h and vbox_CAPI_v4_3.h
files which are bundled in libvirt source code.
This is why the following patch adds vbox_CAPI_v4_2_20.h and
vbox_CAPI_v4_3_4.h.

The actual underlying problem here is that until now,
libvirt assumed that VirtualBox API can only change between minor
versions (4.2 -> 4.3), but we have a case here where it changed
(or got fixed) between patch versions (4.2.18 -> 4.2.20).

This patch makes the VBOX_API_VERSION represent the full API
version number (i.e 4002 => 4002000) so there are specific version
numbers for Vbox 4.2.20 (4002020) and 4.3.4 (4003004)

Libvirtd would crash if a domain contained an empty cdrom drive of
type='volume' as the disk def->srcpool member would be dereferenced. Fix
it by checking if the source pool is present before dereferencing it.

Also alter tests to catch this issue in the future.

Reported by: Kevin Shanahan
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1056328

- Use $XDG_RUNTIME_DIR for re-exec state file when running unprivileged.

- argv[0] may not contain a full path to the binary, however it should
  contain something that can be looked up in the PATH. Use execvp() to
  do path lookup on re-exec.

- As per list discussion [1], ignore --daemon on re-exec.

[1] https://www.redhat.com/archives/libvir-list/2013-December/msg00514.htmlSigned-off-by: NMichael Chapman <mike@very.puzzling.org>

To retrieve node cpu statistics on Linux system, the
linuxNodeGetCPUstats function simply uses STRPREFIX() to match the cpuid
with the one read from /proc/stat. However, as the file is read line by
line it may happen, that some CPUs share the same prefix. So if user
requested stats for the first CPU, which is offline, then there's no
cpu1 in the stats file so the one that we match is cpu10. Which is
obviously wrong. Fortunately, the IDs are terminated by a space, so we
can utilize that.
Signed-off-by: NBing Bu Cao <mars@linux.vnet.ibm.com>

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

SCSI passthrough disks (<disk .. device="lun">) can't be used as backing
for snapshots. Currently with upstream qemu the vm crashes on such
attempt.

This patch adds a early check to catch an attempt to do such a snapshot
and rejects it right away. qemu will fix the issue but this will let us
control the error message.

I noticed this problem when adding systemd support to netcf, because I
setup the configure.ac to automatically prefer using systemd over
initscripts when possible - although I had copied the
install-data-local target from the example of libvirt's
"libvirt-guests" service more or less verbatim, "make distcheck" would
fail because it was trying to install the service file directly into
/lib/systemd/system rather than into
/home/user/some/unimportant/name/lib/systemd/system.

This is caused by the install/uninstall rules for the systemd unit
files relying on $(DESTDIR) pointing the installed files to the right
place, but in reality $(DESTDIR) is empty during this part of make
distcheck - it instead sets $(prefix) with the toplevel directory used
for its test build/install/uninstall cycle.

(This problem hasn't been seen when running "make distcheck" in
libvirt because libvirt will never build/install systemd support
unless explicitly told to do so on the configure commandline, and
"make distcheck" doesn't put the "--with-initscript=..." option on the
configure commandline.)

I verified that the same problem does exist in libvirt by modifying
libvirt's configure.ac to set:

  init_systemd=yes
  with_init_script=systemd+redhat

This forces a build/install of the systemd unit files during
distcheck, which yields an error like this:

/usr/bin/install -c -m 644 virtlockd.service \
  /lib/systemd/system/
libtool: install: warning: relinking `libvirt-qemu.la'
/usr/bin/install: cannot remove '/lib/systemd/system/virtlockd.service': Permission denied
make[4]: *** [install-systemd] Error 1

After adding $(prefix) to all the definitions of SYSTEMD_UNIT_DIR,
make distcheck now completes successfully with the modified
configure.ac, and the above lines change to something like this:

/usr/bin/install -c -m 644 virtlockd.service \
  /home/laine/devel/libvirt/libvirt-1.2.1/_inst/lib/systemd/system/

We shouldn't access the domain definition while we are in the monitor
section as the domain is unlocked. Additionally after we exit from the
monitor we need to check if the VM is still alive. Not doing so resulted
in a crash if qemu exits while attempting to do an external VM snapshot.

spice-server offers an API to disable file transfer messages
on the agent channel between the client and the guest.
This is supported in qemu through the disable-agent-file-xfer option.

This patch exposes this option to libvirt.
Adds a new element 'filetransfer', with one property,
'enable', which accepts a boolean.
Default is enabled, for backward compatibility.

Depends on the capability exported in the first patch of the series.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>

spice-server offers an API to disable file transfer messages
on the agent channel between the client and the guest.
This is supported in qemu through the disable-agent-file-xfer option.

This patch detects if QEMU supports this option, and add
a capability if does.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>

Commit 399394ab removed some coverity
comments which skipped the dead code, so add them back.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

With this patch,user can set throttle blkio cgroup for
lxc domain through virsh tool.
Signed-off-by: NGuan Qiang <hzguanqiang@corp.netease.com>
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

This is useful in certain circumstances, for example when
libvirtd is being executed by FreeBSD rc script, it cannot find
dmidecode installed from FreeBSD ports because it doesn't have
/usr/local (default prefix for ports) in PATH.

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

If none (KVM, VFIO) of the supported PCI passthrough methods is known to
work on a host, it's better to fail right away with a nice error message
rather than letting attachment fail with a more cryptic message such as

    Failed to bind PCI device '0000:07:05.0' to vfio-pci: No such device
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Since commit v0.9.0-47-g4e8969eb (released in 0.9.1) some failures during
device detach were reported to callers of virPCIDeviceBindToStub as
success. For example, even though a device seemed to be detached

    virsh # nodedev-detach pci_0000_07_05_0 --driver vfio
    Device pci_0000_07_05_0 detached

one could find similar message in libvirt logs:

    Failed to bind PCI device '0000:07:05.0' to vfio-pci: No such device

This patch fixes these paths and also avoids overwriting real errors
with errors encountered during a cleanup phase.

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

When a PCI device is not bound to any driver, reattach should just
trigger driver probe rather than failing with

    Invalid device 0000:00:19.0 driver file
    /sys/bus/pci/devices/0000:00:19.0/driver is not a symlink

While virPCIDeviceGetDriverPathAndName was documented to return success
and NULL driver and path when a device is not attached to any driver but
didn't do so. Thus callers could not distinguish unbound devices from
failures.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

With this patch, user can setup throttle blkio cgroup
through virsh for qemu domain.
Signed-off-by: NGuan Qiang <hzguanqiang@corp.netease.com>
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

This patch introduces virCgroupSetBlkioDeviceReadIops,
virCgroupSetBlkioDeviceWriteIops,
virCgroupSetBlkioDeviceReadBps and
virCgroupSetBlkioDeviceWriteBps,

we can use these interfaces to set up throttle
blkio cgroup for domain.

This patch also adds the new throttle blkio cgroup
elements to the test xml.
Signed-off-by: NGuan Qiang <hzguanqiang@corp.netease.com>
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

This patch introduces new xml elements under <blkiotune>,
we use these new elements to setup the throttle blkio
cgroup for domain. The new blkiotune node looks like this:

<blkiotune>
  <device>
    <path>/path/to/block</path>
    <weight>1000</weight>
    <read_iops_sec>10000</read_iops_sec>
    <write_iops_sec>10000</write_iops_sec>
    <read_bytes_sec>1000000</read_bytes_sec>
    <write_bytes_sec>1000000</write_bytes_sec>
  </device>
</blkiotune>
Signed-off-by: NGuan Qiang <hzguanqiang@corp.netease.com>
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

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

When starting up a domain, the SELinux labeling is done depending on
current configuration. If the labeling fails we check for possible
causes, as not all labeling failures are fatal. For example, if the
labeled file is on NFS which lacks SELinux support, the file can still
be readable to qemu process. These cases are distinguished by the errno
code: NFS without SELinux support returns EOPNOTSUPP. However, we were
missing one scenario. In case there's a read-only disk on a read-only
NFS (and possibly any FS) and the labeling is just optional (not
explicitly requested in the XML) there's no need to make the labeling
error fatal. In other words, read-only file on read-only NFS can fail to
be labeled, but be readable at the same time.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Finish the cleanup of libvirt.c; all uses of virLib*Error have
now been converted to more canonical conventions.

* src/libvirt.c: Use virReportError in remaining errors.
(virLibConnError, virLibDomainError): Delete unused macros.
* cfg.mk (msg_gen_function): Drop unused names.
Signed-off-by: NEric Blake <eblake@redhat.com>

We had a lot of repetition of errors that would occur if we
ever register too many drivers; this is unlikely to occur
unless we start adding a lot of new hypervisor modules, but
if it does occur, it's better to have uniform handling of the
situation, so that a one-line change is all that would be
needed if we decide that an internal error is not the best.

* src/libvirt.c (virDriverCheckTabMaxReturn): New define.
(virRegister*Driver): Use it for less code duplication.
Signed-off-by: NEric Blake <eblake@redhat.com>

The choice of error message and category was not consistent
in the migration code; furthermore, the use of virLibConnError
is no longer necessary now that we have a generic virReportError.

* src/qemu/qemu_migration.c (virDomainMigrate*): Prefer
virReportError over virLibConnError.
Signed-off-by: NEric Blake <eblake@redhat.com>

While auditing the error reporting, I noticed that migration
had some issues.  Some of the static helper functions tried
to call virDispatchError(), even though their caller will also
report the error.  Also, if a migration is cancelled early
because a uri was not set, we did not guarantee that the finish
stage would not overwrite the first error message.

* src/qemu/qemu_migration.c (doPeer2PeerMigrate2)
(doPeer2PeerMigrate3): Preserve first error when cancelling.
* src/libvirt.c (virDomainMigrateVersion3Full): Likewise.
(virDomainMigrateVersion1, virDomainMigrateVersion2)
(virDomainMigrateDirect): Avoid redundant error dispatch.
(virDomainMigrateFinish2, virDomainMigrateFinish3)
(virDomainMigrateFinish3Params): Don't report error on cleanup
path.
Signed-off-by: NEric Blake <eblake@redhat.com>

The public virConnectRef and virConnectClose API are just thin
wrappers around virObjectRef/virObjectRef, with added object
validation and an error reset.  Within our backend drivers, use
of the object validation is just an inefficiency since we always
pass valid objects.  More important to think about is what
happens with the error reset; our uses of virConnectRef happened
to be safe (since we hadn't encountered any earlier errors), but
in several cases the use of virConnectClose could lose a real
error.

Ideally, we should also avoid calling virConnectOpen() from
within backend drivers - but that is a known situation that
needs much more design work.

* src/qemu/qemu_process.c (qemuProcessReconnectHelper)
(qemuProcessReconnect): Avoid nested public API call.
* src/qemu/qemu_driver.c (qemuAutostartDomains)
(qemuStateInitialize, qemuStateStop): Likewise.
* src/qemu/qemu_migration.c (doPeer2PeerMigrate): Likewise.
* src/storage/storage_driver.c (storageDriverAutostart):
Likewise.
* src/uml/uml_driver.c (umlAutostartConfigs): Likewise.
* src/lxc/lxc_process.c (virLXCProcessAutostartAll): Likewise.
(virLXCProcessReboot): Likewise, and avoid leaking conn on error.
Signed-off-by: NEric Blake <eblake@redhat.com>

Several APIs clear out a user input buffer before attempting to
populate it; but in a few cases we missed this memset if we
detect a reason for an early exit.  Note that these APIs
check for non-NULL arguments, and exit early with an error
message when NULL is passed in; which means that we must be
careful to avoid a NULL deref in order to get to that error
message.  Also, we were inconsistent on the use of
sizeof(virType) vs. sizeof(expression); the latter is more
robust if we ever change the type of the expression (although
such action is unlikely since these types are part of our
public API).

* src/libvirt.c (virDomainGetInfo, virDomainGetBlockInfo)
(virStoragePoolGetInfo, virStorageVolGetInfo)
(virDomainGetJobInfo, virDomainGetBlockJobInfo): Move memset
before any returns.
Signed-off-by: NEric Blake <eblake@redhat.com>

There is a number of reported issues when we fail starting a domain.
Turns out that, in some scenarios like high load, 3 second timeout is
not enough for qemu to start up to the phase where the socket is
created.  Since there is no downside of waiting longer, raise the
timeout right to 30 seconds.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

To allow using the storage driver APIs to do operation on generic domain
disks we will need to introduce internal storage pools that will give is
a base to support this stuff even on files that weren't originally
defined as a part of the pool.

This patch introduces the 'internal' flag for a storage pool that will
prevent it from being listed along with the user defined storage pools.

Separate the steps to create libvirt's volume metadata from the actual
volume building process.

Separate the steps to create libvirt's volume metadata from the actual
volume building process.

Separate the steps to create libvirt's volume metadata from the actual
volume building process.

Separate the steps to create libvirt's volume metadata from the actual
volume building process. This is already done for regular file based
pools to allow job support for storage APIs.

Implement the "deleteVol" storage backend function for gluster volumes.

Currently, during XML parsing, when a call to a FromString() function to
get an enum value fails, the error which is reported is either
VIR_ERR_CONFIG_UNSUPPORTED, VIR_ERR_INTERNAL_ERROR or VIR_ERR_XML_ERROR.

This commit makes such conversion failures consistently return
VIR_ERR_CONFIG_UNSUPPORTED.