The virDomainDefParse* and virDomainDefFormat* methods both
accept the VIR_DOMAIN_XML_* flags defined in the public API,
along with a set of other VIR_DOMAIN_XML_INTERNAL_* flags
defined in domain_conf.c.

This is seriously confusing & error prone for a number of
reasons:

 - VIR_DOMAIN_XML_SECURE, VIR_DOMAIN_XML_MIGRATABLE and
   VIR_DOMAIN_XML_UPDATE_CPU are only relevant for the
   formatting operation
 - Some of the VIR_DOMAIN_XML_INTERNAL_* flags only apply
   to parse or to format, but not both.

This patch cleanly separates out the flags. There are two
distint VIR_DOMAIN_DEF_PARSE_* and VIR_DOMAIN_DEF_FORMAT_*
flags that are used by the corresponding methods. The
VIR_DOMAIN_XML_* flags received via public API calls must
be converted to the VIR_DOMAIN_DEF_FORMAT_* flags where
needed.

The various calls to virDomainDefParse which hardcoded the
use of the VIR_DOMAIN_XML_INACTIVE flag change to use the
VIR_DOMAIN_DEF_PARSE_INACTIVE flag.

The virCPUDefFormat* methods were relying on the VIR_DOMAIN_XML_*
flag definitions. It is not desirable for low level internal
functions to be coupled to flags for the public API, since they
may need to be called from several different contexts where the
flags would not be appropriate.

QEMU supports feature specification with -cpu host and we just skip
using that.  Since QEMU developers themselves would like to use this
feature, this patch modifies the code to work.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1178850Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This reverts commit 6b818d3b.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Well, apparently it's possible for a patch to sneak in through
review process and break 'make check'. It happened just lately
with 0e502466 which changed the default of vgamem_mb for
qxl device. However, there were left some domain XMLs within our
test suite relying on the old default. These should be updated to
match the change.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

VMware ESX does not always set the "serialX.fileType" tag in VMX files. The
default value for this tag is "device", and when adding a new serial port
of this type VMware will omit the fileType tag. This caused libvirt to
fail to parse the VMX file. Fixed by making this tag optional and using
"device" as a default value. Also updated vmx2xmltest to test for this
case.
Signed-off-by: NEric Blake <eblake@redhat.com>

Make use of the ebtables functionality to be able to filter certain
parameters of icmpv6 packets. Extend the XML parser for icmpv6 types,
type ranges, codes, and code ranges. Extend the nwfilter documentation,
schema, and test cases.

Being able to filter icmpv6 types and codes helps extending the DHCP
snooper for IPv6 and filtering at least some parameters of IPv6's NDP
(Neighbor Discovery Protocol) packets. However, the filtering will not
be as good as the filtering of ARP packets since we cannot
check on IP addresses in the payload of the NDP packets.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Network interfaces devices and host devices with net capabilities can
now have IPv4 and/or an IPv6 routes configured.

Add the possibility to have more than one IP address configured for a
domain network interface. IP addresses can also have a prefix to define
the corresponding netmask.

Add tests to testing HVM default features (pae, acpi, apic)
conversion from xm config to libvirt xml. If no pae|acpi|apic
specified in xm config, after conversion, libvirt xml should
by default include:
 <features>
   <pae/>
   <apic/>
   <acpi/>
 </features>
Signed-off-by: NChunyan Liu <cyliu@suse.com>

add tests for the xen_xl config parser
Signed-off-by: NKiarie Kahurani <davidkiarie4@gmail.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

The <domain/> element under /capabilities/guest/arch/ can have no
child elements. If that's the case we format:

        <domain type='xen'>
        </domain>

instead of simpler:

        <domain type='xen'/>

This commit fixes that.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There are two more places after commit 3865941b that need to be adapted
in order to get rid of some test failures when building as root.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Some of the nwfilter tests are now failing since --concurrent shows
up in the ebtables command. To avoid this, implement a function
preventing the probing for lock support in the eb/iptables tools
and use it in the tests.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Libvirt BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1175397
QEMU BZ:    https://bugzilla.redhat.com/show_bug.cgi?id=1170093

In qemu there are two interesting arguments:

1) -numa to create a guest NUMA node
2) -object memory-backend-{ram,file} to tell qemu which memory
region on which host's NUMA node it should allocate the guest
memory from.

Combining these two together we can instruct qemu to create a
guest NUMA node that is tied to a host NUMA node. And it works
just fine. However, depending on machine type used, there might
be some issued during migration when OVMF is enabled (see QEMU
BZ). While this truly is a QEMU bug, we can help avoiding it. The
problem lies within the memory backend objects somewhere. Having
said that, fix on our side consists on putting those objects on
the command line if and only if needed. For instance, while
previously we would construct this (in all ways correct) command
line:

    -object memory-backend-ram,size=256M,id=ram-node0 \
    -numa node,nodeid=0,cpus=0,memdev=ram-node0

now we create just:

    -numa node,nodeid=0,cpus=0,mem=256

because the backend object is obviously not tied to any specific
host NUMA node.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Volume and pool formatting functions took different approaches to
unspecified uids/gids.  When unknown, it is always parsed as -1, but one
of the functions formatted it as unsigned int (wrong) and one as
int (better).  Due to that, our two of our XML files from tests cannot
be parsed on 32-bit machines.

RNG schema needs to be modified as well, but because both
storagepool.rng and storagevol.rng need same schema for permission
element, save some space by moving it to storagecommon.rng.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

It occurred to me that OpenStack uses the following XML when not using
regular huge pages:

  <memoryBacking>
    <hugepages>
      <page size='4' unit='KiB'/>
    </hugepages>
  </memoryBacking>

However, since we are expecting to see huge pages only, we fail to
startup the domain with following error:

  libvirtError: internal error: Unable to find any usable hugetlbfs
  mount for 4 KiB

While regular system pages are not huge pages technically, our code is
prepared for that and if it helps OpenStack (or other management
applications) we should cope with that.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

In our config files users are expected to pass several integer values
for different configuration knobs. However, majority of them expect a
nonnegative number and only a few of them accept a negative number too
(notably keepalive_interval in libvirtd.conf).
Therefore, a new type to config value is introduced: VIR_CONF_ULONG
that is set whenever an integer is positive or zero. With this
approach knobs accepting VIR_CONF_LONG should accept VIR_CONF_ULONG
too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This fixes reverting to snapshots created by older libvirt
and allows libvirt not to lose track of a domain that
has this in its live status XML (such as a domain
restored from managedsave)

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

The macTableManager attribute of a network's bridge subelement tells
libvirt how the bridge's MAC address table (used to determine the
egress port for packets) is managed. In the default mode, "kernel",
management is left to the kernel, which usually determines entries in
part by turning on promiscuous mode on all ports of the bridge,
flooding packets to all ports when the correct destination is unknown,
and adding/removing entries to the fdb as it sees incoming traffic
from particular MAC addresses.  In "libvirt" mode, libvirt turns off
learning and flooding on all the bridge ports connected to guest
domain interfaces, and adds/removes entries according to the MAC
addresses in the domain interface configurations. A side effect of
turning off learning and unicast_flood on the ports of a bridge is
that (with Linux kernel 3.17 and newer), the kernel can automatically
turn off promiscuous mode on one or more of the bridge's ports
(usually only the one interface that is used to connect the bridge to
the physical network). The result is better performance (because
packets aren't being flooded to all ports, and can be dropped earlier
when they are of no interest) and slightly better security (a guest
can still send out packets with a spoofed source MAC address, but will
only receive traffic intended for the guest interface's configured MAC
address).

The attribute looks like this in the configuration:

  <network>
    <name>test</name>
    <bridge name='br0' macTableManager='libvirt'/>
    ...

This patch only adds the config knob, documentation, and test
cases. The functionality behind this knob is added in later patches.

If probing capabilities via QMP fails, we now have a check
that prevents us falling back to -help parsing. Unfortunately
the error message

  "Failed to probe capabilities for /usr/bin/qemu-kvm:
   unsupported configuration: QEMU 2.1.2 is too new for help parsing"

is proving rather unhelpful to the user. We need to be telling
them why QMP failed (the root cause), rather than they can't
use -help (the side effect).

To do this we should capture stderr during QMP probing, and
if -help parsing then sees a new QEMU version, we know that
QMP should have worked, and so we can show the messages from
stderr. The message thus becomes

  "Failed to probe capabilities for /usr/bin/qemu-kvm:
   internal error: QEMU / QMP failed: Could not access
   KVM kernel module: No such file or directory
   failed to initialize KVM: No such file or directory"

When trying clang, it found out that we were comparing sizeof with 0
even though we wanted to check the return value of memcmp.  That showed
us that the test was wrong and it needs a fix as well.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Now that we don't use the leases file at all for leases just don't
format it into the config and use the leaseshelper to do all the
lifting.

It looks like it was copy-pasted, so in case anyone wonders what some of
those methods do without looking at them, and for the sake of
completeness, fix them.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commit 2aa167ca tried to fix the DBus interaction code to allow
callers to use native types instead of 4-byte bools.  But in
fixing the issue, I missed the case of an arrayref; Conrad Meyer
shows the following valid complaint issued by clang:

  CC       util/libvirt_util_la-virdbus.lo
util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,-Wcast-align]
            GET_NEXT_VAL(dbus_bool_t, bool_val, bool, "%d");
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
util/virdbus.c:858:17: note: expanded from macro 'GET_NEXT_VAL'
            x = (dbustype *)(*xptrptr + (*narrayptr - 1));              \
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.

But fixing that points out that we have NEVER supported arrayrefs
of sub-int types (byte, i16, u16, and now bool).  Again, while raw
types promote, arrays do not; so the macros HAVE to deal with both
size possibilities rather than assuming that an arrayref uses the
same sizing as the promoted raw type.

Obviously, our testsuite wasn't covering as much as it should have.

* src/util/virdbus.c (GET_NEXT_VAL): Also fix array cases.
(SET_NEXT_VAL): Fix uses of sub-int arrays.
* tests/virdbustest.c (testMessageArray, testMessageArrayRef):
Test it.
Signed-off-by: NEric Blake <eblake@redhat.com>

Add attribute to set vgamem_mb parameter of QXL device for QEMU. This
value sets the size of VGA framebuffer for QXL device. Default value in
QEMU is 8MB so reuse it also in libvirt to not break things.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

So far we didn't have any option to set video memory size for qemu video
devices. There was only the vram (ram for QXL) attribute but it was valid
only for the QXL video device.

To provide this feature to users QEMU has a dedicated device attribute
called 'vgamem_mb' to set the video memory size. We will use the 'vram'
attribute for setting video memory size for other QEMU video devices.

For the cirrus device we will ignore the vram value because it has
hardcoded video size in QEMU.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Allow setting vgamem size for video devices.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

QEMU has two different type of QXL display device. The first "qxl-vga"
is for primary video device and second "qxl" is for secondary video
device.

There are also two different ways how to specify those devices on qemu
command line, the first one and obsolete is using "-vga" option and the
current new one is using "-device" option. The "-vga" could be used only
to setup primary video device, so the "-vga qxl" equal to
"-device qxl-vga". Unfortunately the "-vga qxl" doesn't support setting
additional parameters for the device and "-global" option must be used
for this purpose. It's mandatory to use "-global qxl-vga...." to set the
parameters of primary video device previously defined with "-vga qxl".

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The vram attribute was introduced to set the video memory but it is
usable only for few hypervisors excluding QEMU/KVM and the old XEN
driver. Only in case of QEMU the vram was used for QXL.

This patch updates the documentation to reflect current code in libvirt
and also changes the cases when we will set the default vram attribute.
It also fixes existing strange default value for VGA devices 9MB to 16MB
because the video ram should be rounded to power of two.

The change of default value could affect migrations but I found out that
QEMU always round the video ram to power of two internally so it's safe
to change the default value to the next closest power of two and also
silently correct every domain XML definition. And it's also safe because
we don't pass the value to QEMU.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

There are two special cases, if the input number is 0 or the number is
larger then 2^31 (for 32bit unsigned int). For the special cases the
return value is 0 because they cannot be rounded.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Add test cases for qemuAgentGetFSInfo, with a sample agent response for
the qemu-get-fsinfo command and a configuration xml.
Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama@hds.com>

Improve the monitor function to also retrieve the guest state of
character device (if provided) so that we can refresh the state of
virtio-serial channels and perhaps react to changes in the state in
future patches.

This patch changes the returned data from qemuMonitorGetChardevInfo to
return a structure containing the pty path and the state for all the
character devices.

The change to the testsuite makes sure that the data is parsed
correctly.

To be able to express some use cases of the RBD backing with libvirt, we
need to be able to specify a config file for the RBD client to qemu as
that is one of the commonly used options.

Some storage systems have internal support for snapshots. Libvirt should
be able to select a correct snapshot when starting a VM.

This patch adds a XML element to select a storage source snapshot for
the RBD protocol which supports this feature.