A simple getopt-based argument parser is added for the /usr/sbin/bhyveload
command, loosely based on its argument parser.

The boot disk is guessed by iterating over all
disks and matching their sources. If any non-default arguments are found,
def->os.bootloaderArgs is set accordingly, and the bootloader is treated as a
custom bootloader.

Custom bootloader are supported by setting the def->os.bootloader and
def->os.bootloaderArgs accordingly

grub-bhyve is also treated as a custom bootloader. Since we don't get the
device map in the native format anyways, we can't reconstruct the complete
boot order. While it is possible to check what type the grub boot disk is by
checking if the --root argument is "cd" or "hd0,msdos1", and then just use the
first disk found, implementing the grub-bhyve argument parser as-is in the
grub-bhyve source would mean adding a dependency to argp or duplicating lots
of the code of argp. Therefore it's not really worth implementing that now.
Signed-off-by: NFabian Freyer <fabian.freyer@physik.tu-berlin.de>

A simpe getopt-based argument parser is added for the /usr/sbin/bhyve command,
loosely based on its argument parser, which reads the following from the bhyve
command line string:

* vm name
* number of vcpus
* memory size
* the time offset (UTC or localtime)
* features:
  * acpi
  * ioapic: While this flag is deprecated in FreeBSD r257423, keep checking for
    it for backwards compatibiility.
* the domain UUID; if not explicitely given, one will be generated.
* lpc devices: for now only the com1 and com2 are supported. It is required for
   these to be /dev/nmdm[\d+][AB], and the slave devices are automatically
   inferred from these to be the corresponding end of the virtual null-modem
   cable: /dev/nmdm<N>A <-> /dev/nmdm<N>B
* PCI devices:
  * Disks: these are numbered in the order they are found, for virtio and ahci
    disks separately. The destination is set to sdX or vdX with X='a'+index;
    therefore only 'z'-'a' disks are supported.
    Disks are considered to be block devices if the path
    starts with /dev, otherwise they are considered to be files.
  * Networks: only tap devices are supported. Since it isn't possible to tell
    the type of the network, VIR_DOMAIN_NET_TYPE_ETHERNET is assumed, since it
    is the most generic. If no mac is specified, one will be generated.
Signed-off-by: NFabian Freyer <fabian.freyer@physik.tu-berlin.de>

First, remove escaped newlines and split up the string into an argv-list for
the bhyve and loader commands, respectively. This is done by iterating over the
string splitting it by newlines, and then re-iterating over each line,
splitting it by spaces.

Since this code reuses part of the code of qemu_parse_command.c
(in bhyveCommandLine2argv), add the appropriate copyright notices.
Signed-off-by: NFabian Freyer <fabian.freyer@physik.tu-berlin.de>

Unconditionally use gnulib's getopt module. This is needed by the bhyve driver
to provide a reentrant interface for getopt.

Several gnulib headers rely on features.h being included by ctype.h to provide
__GNUC_PREREQ, but on systems without glibc, this is not provided. In these
cases __GNUC_PREREQ gets redefined to 0, which causes build errors from checks
in src/internal.h.
Therefore, define __GNUC_PREREQ as early as possible. config-post.h is probably
the first header that is included, before any other headers.

As the empty bitmap exists, we should also test it. This patch adds
test cases for the procedures 'virBitmapNextSetBit', 'virBitmapLastSetBit',
'virBitmapNextClearBit'.
Tested-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

As there is an explicit constructor for the special case of empty
bitmaps, we should mention that the generic constructors rejects the
creation of empty bitmaps.
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

Before the variable 'bits' was initialized with 0 (commit
3470cd86), the following bug was
possible.

A function call with an empty bitmap leads to undefined
behavior. Because if 'bitmap->map_len == 0' 'unusedBits' will be <= 0
and 'sz == 1'. So the non global and non static variable 'bits' would
have never been set. Consequently the check 'bits == 0' results in
undefined behavior.

This patch clarifies the current version of the function by handling the
empty bitmap explicitly. Also, for an empty bitmap there is obviously no
bit set so we can just return -1 (indicating no bit set) right away. The
explicit check for 'bits == 0' after the loop is unnecessary because we
only get to this point if no set bit was found.
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

On some systems perl is not necessarily in /usr/bin/perl. Use the perl version
in the PATH instead.

The spiceMigration flag will never be true if there is no SPICE graphics
configured for the domain.

https://bugzilla.redhat.com/show_bug.cgi?id=1151723Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Otherwise migration during which we didn't send client_migrate_info QMP
command will get stuck waiting for SPICE migration to finish if libvirtd
sent the QMP command in a previous migration attempt.

Broken by bd7c8a69.

https://bugzilla.redhat.com/show_bug.cgi?id=1151723Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

People debugging guest OS boot processes and reported that
the default 128 KB size is too small to capture an entire
boot up sequence. Increase the default size to 2 MB which
should allow capturing a full boot up even with verbose
debugging.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently virtlogd has a hardcoded max file size of 128kb
and max of 3 backups. This adds two new config parameters
to /etc/libvirt/virtlogd.conf to let these be customized.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Support for SMP topology was added by qemu commit dc6b1c09849484fbbc50
prior to 0.12.0, our minimum supported qemu version.

$ git describe --tags dc6b1c09849484fbbc50803307e4c7a3d81eab62
v0.11.0-rc0-449-gdc6b1c0
$ git describe --tags --contains dc6b1c09849484fbbc50803307e4c7a3d81eab
v0.12.0-rc0~1477

After 27726d8c a privateData is allocated in
virDomainHostdevDefAlloc(). However, the counter part - freeing
them in Free() is missing which leads to the following memory
leak:

==6489== 24 bytes in 1 blocks are definitely lost in loss record 684 of 1,003
==6489==    at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==6489==    by 0x54B7C94: virAllocVar (viralloc.c:560)
==6489==    by 0x5517BE6: virObjectNew (virobject.c:193)
==6489==    by 0x1B400121: qemuDomainHostdevPrivateNew (qemu_domain.c:798)
==6489==    by 0x5557B24: virDomainHostdevDefAlloc (domain_conf.c:2152)
==6489==    by 0x5575578: virDomainHostdevDefParseXML (domain_conf.c:12709)
==6489==    by 0x5582292: virDomainDefParseXML (domain_conf.c:16995)
==6489==    by 0x5583C98: virDomainDefParseNode (domain_conf.c:17470)
==6489==    by 0x5583B07: virDomainDefParse (domain_conf.c:17417)
==6489==    by 0x5583B95: virDomainDefParseFile (domain_conf.c:17441)
==6489==    by 0x55A3F24: virDomainObjListLoadConfig (virdomainobjlist.c:465)
==6489==    by 0x55A43E6: virDomainObjListLoadAllConfigs (virdomainobjlist.c:596)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is preferrable to -nographic which (in addition to disabling
graphics output) redirects the serial port to stdio and on OpenBIOS
enables the firmware's serial console.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Add a new capability for the -display command line option, which has
been present since QEMU 1.0.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Libxl is the last user and I don't have the toolchain prepared to
compile the libxl driver. Move it to the libxl driver to avoid having to
refactor the code.

Few arguments of the function are not necessary any more which leads to
some cleanups. The 'uri' argument had a stray ATTRIBUTE_UNUSED.

The impls are identical and I don't have a reasonable idea where to
extract it.

This also kills yet another use of virDomainLiveConfigHelperMethod.

Use a VIR_ prefix even when it's a local helper macro. It will be later
synced with the LXC implementation.

The new package for the virt-admin binary is libvirt-admin.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Currently, we have libvirt-client library which serves as a
collection point for all the libraries and client binaries we
have. Therefore we have couple of silly dependencies, for
instance libvirt-daemon depends on libvirt-client. Only because
the shared library is in the client package.
To solve this, new package libvirt-libs is introduced where all
the libraries are going to live. The client package is then set
to depend on this new package, just like the rest of packages
that suffer the same problem.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is just a convenience method for discarding a list of filters instead of
using a 'for' loop everywhere. It is safe to pass -1 as the number of elements
in the list as well as passing NULL as list reference.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Provide a separate method to free a logging filter object. This will come handy
once a method to create an individual logging filter object is introduced.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This is just a convenience method for discarding a list of outputs instead of
using a 'for' loop everywhere. It is safe to pass -1 as the number of elements
in the list as well as passing NULL as list reference.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Provide a separate method to free a logging output object. This will come handy
once a method to create an individual logging output object is introduced.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Same as with outputs; since the operations will be further divided into smaller
tasks, creating a filter will become a separate operation that will return
a reference to a newly created filter.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Right now, we define outputs one after another. However, the correct flow
should be to define a set of outputs as a whole unit. Therefore each output
should be first created, placed into an array/list and the list will be
defined. Output creation should be a separate operation, so an output will be
returned by a reference. From that perspective, it makes perfect sense to
only store pointers to actual outputs.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

In this particular case, reset is meant as clearing the whole list of
outputs/filters, not resetting it to a predefined default setting. Looking at
it from that perspective, returning the number of records removed doesn't help
the caller in any way (not that any of the callers would actually check for
it). Well, callers could detect an error from the number of successfully
removed records, but the only thing that can fail in virLogReset is force
closing a file descriptor in which case the error isn't propagated back to
virLogReset anyway. Conclusion: there is no practical use for having a return
type of 'int' rather than 'void' in this case.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Due to the way the hardware works, KVM on ppc64 always requires
memory locking; however, that is not the case for non-KVM ppc64
guests, eg. ppc64 guests that are running on x86_64 with TCG.

Only require memory locking for ppc64 guests if they are using
KVM or, as it's the case for all architectures, they have host
devices assigned using VFIO.

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

Fix mingw build regarding rpl_{printf,scanf} symbols.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

For type='ethernet' interfaces only.

(This patch had been pushed earlier in
commit 0b4645a7, but was reverted in
commit 84d47a3c because it had been
accidentally pushed during the freeze for release 2.0.0)

(This patch had been pushed earlier in
commit cd5c9f21, but was reverted in
commit 1549f168 because it had been
accidentally pushed during the freeze for release 2.0.0)

This will apply to any IP address setting that uses
virNetDevIPInfoAddToDev() (which so far is only the guest-side of LXC
type='ethernet' interfaces).

(This patch had been pushed earlier in
commit cb20f989, but was reverted in
commit cba06aea because it had been
accidentally pushed during the freeze for release 2.0.0)

This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:

    <interface type='ethernet'>
      <mac address='00:16:3e:0f:ef:8a'/>
      <source>
        <ip address='192.168.122.12' family='ipv4'
            prefix='24' peer='192.168.122.1'/>
        <ip address='192.168.122.13' family='ipv4' prefix='24'/>
        <route family='ipv4' address='0.0.0.0'
               gateway='192.168.122.1'/>
        <route family='ipv4' address='192.168.124.0' prefix='24'
               gateway='192.168.124.1'/>
      </source>
    </interface>

In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types if needed, and 2) we can retain the info
when set to an invalid interface type all the way through to
validation and report a proper error, rather than just ignoring it
(which is currently what happens for many other type-specific
settings).

(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).

(This patch had been pushed earlier in
commit fe6a7789, but was reverted in
commit d6584565 because it had been
accidentally pushed during the freeze for release 2.0.0)

The peer attribute is used to set the property of the same name in the
interface IP info:

  <interface type='ethernet'>
    ...
    <ip family='ipv4' address='192.168.122.5'
        prefix='32' peer='192.168.122.6'/>
    ...
  </interface>

Note that this element is used to set the IP information on the
*guest* side interface, not the host side interface - that will be
supported in an upcoming patch.

(This patch now has quite a history: it was originally pushed in
commit 690969af, which was subsequently reverted in commit 1d14b13f,
then reworked and pushed (along with a lot of other related/supporting
patches) in commit 93135abf; however *that* commit had been
accidentally pushed during dev. freeze for release 2.0.0, so it was
again reverted in commit f6acf039).
Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>
Signed-off-by: NLaine Stump <laine@laine.org>

This patch takes the code out of
lxcContainerRenameAndEnableInterfaces() that adds all IP addresses and
IP routes to the interface, and puts it into a utility function
virNetDevIPInfoAddToDev() in virnetdevip.c so that it can be used by
anyone.

One small change in functionality -
lxcContainerRenameAndEnableInterfaces() previously would add all IP
addresses to the interface while it was still offline, then set the
interface online, and then add the routes. Because I don't want the
utility function to set the interface online, I've moved this up so
the interface is first set online, then IP addresses and routes are
added. This is the same order that the network service from
initscripts (in ifup-ether) does it, so it shouldn't pose any problem
(and hasn't, in the tests that I've run).

(This patch had been pushed earlier in commit
f1e0d0da, but was reverted in commit
05eab475 because it had been
accidentally pushed during the freeze for release 2.0.0)

Introduce a helper to help determine if a disk src could be possibly used
for a disk secret... Going to need this for hot unplug.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>