Newer versions of Debian use '/run/initctl' instead of '/dev/initctl'.
This patch updates the code to search for the FIFO from a list of
well-known locations.

Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

Build with clang fails with:

  CC       util/libvirt_util_la-virsocketaddr.lo
util/virsocketaddr.c:904:17: error: cast from 'struct sockaddr *' to
'struct sockaddr_in *' increases required alignment from 1 to 4
[-Werror,-Wcast-align]
        inet4 = (struct sockaddr_in*) res->ai_addr;
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
util/virsocketaddr.c:909:17: error: cast from 'struct sockaddr *' to
'struct sockaddr_in6 *' increases required alignment from 1 to 4
[-Werror,-Wcast-align]
        inet6 = (struct sockaddr_in6*) res->ai_addr;
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.

Fix that by replacing virSocketAddrParseInternal() call with
virSocketAddrParse() in the virSocketAddrIsNumericLocalhost() function.
virSocketAddrParse stores an address in virSocketAddr.
virSocketAddr uses a union to store an address, so it doesn't
need casting.

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

Commit 4882618e added the code that
requests driver cfg, but forgot to unref it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

virt-manager on Fedora sets up i686 hosts with "/usr/bin/qemu-kvm" emulator,
which in turn unconditionally execs qemu-system-x86_64 querying capabilities
then fails:

Error launching details: invalid argument: architecture from emulator 'x86_64' doesn't match given architecture 'i686'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 748, in _show_vm_helper
    details = self._get_details_dialog(uri, vm.get_connkey())
  File "/usr/share/virt-manager/virtManager/engine.py", line 726, in _get_details_dialog
    obj = vmmDetails(conn.get_vm(connkey))
  File "/usr/share/virt-manager/virtManager/details.py", line 399, in __init__
    self.init_details()
  File "/usr/share/virt-manager/virtManager/details.py", line 784, in init_details
    domcaps = self.vm.get_domain_capabilities()
  File "/usr/share/virt-manager/virtManager/domain.py", line 518, in get_domain_capabilities
    self.get_xmlobj().os.machine, self.get_xmlobj().type)
  File "/usr/lib/python2.7/site-packages/libvirt.py", line 3492, in getDomainCapabilities
    if ret is None: raise libvirtError ('virConnectGetDomainCapabilities() failed', conn=self)
libvirtError: invalid argument: architecture from emulator 'x86_64' doesn't match given architecture 'i686'

Journal:

Oct 16 21:08:26 goatlord.localdomain libvirtd[1530]: invalid argument: architecture from emulator 'x86_64' doesn't match given architecture 'i686'

If VM is configured with many devices(including passthrough devices)
and large memory, libvirtd will take seconds(in the worst case) to
wait for monitor. In this period the qemu process may run on any
PCPU though I intend to pin emulator to the specified PCPU in xml
configuration.

Actually qemu process takes high cpu usage during vm startup.
So this is not the strict CPU isolation in this case.
Signed-off-by: NZhou yimin <zhouyimin@huawei.com>

These tools have been rewritten upstream, so you don't need to link to
the old tools, link to the new ones and mention they are part of
libguestfs.

Also remove the link to "Poor man's P2V".  There's no real reason to
use that technique any longer since the rewritten tools are simple,
fast and highly capable.

VIR_TEST_DEBUG=2 ./qemuxml2argvtest generates the following output:

409) QEMU XML-2-ARGV shmem-invalid-size
... Got expected error: unsupported configuration: ivshmem device is not \
	 supported with this QEMU binary
OK
410) QEMU XML-2-ARGV shmem-small-size
... Got expected error: unsupported configuration: ivshmem device is not \
supported with this QEMU binary
OK

We should have:

409) QEMU XML-2-ARGV shmem-invalid-size
... Got expected error: XML error: shmem size must be a power of two
OK
410) QEMU XML-2-ARGV shmem-small-size
... Got expected error: XML error: shmem size must be at least 1 MiB
OK

This commit fixes the issue by providing QEMU_CAPS_DEVICE_IVSHMEM caps
for shmem-invalid-size, shmem-small-size test.
Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>

The mode attribute is required for the source element of vhost-user.
Thus virDomainNetDefFormat should always generate a xml with it and not
only when the mode is server.

The commit fixes the issue. And it adds a vhostuser interface in
'client' mode to qemuxml2argv-net-vhostuser.(args|xml) to test this
usecase.
Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>

Add missing 'break's from commit 1298daca, as noted by John Ferlan

https://www.redhat.com/archives/libvir-list/2014-October/msg00430.html

Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>

Shove it to the top of the file so that it can be reused earlier.

To allow easy implementation of a callback check this patch adds empty
post parse callbacks to drivers that were missing them.

To allow live modification of device backends in qemu libvirt needs to
be able to hot-add/remove "objects". Add monitor backend functions to
allow this.

This function will be used for hot-add/remove of RNG backends,
IOThreads, memory backing objects, etc.

Add a new option specifier that will optionally add a JSON key=value pair
containing a nested object if the added object isn't NULL.

The JSON structure constructor has an option to add JSON arrays to the
constructed object. The description is inaccurate as it can add any json
object even a dict. Change the docs to cover this option and reject
adding NULL objects.

Our qemu monitor code has a converter from key-value pairs to a json
value object. I want to re-use the code later and having it part of the
monitor command generator is inflexible. Split it out into a separate
helper.

As in the device info iterator add a switch that will force the compiler
to check that new device types are added to the ABI stability checker.

Although the device will probably inhibit migration add checks to make
sure that the configuration change gets caught.

Use typecasted switch statement and note the type used to select the
address type in a comment.

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

Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>

When enabling the migration_address option, by default it is
set to "127.0.0.1", but it's not a valid address for migration.
so we should add verification and set the default migration_address
to "0.0.0.0".
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

if specifying migration_host to an Ipv6 address without brackets,
it was resolved to an incorrect address, such as:
    tcp:2001:0DB8::1428:4444,
but the correct address should be:
    tcp:[2001:0DB8::1428]:4444
so we should add brackets when parsing it.
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>

Helper function to strip the brackets from an IPv6 address.
Tested by viruritest.

Few places still used hardcoded limit for maximum XML size for commands
that accept XML files. The hardcoded limits ranged from 8k to 1M. Use
VSH_MAX_XML_FILE to express this limit in a unified way. This will bump
the limit for the commands that used hardcoded string lengths to 10M.

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

dommemstat and blkdeviotune's man page incorrectly stated the usage of
--live and --config.

Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

The actual origin of this so called typo are two commits.  The first one
was commit 72f8a7f1 that came up with the following condition:

if ((i == 8) & (flags & VIR_QEMU_PROCESS_KILL_FORCE))

Fortunately this succeeded thanks to bool being (int)1 and
VIR_QEMU_PROCESS_KILL_FORCE having the value of 1 << 0.  The check was
then moved and altered in 8fd38231 to
current state:

if ((i == 50) & force)

that will work again (both sides of '&' being booleans), but since this
was missed so many times, it may pose a problem in the future in case it
gets copy-pasted again.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This started as an investigation into an issue where libvirt (using the
libxl driver) and the Xen host, like an old couple, could not agree on
who is responsible for selecting the VNC port to use.

Things usually (and a bit surprisingly) did work because, just like that
old couple, they had the same idea on what to do by default. However it
was possible that this ended up in a big argument.

The problem is that display information exists in two different places:
in the vfbs list and in the build info. And for launching the device model,
only the latter is used. But that never gets initialized from libvirt. So
Xen allows the device model to select a default port while libvirt thinks
it has told Xen that this is done by libvirt (though the vfbs config).

While fixing that, I made a stab at actually evaluating the configuration
of the video device. So that it is now possible to at least decide between
a Cirrus or standard VGA emulation and to modify the VRAM within certain
limits using libvirt.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>