New rules are added in fixup_name in gendispatch.pl to keep the name
FSFreeze and FSThaw. This adds a new ACL permission 'fs_freeze',
which is also applied to VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE flag.
Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama@hds.com>
Acked-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

These will freeze and thaw filesystems within guest specified by
@mountpoints parameters. The parameters can be NULL and 0, then all
mounted filesystems are frozen or thawed. @flags parameter, which are
currently not used, is for future extensions.
Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama@hds.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Some CDROM devices are reported by udev to have an ID_TYPE="generic"
thus it is necessary to check if ID_CDROM is present.

As a side effect, treating ID_TYPE="generic" as a missing ID_TYPE will
enable checks for ID_DRIVE_FLASH_SD and ID_DRIVE_FLOPPY and the
udevKludgeStorageType heuristic.
Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

We don't have a "README-valgrind" file.
So remove related description.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

If the XML_PARSE_NOENT flag is passed to libxml2, then any
entities in the input document will be fully expanded. This
allows the user to read arbitrary files on the host machine
by creating an entity pointing to a local file. Removing
the XML_PARSE_NOENT flag means that any entities are left
unchanged by the parser, or expanded to "" by the XPath
APIs.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

test_libvirt_lockd.aug is only generated when qemu driver is enabled.

This uses the new QEMU_CAPS_HOST_PCI_MULTIDOMAIN capability when
present, for -devivce pci-assign, -device vfio-pci, and -pcidevice.

While creating tests for this new functionality, I noticed that the
xmls for two existing tests had erroneously specified an
until-now-ignored domain="0x0002", so I corrected those two tests, and
also added two failure tests to be sure that we alert users who
attempt to use a non-zero domain with a qemu that doesn't support it.

Quite a long time ago, (apparently between qemu 0.12 and 0.13) qemu
quietly began supporting the optional specification of a domain in the
host-side address of all pci passthrough commands (by simply
prepending it to the bus:slot.function format, as
"dddd:bb:ss.f"). Since machines with multiple PCI domains are very
rare, this never came up in practice, so libvirt was never updated to
support it.

This patch takes the first step to supporting specification of a non-0
domain in the host-side address of PCI devices being assigned to a
domain, by adding a capability bit to indicate support
"QEMU_CAPS_HOST_PCI_MULTIDOMAIN", and detect it. Since this support
was added in a version prior to the minimum version required for
QMP-style capabilities detection, the capability is always enabled for
any qemu that uses QMP for capabilities detection. For older qemus,
the only clue that a domain can be specified in the host pci address
is the presence of the string "[seg:]" in the help string for
-pcidevice. (Ironically, libvirt will not be modified to support
specification of domain for -pcidevice, since any qemu new enough for
us to care about also supports "-device pci-assign" or "-device
vfio-pci", which are greatly preferred).

When creating a new volume, it is possible to copy data into it from
another already existing volume (referred to as @origvol). Obviously,
the read-only access to @origvol is required, which is thread safe
(probably not performance-wise though). However, with current code
both @newvol and @origvol are marked as building for the time of
copying data from the @origvol to @newvol. The rationale behind
is to disallow some operations on both @origvol and @newvol, e.g.
vol-wipe, vol-delete, vol-download. While it makes sense to not allow
such operations on partly copied mirror, but it doesn't make sense to
disallow vol-create or vol-download on the source (@origvol).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 1b14c449 broke the build on FreeBSD by changing
the signature of a few functions without updating the
corresponding stubs that are used when WITH_MACVTAP
or WITH_VIRTUALPORT is not defined.

s/virual/virtual
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

In "src/conf/" there are many enumeration (enum) declarations.
Similar to the recent cleanup to "src/util" directory, it's
better to use a typedef for variable types, function types and
other usages. Other enumeration and folders will be changed to
typedef's in the future. Most of the files changed in this commit
are reltaed to Network (network_conf.* and interface_conf.*) enums.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

In "src/conf/" there are many enumeration (enum) declarations.
Similar to the recent cleanup to "src/util" directory, it's
better to use a typedef for variable types, function types and
other usages. Other enumeration and folders will be changed to
typedef's in the future. Most of the files changed in this commit
are related to CPU (cpu_conf) enums.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

In "src/util/" there are many enumeration (enum) declarations.
Sometimes, it's better using a typedef for variable types,
function types and other usages. Other enumeration will be
changed to typedef's in the future.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NLi Yang <liyang.fnst@cn.fujitsu.com>

Add support for the VIR_DOMAIN_REBOOT_PARAVIRT flag in
libxlDomainReboot().

Add support for VIR_DOMAIN_SHUTDOWN_PARAVIRT and
VIR_DOMAIN_SHUTDOWN_ACPI_POWER_BTN flags in
libxlDomainShutdownFlags().

Add a new flag to virDomain{Reboot,Shutdown}FlagValues to allow
shutting down and rebooting a domain via the Xen paravirt control
interface.

All callers of virStorageFileGetMetadataFromBuf were first calling
virStorageFileProbeFormatFromBuf, to learn what format to pass in.
But this function is already wired to do the exact same probe if
the incoming format is VIR_STORAGE_FILE_AUTO, so it's simpler to
just refactor the probing into the central function.

* src/util/virstoragefile.h (virStorageFileGetMetadataFromBuf):
Drop parameter.
(virStorageFileProbeFormatFromBuf): Drop declaration.
* src/util/virstoragefile.c (virStorageFileGetMetadataFromBuf):
Do probe here instead of in callers.
(virStorageFileProbeFormatFromBuf): Make static.
* src/libvirt_private.syms (virstoragefile.h): Drop function.
* src/storage/storage_backend_fs.c (virStorageBackendProbeTarget):
Update caller.
* src/storage/storage_backend_gluster.c
(virStorageBackendGlusterRefreshVol): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

Add a helper function virBhyveGetDomainTotalCpuStats() to
obtain process CPU time using kvm (kernel memory interface)
and use it to set cpuTime field of the virDomainInfo struct in
bhyveDomainGetInfo().

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

Signed-off-by: NLi Yang <liyang.fnst@cn.fujitsu.com>

The only accepted format for now is 'bhyve-argv' which
prints out a bhyve command corresponding to the given
domain definition.

* bhyve_command.c (bhyveBuildNetArgStr, virBhyveProcessBuildBhyveCmd):
  add dryRun mode which doesn't create any devices when enabled
* bhyve_command.c (virBhyveProcessBuildBhyveCmd,
  virBhyveProcessBuildDestroyCmd, virBhyveProcessBuildLoadCmd): accept
  virDomainDefPtr instead of virDomainObjPtr.

Instead of guessing it from the interface name, look into
/proc/net/vlan/<interface>.

This works for devices not named <real_device>.<vlan ID>,
avoiding an error flood when virt-manager keeps asking about
them every second:

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

* docs/news.html.in libvirt.spec.in: updates for release
* po/*.po*: fetched new localization and regenerated

This fixes link failures like:

  CCLD     virfirewalltest
  /usr/bin/ld: virfirewalltest-virfirewalltest.o: undefined reference to
  symbol 'dbus_message_iter_init_append'

When building packages in a clean chroot the QEMU_USER and QEMU_GROUP
don't exist making VirQemuDriverConfigNew fail with privileged=true.

Avoid that by not requiring privileged mode upfront but setting it later
so we skip the user/group existence check.

This solution was suggested by Daniel P. Berrange and tested by Martin
Kletzander.

Currently firewalling is supported on Linux only, so skip the
virfirewalltest on other platforms.

Commit id 'ac9a0963' refactored out the 'withCapacity' for the
virStorageBackendUpdateVolInfo() API.  See:

http://www.redhat.com/archives/libvir-list/2014-April/msg00043.html

This resulted in a difference in how 'virsh vol-info --pool <poolName>
<volume>' or 'virsh vol-list vol-list --pool <poolName> --details' outputs
the capacity information for a directory pool with a qcow2 sparse file.

For example, using the following XML

mkdir /home/TestPool
cat testpool.xml
<pool type='dir'>
  <name>TestPool</name>
  <uuid>6bf80895-10b6-75a6-6059-89fdea2aefb7</uuid>
  <source>
  </source>
  <target>
    <path>/home/TestPool</path>
    <permissions>
      <mode>0755</mode>
      <owner>0</owner>
      <group>0</group>
    </permissions>
  </target>
</pool>

virsh pool-create testpool.xml
virsh vol-create-as --pool TestPool temp_vol_1 \
      --capacity 1048576 --allocation 1048576 --format qcow2
virsh vol-info --pool TestPool temp_vol_1

Results in listing a Capacity value.  Prior to the commit, the value would
be '1.0 MiB' (1048576 bytes). However, after the commit the output would be
(for example) '192.50 KiB', which for my system was the size of the volume
in my file system (eg 'ls -l TestPool/temp_vol_1' results in '197120' bytes
or 192.50 KiB). While perhaps technically correct, it's not necessarily
what the user expected (certainly virt-test didn't expect it).

This patch restores the code to not update the target capacity for this path

gnutls-3.3.0 and newer leaves 2 FDs open in order to be backwards
compatible when it comes to chrooted binaries [1].  Linking
commandhelper with gnutls then leaves these two FDs open and
commandtest fails thanks to that.  This patch does not link
commandhelper with libvirt.la, but rather only the utilities making
the test pass.

Based on suggestion from Daniel [2].

[1] http://lists.gnutls.org/pipermail/gnutls-help/2014-April/003429.html
[2] https://www.redhat.com/archives/libvir-list/2014-April/msg01119.htmlSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

Older gcc (4.1.2-55.el5, 4.2.1 on FreeBSD) reports bogus warnings:
../../src/conf/nwfilter_conf.c:2111: warning: 'protocol' may be used
uninitialized in this function
../../src/conf/nwfilter_conf.c:2110: warning: 'dataProtocolID' may be
used uninitialized in this function

Initialize them to NULL to make the compiler happy.

Commit f22b7899 stumbled across a difference between 32-bit and
64-bit platforms when parsing "-1" as an int.  Now that we've
fixed that difference, it's time to fix the testsuite.

* src/util/virstoragefile.c (virStorageFileParseChainIndex):
Require a positive index.
Signed-off-by: NEric Blake <eblake@redhat.com>

strtoul() is required to parse negative numbers as their
twos-complement positive counterpart.  But sometimes we want
to reject negative numbers.  Add new functions to do this.
The 'p' suffix is a mnemonic for 'positive' (technically it
also parses 0, but 'non-negative' doesn't lend itself to a
nice one-letter suffix).

* src/util/virstring.h (virStrToLong_uip, virStrToLong_ulp)
(virStrToLong_ullp): New prototypes.
* src/util/virstring.c (virStrToLong_uip, virStrToLong_ulp)
(virStrToLong_ullp): New functions.
* src/libvirt_private.syms (virstring.h): Export them.
* tests/virstringtest.c (testStringToLong): Test them.
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms.  Curse you, C type promotion and
narrowing rules, and strtoul specification.  POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives.  Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error.  We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long.  But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN.  Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.

The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d254191 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs.  How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.

[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.

This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.

* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: NEric Blake <eblake@redhat.com>

A couple of places in the QEMU XML -> ARGV conversion code
raised an error but then forgot to return an error status
due to missing gotos. While fixing this also tweak style
of a couple of other error reports
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>