Add the sysfs_prefix argument to the call to allow for setting the
path for tests to something other than SYSFS_SYSTEM_PATH.

Add the sysfs_prefix argument to the call to allow for setting the
path for tests to something other than SYSFS_SYSTEM_PATH.

Add the sysfs_prefix argument to the call to allow for setting the
path for tests to something other than SYSFS_SYSTEM_PATH.

Build with gcc 4.8 fails with:

bhyve/bhyve_monitor.c: In function 'bhyveMonitorIO':
bhyve/bhyve_monitor.c:51:18: error: missing initializer for field 'tv_sec' of 'const struct timespec' [-Werror=missing-field-initializers]
     const struct timespec zerowait = {};

Explicitly initialize zerowait to fix the build.

Every domain that grabs a domain object to work over should
reference it to make sure it won't disappear meanwhile.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This needs to specified in way too many places for a simple validation
check. The ostype/arch/virttype validation checks later in
DomainDefParseXML should catch most of the cases that this was covering.

Rather than an opencoded string. This should be a no-op

This patch adds code that parses and formats configuration for memory
devices.

A simple configuration would be:
<memory model='dimm'>
  <target>
    <size unit='KiB'>524287</size>
    <node>0</node>
  </target>
</memory>

A complete configuration of a memory device:
<memory model='dimm'>
  <source>
    <pagesize unit='KiB'>4096</pagesize>
    <nodemask>1-3</nodemask>
  </source>
  <target>
    <size unit='KiB'>524287</size>
    <node>1</node>
  </target>
</memory>

This patch preemptively forbids use of the <memory> device in individual
drivers so the users are warned right away that the device is not
supported.

Add a XML element that will allow to specify maximum supportable memory
and the count of memory slots to use with memory hotplug.

To avoid possible confusion and misuse of the new element this patch
also explicitly forbids the use of the maxMemory setting in individual
drivers's post parse callbacks. This limitation will be lifted when the
support is implemented.

Wikipedia's list of common misspellings [1] has a machine-readable
version.  This patch fixes those misspellings mentioned in the list
which don't have multiple right variants (as e.g. "accension", which can
be both "accession" and "ascension"), such misspellings are left
untouched.  The list of changes was manually re-checked for false
positives.

[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machinesSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

As there are two possible approaches to define a domain's memory size -
one used with legacy, non-NUMA VMs configured in the <memory> element
and per-node based approach on NUMA machines - the user needs to make
sure that both are specified correctly in the NUMA case.

To avoid this burden on the user I'd like to replace the NUMA case with
automatic totaling of the memory size. To achieve this I need to replace
direct access to the virDomainMemtune's 'max_balloon' field with
two separate getters depending on the desired size.

The two sizes are needed as:
1) Startup memory size doesn't include memory modules in some
hypervisors.
2) After startup these count as the usable memory size.

Note that the comments for the functions are future aware and document
state that will be present after a few later patches.

Filter out non-migratable features if
VIR_CONNECT_BASELINE_CPU_MIGRATABLE was specified.

Return 0 instead of ERR_NO_SUPPORT in each driver
where we don't support managed save or -1 if
the domain does not exist.

This avoids spamming daemon logs when 'virsh dominfo' is run.

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

For stateless, client side drivers, it is never correct to
probe for secondary drivers. It is only ever appropriate to
use the secondary driver that is associated with the
hypervisor in question. As a result the ESX & HyperV drivers
have both been forced to do hacks where they register no-op
drivers for the ones they don't implement.

For stateful, server side drivers, we always just want to
use the same built-in shared driver. The exception is
virtualbox which is really a stateless driver and so wants
to use its own server side secondary drivers. To deal with
this virtualbox has to be built as 3 separate loadable
modules to allow registration to work in the right order.

This can all be simplified by introducing a new struct
recording the precise set of secondary drivers each
hypervisor driver wants

struct _virConnectDriver {
    virHypervisorDriverPtr hypervisorDriver;
    virInterfaceDriverPtr interfaceDriver;
    virNetworkDriverPtr networkDriver;
    virNodeDeviceDriverPtr nodeDeviceDriver;
    virNWFilterDriverPtr nwfilterDriver;
    virSecretDriverPtr secretDriver;
    virStorageDriverPtr storageDriver;
};

Instead of registering the hypervisor driver, we now
just register a virConnectDriver instead. This allows
us to remove all probing of secondary drivers. Once we
have chosen the primary driver, we immediately know the
correct secondary drivers to use.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virDomainDefineXMLFlags and virDomainCreateXML APIs both
gain new flags allowing them to be told to validate XML.
This updates all the drivers to turn on validation in the
XML parser when the flags are set

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.

Make sure every virt driver implements virDomainDefineXMLFlags
by adding a trivial passthrough from the existing impl with
no flags set.

Reboot requires more sophistication and is left as a future work item --
but at least part of the plumbing is in place.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Rather than just picking the first CD (or failing that, HDD) we come
across, if the user has picked a boot device ordering with <boot
order=''>, respect that (and just try to boot the lowest-index device).

Adds two sets of tests to bhyve2xmlargv; 'grub-bootorder' shows that we
pick a user-specified device over the first device in the domain;
'grub-bootorder2' shows that we pick the first (lowest index) device.

This enables booting interactive GRUB menus (e.g. install CDs) with
libvirt-bhyve.

Caveat: A terminal other than the '--console' option to 'virsh start'
(e.g. 'cu -l /dev/nmdm0B -s 115200') must be used to connect to
grub-bhyve because the bhyve loader path is synchronous and must occur
before the VM actually starts.

Changing the bhyveProcessStart logic around to accommodate '--console'
for interactive loader use seems like a significant project and probably
not worth it, if UEFI/BIOS support for bhyve is "coming soon."

We still default to bhyveloader(1) if no explicit bootloader
configuration is supplied in the domain.

If the /domain/bootloader looks like grub-bhyve and the user doesn't
supply /domain/bootloader_args, we make an intelligent guess and try
chainloading the first partition on the disk (or a CD if one exists,
under the assumption that for a VM a CD is likely an install source).

Caveat: Assumes the HDD boots from the msdos1 partition. I think this is
a pretty reasonable assumption for a VM. (DrvBhyve with Bhyveload
already assumes that the first disk should be booted.)

I've tested both HDD and CD boot and they seem to work.

To prepare for introducing a single global driver, rename the
virDriver struct to virHypervisorDriver and the registration
API to virRegisterHypervisorDriver()

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

Pass the user-specified tun path down when creating tap device
when called from the qemu driver.

Also honor the vhost device path specified by user.

Update bhyveBuildDiskArgStr to support volumes:

 - Make virBhyveProcessBuildBhyveCmd and
   virBhyveProcessBuildLoadCmd take virConnectPtr as the
   first argument instead of bhyveConnPtr as virConnectPtr is
   needed for virStorageTranslateDiskSourcePool,
 - Add virStorageTranslateDiskSourcePool call to
   virBhyveProcessBuildBhyveCmd and
   virBhyveProcessBuildLoadCmd,
 - Allow disks of type VIR_STORAGE_TYPE_VOLUME

If we failed to create BHYVE_STATE_DIR, we should show this
path, not BHYVE_LOG_DIR.

Add support for CDROM devices for bhyve driver using
bhyve(8)'s 'ahci-cd' device type.

As bhyve currently does not support media insertion at runtime,
disallow to start a domain with an empty source path for cdrom
devices.

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

Although the edits were changing in-memory XML, it was not flushed
to disk; so unless some other action changes XML, a libvirtd restart
would lose the changed information.

* src/conf/domain_conf.c (virDomainObjSetMetadata): Add parameter,
to save live status across restarts.
(virDomainSaveXML): Allow for test driver.
* src/conf/domain_conf.h (virDomainObjSetMetadata): Adjust
signature.
* src/bhyve/bhyve_driver.c (bhyveDomainSetMetadata): Adjust caller.
* src/lxc/lxc_driver.c (lxcDomainSetMetadata): Likewise.
* src/qemu/qemu_driver.c (qemuDomainSetMetadata): Likewise.
* src/test/test_driver.c (testDomainSetMetadata): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

For the values "default", "on", "off"

Replaces
virDeviceAddressPCIMulti
virDomainFeatureState
virDomainIoEventFd
virDomainVirtioEventIdx
virDomainDiskCopyOnRead
virDomainMemDump
virDomainPCIRombarMode
virDomainGraphicsSpicePlaybackCompression

Try to reconnect to the running domains after libvirtd restart. To
achieve that, do:

 * Save domain state
  - Modify virBhyveProcessStart() to save domain state to the state
    dir
  - Modify virBhyveProcessStop() to cleanup the pidfile and the state

 * Detect if the state information loaded from the driver's state
   dir matches the actual state. Consider domain active if:
    - PID it points to exist
    - Process title of this PID matches the expected one with the
      domain name

   Otherwise, mark the domain as shut off.

Note: earlier development bhyve versions before FreeBSD 10.0-RELEASE
didn't set proctitle we expect, so the current code will not detect
it. I don't plan adding support for this unless somebody requests
this.

While preparing to add a capability for active commit, I noticed
that the existing code was abusing int for boolean values.

* src/conf/capabilities.h (_virCapsGuestFeature, _virCapsHost)
(virCapabilitiesNew, virCapabilitiesAddGuestFeature): Improve
types.
* src/conf/capabilities.c (virCapabilitiesNew)
(virCapabilitiesAddGuestFeature): Adjust signature.
* src/bhyve/bhyve_capabilities.c (virBhyveCapsBuild): Update
clients.
* src/esx/esx_driver.c (esxCapsInit): Likewise.
* src/libxl/libxl_conf.c (libxlMakeCapabilities): Likewise.
* src/lxc/lxc_conf.c (virLXCDriverCapsInit): Likewise.
* src/openvz/openvz_conf.c (openvzCapsInit): Likewise.
* src/parallels/parallels_driver.c (parallelsBuildCapabilities):
Likewise.
* src/phyp/phyp_driver.c (phypCapsInit): Likewise.
* src/qemu/qemu_capabilities.c (virQEMUCapsInit)
(virQEMUCapsInitGuestFromBinary): Likewise.
* src/security/virt-aa-helper.c (get_definition): Likewise.
* src/test/test_driver.c (testBuildCapabilities): Likewise.
* src/uml/uml_conf.c (umlCapsInit): Likewise.
* src/vbox/vbox_tmpl.c (vboxCapsInit): Likewise.
* src/vmware/vmware_conf.c (vmwareCapsInit): Likewise.
* src/xen/xen_hypervisor.c (xenHypervisorBuildCapabilities):
Likewise.
* src/xenapi/xenapi_driver.c (getCapsObject): Likewise.
* tests/qemucaps2xmltest.c (testGetCaps): Likewise.
* tests/testutils.c (virTestGenericCapsInit): Likewise.
* tests/testutilslxc.c (testLXCCapsInit): Likewise.
* tests/testutilsqemu.c (testQemuCapsInit): Likewise.
* tests/testutilsxen.c (testXenCapsInit): Likewise.
* tests/vircaps2xmltest.c (buildVirCapabilities): Likewise.
* tests/vircapstest.c (buildNUMATopology): Likewise.
* tests/vmx2xmltest.c (testCapsInit): Likewise.
* tests/xml2vmxtest.c (testCapsInit): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

Replace:
if (virBufferError(&buf)) {
    virBufferFreeAndReset(&buf);
    virReportOOMError();
    ...
}

with:
if (virBufferCheckError(&buf) < 0)
    ...

This should not be a functional change (unless some callers
misused the virBuffer APIs - a different error would be reported
then)

So far, we only report an error if formatting the siblings bitmap
in NUMA topology fails.

Be consistent and always report error in virCapabilitiesFormatXML.

Commit 80d0918b introduced a typo in variable name:

s/failIncomaptible/failIncompatible/

Pushed under the build breaker rule.

The new VIR_CONNECT_COMPARE_CPU_FAIL_INCOMPATIBLE flag for
virConnectCompareCPU can be used to get an error
(VIR_ERR_CPU_INCOMPATIBLE) describing the incompatibility instead of the
usual VIR_CPU_COMPARE_INCOMPATIBLE return code.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When CPU comparison APIs return VIR_CPU_COMPARE_INCOMPATIBLE, the caller
has no clue why the CPU is considered incompatible with host CPU. And in
some cases, it would be nice to be able to get such info in a client
rather than having to look in logs.

To achieve this, the APIs can be told to return VIR_ERR_CPU_INCOMPATIBLE
error for incompatible CPUs and the reason will be described in the
associated error message.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>