Add sections describing usage of the virtio-console device
and about block I/O tuning.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Report error in case when incorrect index is specified for
the ISA controller.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve supports virtio-console devices using the following syntax:
-s 2:0,virtio-console,org.qemu.guest_agent.0=/path/to/unix/socket,other.port=/other/socket,...
There are two details about that to consider.
The first one is that only up to 16 ports per console is supported. This
is different from the default (31), so update the code to manually add
the virtio-serial controllers with 16 ports. For the existing
controllers, make sure to set max ports to 16 or error out if ports
count greater than 16 was specified.
The second one is that bhyve does not clean up UNIX sockets for these
devices. So update virBhyveProcessStop() to remove leftover sockets.
Not adding capabilities probing as the virtio-console device is
available on all supported FreeBSD versions and on all supported arches.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently, there are two (at least) issues in virBhyveProcessStop().
Before going into details, a quick overview of the bhyve shutdown
process. It is a two stage process: first, the main bhyve
process gets destroyed (either via an external command or within the
guest), then the resources need to be cleaned up using the bhyvectl(8)
tool.
The first issue is that if virCommandRun() for bhyvectl(8) fails,
virBhyveProcessStop() jumps to the 'cleanup' label and misses cleaning
of some resources.
The second issue is more serious. Currently, monitor is closed only
after running of the bhyvectl(8) command. That means that the monitor
could catch the domain destroy event and try to run
virBhyveProcessStop() on the same domain again, resulting in trying
to release already released resources, such as the monitor itself.
Address by:
* Making virCommandRun() on bhyvectl(8) non-critical. Even if it
fails, we try to clean up all resources. We consider the function
failed (return value 1) though.
* Close monitor before running bhyvectl(8)
Additionally, do not verify that virBhyveProcessBuildDestroyCmd()
returns non-NULL, there could be only allocation errors.
And with 'glib' they result in an abort() so no need
to worry about those.
Reported-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
FreeBSD 15.x updated posix_fallocate() to return EOPNOTSUPP
instead of EINVAL when the operation is not supported.
Quoting posix_fallocate(2):
Previous versions of posix_fallocate used EINVAL to indicate that the
operation is not supported by the file system, as specified in IEEE Std
1003.1 (“POSIX.1”) Base Specifications, Issue 7. IEEE Std 1003.1
(“POSIX.1”) Base Specifications, Issue 8 switched to requiring EOPNOTSUPP
for this error case. ZFS adopted the latter convention in FreeBSD 15.0,
and the remaining filesystems in base adopted it in FreeBSD 15.1.
Update safezero_posix_fallocate() to handle this return value
along with EINVAL to fix the waterfall down to safezero_slow()
for filesystems that do not support that.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add a FreeBSD implementation of the virArpTableGet() function.
Update the bhyve driver's bhyveDomainInterfaceAddresses()
to use it for the VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP
source type.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
FreeBSD supports resource limiting with the rctl(4) framework.
It supports various resource types, including I/O resources.
It allows to limit resources for users, processes, login classes,
and jails.
To apply blkiotune limits set limits for the bhyve process.
I/O related resources supported by rctl(4) are:
readbps filesystem reads, in bytes per second
writebps filesystem writes, in bytes per second
readiops filesystem reads, in operations per second
writeiops filesystem writes, in operations per second
Thus, the actual commands look like:
rctl -a process:$bhyvepid:writebps:throttle=10000000
rctl -a process:$bhyvepid:readbps:throttle=10000000
rctl -a process:$bhyvepid:writeiops:throttle=20000
rctl -a process:$bhyvepid:readiops:throttle=20000
This is different from the current blkiotune modeling in libvirt as
it requires specific device to apply limits to. To adapt this model
to per-domain I/O limits, update domain schema to specify "*" as a
device name.
The rctl(8) may be not available or not enabled, so add a capability
check for that.
Per process rules get removed when the process disappears, so no special
clean up is necessary.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The current qemuDomainGetHostnameLease() implementation
jumps to the "endjob" label when it finds hostname.
As the label is defined after "ret = 0",
qemuDomainGetHostnameLease() returns -1 in this case.
That works because in qemuDomainGetHostname() it is used like that:
...
if (qemuDomainGetHostnameLease(vm, &hostname) < 0)
goto cleanup;
...
cleanup:
virDomainObjEndAPI(&vm);
return hostname;
}
So it works, but it looks confusing. To make more consistent,
use 'break' in qemuDomainGetHostnameLease() when the hostname
is found, so it returns 0 in this case.
Fixes: a4a5827c9f
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Implement the domainInterfaceAddresses and domainGetHostname APIs.
These APIs could use multiple sources of information, though
for bhyve only the 'lease' source is supported.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Implement virHostCPUGetOnlineBitmap() for FreeBSD. As FreeBSD
supports neither plugging nor taking CPUs offline,
all CPUs are always online.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend virHostCPUGetInfo() to report more data on FreeBSD, such as:
- NUMA domain count
- CPU core count
- CPU threads per core count
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In the "virtio-scsi" section: "12:0.0" -> "12.0.0".
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve supports NUMA domains configuration using the '-n'
command line argument:
-n id,size,cpus[,domain_policy]
Here, "id" is a numeric NUMA domain id, "size" is the total VM
memory size with units format similar to the "-m" switch,
"cpus" is a cpuset, and "domain_policy" is an optional
domainset(9) memory allocation policy. The "domain_policy"
is currently not used by the libvirt driver.
This argument is repeated for every NUMA domain to be configured, e.g.:
bhyve \
...
-n id=0,size=107,cpus=0-3
-n id=1,size=107,cpus=4-7
To support that:
* Add a corresponding capability; it is considered supported
if the bhyve binary has the '-n' command line switch.
* Generate command line arguments for NUMA from
<cpu><numa>..</numa></cpu> domain configuration.
Additionally, validate that:
* NUMA domains can be only configured with the UEFI loaders.
* No more than 8 domains configured per VM as limited by bhyve.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement domainGetVcpuPinInfo for querying vcpu pinning information.
Also, implement a couple of other APIs this one depends on:
domainGetVcpusFlags and domainGetMaxVcpus.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve supports vcpu pinning using the `-p vcpu:hostcpu`
argument. This argument can be specified multiple times for the same
vcpu to pin it to multiple hostcpu's.
Bhyve currently does not allow to change vcpu pinning configuration for
the VM that is already running.
Use this to support domain's vcpupin configuration such as:
<cputune>
<vcpupin vcpu="0" cpuset="1,2,3"/>
</cputune>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve on arm64 does not have the bhyveload(8) tool.
That means that it cannot be used as a default if the loader is not
configured for the domain.
To prevent users from getting unusable configurations, handle loader
configuration on arm64 like that:
- if loader is specified in the domain XML, just use it
- if not specified, try to check whether the default uboot loader
is available on the system. In case it is, set is as the loader,
otherwise fail with the error.
Additionally, the loader could be configured in bhyve.conf.
By default, it uses the loader installed by the
sysutils/u-boot-bhyve-arm64 port or a corresponding package.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve used the '-A' flag to enable ACPI until it was deprecated
by commit:
https://cgit.freebsd.org/src/commit/?id=6a0e7f908802b86ca5d1c0b3c404b8391d0f626e
With that, ACPI tables are always generated. As this change is
relatively new and there are likely systems that have bhyve(8) that
requires using the '-A' flag, add a capability probing for that, and
use this flag if it's supported.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
According to 9fa3a8ab6f,
macOS insists on passing 3 arguments for xdrproc_t.
Passing 3 arguments was a good common ground, but since
recently[1] FreeBSD only accepts 2 arguments.
Add a meson.build check whether 3 arguments are accepted,
and add macros which passes either 2 or 3 arguments to
xdrproc_t based on the result of this check.
1: https://cgit.freebsd.org/src/commit/?id=ac5a19ec6989675c8ec6c3ca245dba243d1a6416
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The "virt" board in QEMU has a "virtualization" option
that is documented like this:
virtualization
Set ``on``/``off`` to enable/disable emulating a guest CPU which implements the
Arm Virtualization Extensions. The default is ``off``.
(from system/arm/virt.rst)
According to the documentation, the "virtualiaztion" option
is related to the "gic-version" option. Specifically, gic version=4
requires virtualization to be enabled. And gic version=max will use
version=4 when virtualization is enabled, and 3 when not.
Libvirt does not currently model neither gic version "4" nor "max"
though.
It is also documented for the "vexpress-a(9|15)" boards, where it is
also disabled by default:
- QEMU defaults to providing a CPU which does not provide either
TrustZone or the Virtualization Extensions: if you want these you
must enable them with ``-machine secure=on`` and ``-machine
virtualization=on``
(system/arm/vexpress.rst).
On the command line it looks like:
qemu-system-aarch64 -machine type=virt,virtualization=on ..
Model it using the "virtualization" element in the "features" section:
<features>
<virtualization/>
</features>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, bhyve does not support UTC clock offset on ARM64.
However, when <clock offset= > is not specified in the domain XML,
UTC offset is used by default. That results in an incorrect
configuration for the bhyve ARM64 guests by default.
Workaround is to extend bhyveDomainDefPostParse() to fall back
to the LOCALTIME clock offset when UTC clock offset is not
supported by bhyve.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, domain capabilities reporting is limited to X86.
Enable it for ARM as well.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Just like consoles, bootloader is handled differently on arm64.
It also does not used the LPC bus, and is configured with:
-o bootrom=/usr/local/share/u-boot/u-boot-bhyve-arm64/u-boot.bin
Additionally, fill firmware inforamtion only for amd64.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These arguments control IA32 HLT and PAUSE instructions, so
there are supported only on amd64.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Console device handling in bhyve is different for amd64 and arm64.
On amd64, it's configured as an LPC device, and multiple consoles are
supported.
On arm64, only a single console can be configured, and the syntax is
different:
-o console=/dev/nmdmguest0A
Update the bhyve command generation accordingly.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, guest capabilities have VIR_ARCH_X86_64 hard-coded
for supported guest. As bhyve supports amd64 and arm64 hosts,
and guests' arch must match host's arch, reporting VIR_ARCH_X86_64
for arm64 is wrong.
Set supported guest arch to the same value as the host arch.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve supports virtio-scsi devices using the following syntax:
bhyve ... -s N,virtio-scsi,/dev/cam/ctl[pp.vp][,scsi-device-options]
Where /dev/cam/ctl is a ctl(4) device path.
The optional "scsi-device-options" include "iid" (Initiator ID)
and "bootindex", which are currently not used by libvirt.
Model this device using:
<disk type='ctl'>
<source dev='/dev/cam/ctl'/>
<target dev='sda' bus='scsi'/>
</disk>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
CTL stands for CAM Target Layer, and CAM stands for
Common Access Method Storage subsystem, and is available
on FreeBSD.
Quoting the ctl(4) manual page:
The ctl subsystem provides SCSI target devices emulation. It supports
features such as:
• Disk, CD-ROM and processor device emulation
• Tagged queueing
• SCSI task attribute support (ordered, head of queue, simple tags)
• SCSI implicit command ordering support
• Full task management support (abort, query, reset, etc.)
• Support for multiple ports, initiators, targets and backing stores
• Support for VMWare VAAI and Microsoft ODX offload (COMPARE AND WRITE,
XCOPY, POPULATE TOKEN/WRITE USING TOKEN, WRITE SAME and UNMAP)
• Persistent reservation support
• Extensive VPD/mode/log pages support
• Featured error reporting, error injection and basic SMART support
• High Availability clustering support with ALUA
• All I/O handled in-kernel, no userland context switch overhead
This is a preparation for implementing virtio-scsi support for the bhyve
driver.
Co-authored-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, to probe PCI devices, for each device libvirt
calls "bhyve -s 0,<device_type>" and parses the error message to check
if this specific device is supported.
For quite some time, bhyve reports the list of devices using:
bhyve -s help
where it prints all supported devices, one device per line.
Update the code to use this command:
* It is more accurate as we don't need to rely on the error message
parsing.
* It's faster as we get all the devices in one run instead of
running bhyve for every device type.
* The code is simpler.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve supports SLIRP networking using the following syntax:
-s 12:0,e1000,slirp,mac=<macaddr>,open
Where "e1000" is a NIC model, "slirp" is the SLIRP backend and "open"
specifies open mode where external network is available to the guest.
The "open" mode is a recent addition in FreeBSD -CURRENT.
Unfortunately, bhyve does not provide a way to probe whether
the open mode is supported, so users will have to make sure
it's supported on their own.
For the reference, without the "open" mode, the guest will have no
outside network connectivity. To make this mode useful,
it is possible to configure forwarding from the host to the guest,
but it is not covered by this patch.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Document the new VNC's 'wait' attribute in formatdomain.rst and
drvbhyve.rst.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve supports the 'wait' option for the VNC device configuration.
When enabled, VM boots only upon a VNC connection.
Sample device configuration looks like this:
-s 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Introduce an optional 'wait' attribute for 'VNC'.
When set to 'yes', VM should only boot upon the initiation of a VNC
connection.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Do not allow to configure queues and queue size for non-NVMe disks.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor bhyveDomainDeviceDefValidate() to use switch/case instead of
series of ifs which makes it easier to follow.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
bhyve supports queue configuration for the NVMe disks:
maxq Max number of queues.
qsz Max elements in each queue.
Map that to the disk driver's "queues" and "queue_size" attributes
respectfully, so:
<driver name='file' type='raw' queues='2' queue_size='256'/>
results in:
-s N:0,nvme,/tmp/disk.img,maxq=2,qsz=256
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, virDomainDiskDefValidate() allows to configure disks' number
of queues and queue size for virtio disks only. However, the bhyve
driver allows to configure these for the NVMe disks, so make this
check driver-specific.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a section with guest-specific notes. Start with LPC slot address
information for the Windows guests.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When linking to the bhyve(8) manual page, do not set manpath
to a specific FreeBSD version so the latest actual version
is displayed.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After executing the bhyve binary, it might happen that it fails very
early due to configuration issues (missing/inaccessible files, incorrect
custom args), bugs, etc. In this case it'll look like the domain has
started normally, but quickly turned off.
Improve that by waiting for the domain's vmm entity to appear in
/dev/vmm.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve supports specifying disk rotation rate using the nmrr attribute,
e.g.:
-s 3:0,ahci,hd:/data/img/freebsd.img,nmrr=1
Where 1 means the SSD, 0 (default) means do not report, and other values
specify the actual RPM.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For domains using NVMe disks make sure that the bhyve binary supports
that by checking capabilities.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As bhyve does not have explicit notion of controllers, and for NVMe
devices it allows to specify one a single source for for a given PCI
address, it effectively means that there could be only one device per
controller.
Update validation code to check this case.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
NVMe devices in bhyve are modeled this way:
-s $pciaddr,nvme,devpath[,opts]
devpath can be a path to the image or the block device. It also can be
"ram=size_in_MiB", but this is not covered by this series.
There could be only a single device per PCI address.
Optional configuration options (such as max number of queues, concurrent
I/O requests, etc) are also not covered by this series.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Current implementation uses a single command to flush the old rules and
create new ones. This is not optimal because if flush fails for some
non-critical reasons (e.g. because the anchor didn't previously exist),
it will block rules creation and network start.
Split this command into two: one for flush, and one for rules creation.
Also, don't fail if the flush command fails.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Laine Stump <laine@redhat.com>
When the virBhyveProcessStart() fails early, make sure to execute
the "stopped" and "release" hooks.
Spotted while running TCK hooks tests against the bhyve driver.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When a domain configured with "<os firmware='efi'/>", autofill not only
loader/firmware configuration, but also nvram.
This also fixes the `scripts/domain/405-ovmf-nvram-efi.t` test in
libvirt-tck for bhyve.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently documents only FreeBSD/pf specific configuration.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add BSD-specific platform flavor of the bridge driver which will be used
as a base for Packet Filter (pf) based NAT networking implementation.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement domainBlockStats for the bhyve driver. Only the read/write
operations counts are reported as FreeBSD apparently doesn't support
accumulative bytes read or written, though real-time data is available
via rctl(8). There's also no information about the errors.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, bhyve does not support neither memory ballooning nor
reporting guest memory usage. So the following information can be
obtained:
- RSS of the running process
- Memory available to the guest (that is, guest total memory)
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virNetDevTapInterfaceStats() function already works on FreeBSD, so
it's just a matter of wrapping that for domainInterfaceStats.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement NAT networking support based on the Packet Filter (pf)
firewall in FreeBSD. At this point, the implementation is very basic.
It creates:
- Essential NAT translation rules
- Basic forwarding rules
Implementation uses pf's anchor feature to group rules. All rules live
in the "libvirt" anchor and every libvirt's network has its own
sub-anchor.
Currently there are some assumptions and limitations:
- We assume that a user has created the "libvirt" (nat-)anchors. As
they cannot be created on fly, it's better not to touch global pf
configuration and let the user do the changes. If the user doesn't
have these anchors configured, the rules will still be created in
sub-anchors, but will not be effective until these anchors are
activated. Should we check if these anchors are not active to
give some runtime warning?
- Currently, rule reloading is not smart: it always deletes rules,
flushes rules and re-creates that. It would be better to do that
more gracefully.
- IPv6 configurations are currently not supported
- For NAT, pf requires explicit IP address or an interface to NAT to.
We try to obtain that from the network XML definition, and if it's
not specified, we try to determine interface corresponding to the
default route.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
The bhyveload(8) command does not have a native non-interactive mode.
It means that in case of errors, e.g. invalid boot media, it
just drops into a loader prompt and waits for user input. This behaviour
makes it tricky for users to understand what's going on.
To address that, run it with the timeout(1) tool which sends SIGTERM
after a certain timeout, and then optionally sends SIGKILL if the
command keeps hanging.
These timeout values could be configured in the bhyve.conf. Setting
timeout to 0 mean that bhyveload(8) will be executed directly, without
timeout(1).
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, virBhyveProcessStop() uses the virDomainDeleteConfig()
helper to clean up domain status. It passes BHYVE_STATE_DIR as
a configuration dir and NULL as autostart dir, so the helper does its
job, even though it has a different purpose. However, the issue is that
it also resets the autostart (and autostartOnce) property.
This results in a situation that when a persistent domain with autostart
enabled gets destroyed, its autostart state is reported as disabled,
which is not correct.
To fix that, implement the bhyveProcessRemoveDomainStatus() which
removes the status file without side effects on the virDomainObj object.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com
Use the same error messages for serial devices validation which are
already used in bhyve_domain.c
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Extend bhyveDomainDeviceDefValidate() to check that:
- only 'nmdm' or 'tcp' serial devices are used,
- serial device count is not more than supported,
- only listening raw TCP sockets are used.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Recent versions of bhyve support 4 com ports instead of just 2. Thus,
allow to use 4 console devices.
Also, there was a bug previously because the condition was
"if (chr->target.port > 2)", but as target.port start
with 0 and "com" ports start with 1, this condition allows com3 to be
used.
As bhyve supports 4 com ports already long enough, and all supported
FreeBSD versions include this capability, do not introduce driver
capability for that.
Add a couple of tests for that:
- A domain that uses 4 serials, 2 of type 'nmdm'
and the other 2 of type 'tcp'
- A domain that uses unsupported port, such as target.port=4 which
translates into com5.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In addition to the nmdm consoles, bhyve also supports a tcp console.
It's configured with:
.. -l com1,tcp=127.0.0.1:12345
Then a user could connect to the guest console port 0 by making a tcp
connection to the host's 127.0.0.1:12345.
In the domain XML this configuration is represented as:
<serial type='tcp'>
<source mode='bind' host='127.0.0.1' service='12345'/>
<target type='serial' port='0'/>
</serial>
Also, update domain capabilities to include the TCP console support.
Unfortunately, there's no way to detect that from the bhyve binary
before trying to start a VM, so there's no capability probing for this
feature.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Extend domain capabilities with information about the supported console
device types.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend domain capabilities with information about the supported console
device types.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend domain capabilities to report the NMDM console support.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, domain capabilities do not include information about the
supported console device types. While most of the drivers support
'pty' console type, it's not the case for bhyve. Without this
information, management software cannot always generate compatible
domain configuration.
To address that, extend domain capabilities like that:
<devices>
...
<console supported='yes'>
<enum name='type'>
<value>pty</value>
<value>type2</value>
...
</enum>
</console>
...
</devices>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a couple of examples of the explicit NVRAM configuration, and also
an automatic configuration, along with `<os firmware="efi">`.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add the bhyveDomainDefValidate() validation which currently checks
whether the requested NVRAM is supported.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend bhyveFirmwareFillDomain() so that when we find the default edk2
firmware, also look for its matching template file, and use it as a
nvramTemplate if found.
Extend bhyvexml2argvtest to verify various NVRAM configurations.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, bhyve bootrom specification looks like this:
bhyve ... -l bootrom,/path/to/firmware.fd
In addition to that, it supports specifying the VARS files using:
-l bootrom,/path/to/firmware.fd,/path/to/my_domain_VARS.fd
Update virBhyveProcessBuildBhyveCmd() to include the VARS file if NVRAM
is specified in the domain XML.
Additionally, support copying this file from the specified template. To
do that, introduce the bhyveProcessPrepareHost() and related helpers.
They are currently not doing anything but NVRAM preparations, but should
be useful for other host-side related tasks in the future.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As a preparation for NVRAM support, introduce nvramDir configuration
item.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As virDomainNet* functions were converted to use const virDomainDef
pointers, update bhyveBuildNetArgStr() as well, like it was before it was
changed in e1e40b5035.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some virDomainNet* functions use virDomainDef pointers even though they
don't modify the domain config, so switch to const pointers there.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
- Document the virtio random number generator device support
- While here, remove mention of the specific FreeBSD version such as
10-STABLE, and just refer to the latest supported release.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Roman Bogorodskiy
