Recently e1000 NIC support was added to bhyve; implement that in
the bhyve driver:

 - Add capability check by analyzing output of the 'bhyve -s 0,e1000'
   command
 - Modify bhyveBuildNetArgStr() to support e1000 and also pass
   virConnectPtr so it could call bhyveDriverGetCaps() to check if this
   NIC is supported
 - Modify command parsing code to add support for e1000 and adjust tests
 - Add net-e1000 test

virNetDevTapCreateInBridgePort() has always set the new tap device to
the current MTU of the bridge it's being attached to. There is one
case where we will want to set the new tap device to a different
(usually larger) MTU - if that's done with the very first device added
to the bridge, the bridge's MTU will be set to the device's MTU. This
patch allows for that possibility by adding "int mtu" to the arg list
for virNetDevTapCreateInBridgePort(), but all callers are sending -1,
so it doesn't yet have any effect.

Since the requested MTU isn't necessarily what is used in the end (for
example, if there is no MTU requested, the tap device will be set to
the current MTU of the bridge), and the hypervisor may want to know
the actual MTU used, we also return the actual MTU to the caller (if
actualMTU is non-NULL).

As bhyve for a long time didn't have a notion of the explicit SATA
controller and created a controller for each drive, the bhyve driver
in libvirt acted in a similar way and didn't care about the SATA
controllers and assigned PCI addresses to drives directly, as
the generated command will look like this anyway:

 2:0,ahci-hd,somedisk.img

This no longer makes sense because:

 1. After commit c07d1c1c it's not possible to assign
    PCI addresses to disks
 2. Bhyve now supports multiple disk drives for a controller,
    so it's going away from 1:1 controller:disk mapping, so
    the controller object starts to make more sense now

So, this patch does the following:

 - Assign PCI address to SATA controllers (previously we didn't do this)
 - Assign disk addresses instead of PCI addresses for disks. Now, when
   building a bhyve command, we take PCI address not from the disk
   itself but from its controller
 - Assign addresses at XML parsing time using the
   assignAddressesCallback. This is done mainly for being able to
   verify address allocation via xml2xml tests
 - Adjust existing bhyvexml2{xml,argv} tests to chase the new
   address allocation

This patch is largely based on work of Fabian Freyer.

We have couple of functions that operate over NULL terminated
lits of strings. However, our naming sucks:

virStringJoin
virStringFreeList
virStringFreeListCount
virStringArrayHasString
virStringGetFirstWithPrefix

We can do better:

virStringListJoin
virStringListFree
virStringListFreeCount
virStringListHasString
virStringListGetFirstWithPrefix
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Use 'goto cleanup'-style error handling instead of explicitly
freeing variables in every error path.

Change the virDomainChrDef to use a pointer to 'source' and allocate
that pointer during virDomainChrDefNew.

This has tremendous "fallout" in the rest of the code which mainly
has to change source.$field to source->$field.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This function for some weird reason returns integer instead of
virDomainNetType type. It is important to return the correct type
so that we know what values we can expect.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The value is never negative thus there's no need to store it in a signed
type.

Make bhyveload respect boot order as specified by os.boot section of the
domain XML or by "boot order" for specific devices. As bhyve does not
support a real boot order specification right now, it's just about
choosing a single device to boot from.

Bhyve as of r279225 (FreeBSD -CURRENT) or r284894 (FreeBSD 10-STABLE)
supports using UTC time offset via the '-u' argument to bhyve(8). By
default it's still using localtime.

Make the bhyve driver use UTC clock if it's requested by specifying
<clock offset='utc'> in domain XML and if the bhyve(8) binary supports
the '-u' flag.

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.

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.

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

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.

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

Replaces
virDeviceAddressPCIMulti
virDomainFeatureState
virDomainIoEventFd
virDomainVirtioEventIdx
virDomainDiskCopyOnRead
virDomainMemDump
virDomainPCIRombarMode
virDomainGraphicsSpicePlaybackCompression

bhyveBuildNetArgStr() calls virNetDevTapCreateInBridgePort() and
passes tapfd = NULL, but tapfdSize = 1. That is wrong, because
if virNetDevTapCreateInBridgePort() crashes after successfully
creating a TAP device, it'll jump to 'error' label, that
loops over tapfd and calls VIR_FORCE_CLOSE:

   for (i = 0; i < tapfdSize && tapfd[i] >= 0; i++)

In that case we get a segfault.

As the bhyve code doesn't use tapfd, pass NULL and set tapfdSize to 0.

Automatically allocate PCI addresses for devices instead
of hardcoding them in the driver code. The current
allocation schema is to dedicate an entire slot for each devices.

Also, allow having arbitrary number of devices.

* 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.

nmdm is a FreeBSD driver which allows to create a pair of tty
devices one of which is passed to the guest and second is used
by the client.

This patch adds new 'nmdm' character device type. Its definition
looks this way:

<serial type='nmdm'>
  <source master='/dev/nmdm0A' slave='/dev/nmdm0B'/>
</serial>

Master is passed to the hypervisior and slave is used for client
connection.

Also implement domainOpenConsole() for bhyve driver based on that.

A continuation of the migration of disk details to virstoragefile.
This patch moves a single enum, but converting the name has quite
a bit of fallout.

* src/conf/domain_conf.h (virDomainDiskType): Move...
* src/util/virstoragefile.h (virStorageType): ...and rename.
* src/bhyve/bhyve_command.c (bhyveBuildDiskArgStr)
(virBhyveProcessBuildLoadCmd): Update clients.
* src/conf/domain_conf.c (virDomainDiskSourceDefParse)
(virDomainDiskDefParseXML, virDomainDiskSourceDefFormatInternal)
(virDomainDiskDefFormat, virDomainDiskGetActualType)
(virDomainDiskDefForeachPath, virDomainDiskSourceIsBlockType):
Likewise.
* src/conf/snapshot_conf.h (_virDomainSnapshotDiskDef): Likewise.
* src/conf/snapshot_conf.c (virDomainSnapshotDiskDefParseXML)
(virDomainSnapshotAlignDisks, virDomainSnapshotDiskDefFormat):
Likewise.
* src/esx/esx_driver.c (esxAutodetectSCSIControllerModel)
(esxDomainDefineXML): Likewise.
* src/locking/domain_lock.c (virDomainLockManagerAddDisk):
Likewise.
* src/lxc/lxc_controller.c
(virLXCControllerSetupLoopDeviceDisk)
(virLXCControllerSetupNBDDeviceDisk)
(virLXCControllerSetupLoopDevices, virLXCControllerSetupDisk):
Likewise.
* src/parallels/parallels_driver.c (parallelsGetHddInfo):
Likewise.
* src/phyp/phyp_driver.c (phypDiskType): Likewise.
* src/qemu/qemu_command.c (qemuGetDriveSourceString)
(qemuDomainDiskGetSourceString, qemuBuildDriveStr)
(qemuBuildCommandLine, qemuParseCommandLineDisk)
(qemuParseCommandLine): Likewise.
* src/qemu/qemu_conf.c (qemuCheckSharedDevice)
(qemuTranslateDiskSourcePool)
(qemuTranslateSnapshotDiskSourcePool): Likewise.
* src/qemu/qemu_domain.c (qemuDomainDeviceDefPostParse)
(qemuDomainDetermineDiskChain): Likewise.
* src/qemu/qemu_driver.c (qemuDomainGetBlockInfo)
(qemuDomainSnapshotPrepareDiskExternalBackingInactive)
(qemuDomainSnapshotPrepareDiskExternalBackingActive)
(qemuDomainSnapshotPrepareDiskExternalOverlayActive)
(qemuDomainSnapshotPrepareDiskExternalOverlayInactive)
(qemuDomainSnapshotPrepareDiskInternal)
(qemuDomainSnapshotPrepare)
(qemuDomainSnapshotCreateSingleDiskActive): Likewise.
* src/qemu/qemu_hotplug.c (qemuDomainChangeEjectableMedia):
Likewise.
* src/qemu/qemu_migration.c (qemuMigrationIsSafe): Likewise.
* src/security/security_apparmor.c
(AppArmorRestoreSecurityImageLabel)
(AppArmorSetSecurityImageLabel): Likewise.
* src/security/security_dac.c (virSecurityDACSetSecurityImageLabel)
(virSecurityDACRestoreSecurityImageLabelInt)
(virSecurityDACSetSecurityAllLabel): Likewise.
* src/security/security_selinux.c
(virSecuritySELinuxRestoreSecurityImageLabelInt)
(virSecuritySELinuxSetSecurityImageLabel)
(virSecuritySELinuxSetSecurityAllLabel): Likewise.
* src/storage/storage_backend.c (virStorageFileBackendForType):
Likewise.
* src/storage/storage_backend_fs.c (virStorageFileBackendFile)
(virStorageFileBackendBlock): Likewise.
* src/storage/storage_backend_gluster.c
(virStorageFileBackendGluster): Likewise.
* src/vbox/vbox_tmpl.c (vboxDomainGetXMLDesc, vboxAttachDrives)
(vboxDomainAttachDeviceImpl, vboxDomainDetachDevice): Likewise.
* src/vmware/vmware_conf.c (vmwareVmxPath): Likewise.
* src/vmx/vmx.c (virVMXParseDisk, virVMXFormatDisk)
(virVMXFormatFloppy): Likewise.
* src/xenxs/xen_sxpr.c (xenParseSxprDisks, xenParseSxpr)
(xenFormatSxprDisk): Likewise.
* src/xenxs/xen_xm.c (xenParseXM, xenFormatXMDisk): Likewise.
* tests/securityselinuxlabeltest.c (testSELinuxLoadDef):
Likewise.
* src/libvirt_private.syms (domain_conf.h): Move symbols...
(virstoragefile.h): ...as appropriate.
Signed-off-by: NEric Blake <eblake@redhat.com>

To ease mocking for bhyve unit tests move virBhyveTapGetRealDeviceName()
out of bhyve_command.c to virnetdevtap and rename it to
virNetDevTapGetRealDeviceName().

We use virBhyveTapGetRealDeviceName() to map network interface name
to a real device path, trying to open possible devices and getting
names by ioctl.

Make it skip devices that fail to open with EBUSY because they're
most likely already used by other VMs.

Part of a series of cleanups to use new accessor methods.

* src/bhyve/bhyve_command.c (bhyveBuildDiskArgStr)
(virBhyveProcessBuildLoadCmd): Use accessors.
Signed-off-by: NEric Blake <eblake@redhat.com>

Add support for MAC address configuration on network bridge
interface.

Any source file which calls the logging APIs now needs
to have a VIR_LOG_INIT("source.name") declaration at
the start of the file. This provides a static variable
of the virLogSource type.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Addition of the hostbridge device was mistakenly placed to
bhyveBuildNetArgStr(). This could result in hostbridge device not being
added to the commandline if there are no network devices specified, but
hostbridge device should be added unconditionally.

Fix by placing it to virBhyveProcessBuildBhyveCmd().

Some of these are leftovers from renaming the files, others
are just typos.

Also introduce an ugly awk script to enforce this.

At this point it has a limited functionality and is highly
experimental. Supported domain operations are:

  * define
  * start
  * destroy
  * dumpxml
  * dominfo

It's only possible to have only one disk device and only one
network, which should be of type bridge.