Laine Stump wrote:
> This patch series enables libvirt to use nftables rules rather than
> iptables *when setting up virtual networks* (it does *not* add
> nftables support to the nwfilter driver). It accomplishes this by
> abstracting several iptables functions (from viriptables.[ch] called
> b
Laine Stump wrote:
> On 6/10/24 2:54 PM, Roman Bogorodskiy wrote:
> >Laine Stump wrote:
> >
> > > This patch series enables libvirt to use nftables rules rather than
> > > iptables *when setting up virtual networks* (it does *not* add
> > > nf
Laine Stump wrote:
> On 6/12/24 2:32 PM, Roman Bogorodskiy wrote:
> >Laine Stump wrote:
> >
> > > On 6/10/24 2:54 PM, Roman Bogorodskiy wrote:
> > > > Laine Stump wrote:
> > > >
> > > > > This patch series enables lib
Andrea Bolognani wrote:
> On Wed, Jun 12, 2024 at 07:31:51PM GMT, Laine Stump wrote:
> > On 6/12/24 2:32 PM, Roman Bogorodskiy wrote:
> > > I'm using it with the following network configuration:
> > >
> > > virsh # net-dumpxml default
> > >
Daniel P. Berrangé wrote:
> There are two scenarios identified after the recent firewall backend
> selection was introduced, which result in libvirtd failing to startup
> due to an inability to find either iptables/nftables
>
> - On Linux if running unprivileged with $PATH lacking the dir
>
Andrea Bolognani wrote:
> On Thu, Jun 13, 2024 at 06:24:00PM GMT, Roman Bogorodskiy wrote:
> > Laine Stump wrote:
> > > On 6/12/24 2:32 PM, Roman Bogorodskiy wrote:
> > > > So basically all the mechanics like creating tap devices, bridges,
> > > > se
Andrea Bolognani wrote:
> On Thu, Jun 13, 2024 at 07:45:52PM GMT, Roman Bogorodskiy wrote:
> > > My configuration is the same (obtained from copying the file shipped
> > > as /usr/local/share/examples/libvirt/networks/default.xml, which is
> > > identical to src
Alexander Shursha wrote:
> Sponsored by: Future Crew, LLC
> Signed-off-by: Alexander Shursha
> ---
> src/bhyve/bhyve_command.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c
> index bc287307c8..16986c9d53
Alexander Shursha wrote:
> Linux gets the list via sysfs. FreeBSD can get the list through
> ioctl
>
> Sponsored by: Future Crew, LLC
> Signed-off-by: Alexander Shursha
> ---
> src/bhyve/bhyve_capabilities.c | 2 +-
> src/conf/node_device_conf.c | 2 +-
> src/node_device/no
l
> b/tests/domaincapsdata/bhyve_uefi.x86_64.xml
> index 69fff197a7..f76cf91acb 100644
> --- a/tests/domaincapsdata/bhyve_uefi.x86_64.xml
> +++ b/tests/domaincapsdata/bhyve_uefi.x86_64.xml
> @@ -35,7 +35,8 @@
>
>
>
> -
> +
> +
>
>
>
> --
> 2.46.1
Reviewed-by: Roman Bogorodskiy
Michal Prívozník wrote:
> On 4/2/25 19:24, Roman Bogorodskiy wrote:
> > The 'plain' optimization type also triggers the clang stack frame size
> > issues, so increase limit for it as well.
> >
> > Signed-off-by: Roman Bogorodskiy
> > ---
>
Some virDomainNet* functions use virDomainDef pointers even though they
don't modify the domain config, so switch to const pointers there.
This also allows to use the const pointer again in
bhyveBuildNetArgStr() after it was changed in e1e40b5035.
Signed-off-by: Roman Bogorodskiy
---
src/
Bhyve supports the Virtio RNG interface. It's always using the
/dev/random device and doesn't have any configuration options.
Thus, in XML it's represented as:
So extend the bhyve driver to support that and add a set of tests for
this feature.
Signed-off-by: Ro
Roman Bogorodskiy (3):
bhyve: support random number generator device
bhyve: argv2xml: support virtio-rnd devices
bhyve: extend RNG device validation
src/bhyve/bhyve_capabilities.c| 15
src/bhyve/bhyve_capabilities.h| 2 +
src/bhyve
Add a bunch of device def validation to catch unsupported RNG device
configurations early.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_domain.c | 21 +++
...yvexml2argv-virtio-rnd-backend-builtin.xml | 26 +++
...io-rnd-backend-random
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_parse_command.c | 29 +++
.../bhyveargv2xml-virtio-rnd.args | 8 +
.../bhyveargv2xml-virtio-rnd.xml | 20 +
tests/bhyveargv2xmltest.c | 1 +
4 files
Alexander Shursha wrote:
> The current virpci code uses the Linux-specific sysfs subsystem, which makes
> it impossible to use on other Unix-like systems. The libpciaccess library
> provides a cross-platform API for accessing the PCI bus. Employ it to make
> the code portable.
>
> This makes li
v2xmldata/bhyveargv2xml-passthru.xml
> @@ -0,0 +1,22 @@
> +
> + bhyve
> + c7a5fdbd-edaf-9455-926a-d65c16db1809
> + 219136
> + 219136
> + 1
> +
> +hvm
> +
> +
> + destroy
> + destroy
> + destroy
> +
> +
> +
> +
> +
> + function='0x0'/>
> +
> +
> +
> diff --git a/tests/bhyveargv2xmltest.c b/tests/bhyveargv2xmltest.c
> index 92189a2e58..f61235e04f 100644
> --- a/tests/bhyveargv2xmltest.c
> +++ b/tests/bhyveargv2xmltest.c
> @@ -161,6 +161,7 @@ mymain(void)
> DO_TEST("virtio-blk");
> DO_TEST("virtio-net");
> DO_TEST("e1000");
> +DO_TEST("passthru");
> DO_TEST_WARN("virtio-net2");
> DO_TEST_WARN("virtio-net3");
> DO_TEST_WARN("virtio-net4");
> --
> 2.46.1
Reviewed-by: Roman Bogorodskiy
e/bhyve_command.c
> +++ b/src/bhyve/bhyve_command.c
> @@ -2,6 +2,7 @@
> * bhyve_command.c: bhyve command generation
> *
> * Copyright (C) 2014 Roman Bogorodskiy
> + * Copyright (C) 2024-2025 Future Crew, LLC
> *
> * This library is free software; you can redistribute
Roman Bogorodskiy wrote:
> I think I'll update the domain builder code to use either sata or ide,
> based on what is available as reported by domain capabilities. At least
> when the bus is not explicitly requested by the test.
FWIW, I was able to resolve this and a couple
from 192.168.122.154: icmp_seq=1 ttl=64 time=0.209 ms
64 bytes from 192.168.122.92: icmp_seq=1 ttl=64 time=0.235 ms (DUP!)
^C
--- 192.168.122.255 ping statistics ---
2 packets transmitted, 2 packets received, +2 duplicates, 0.0% packet
loss
round-trip min/avg/max/stddev = 0.199/0.218/0.235/0.014 ms
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
---
po/POTFILES | 1 +
src/network/bridge_driver_bsd.c | 101
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_capabilities.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
index 37ae5d2872..36a092a819 100644
--- a/src/bhyve/bhyve_capabilities.c
+++ b/src/bhyve
Hi,
I'd like to test the bhyve driver using libvirt-tck, which seems to be
very useful both from the continuous integration perspective,
and making the bhyve driver closer to other drivers to improve
integration with other tooling.
As a small proof-of-concept I made just a single test
060-persist
Daniel P. Berrangé wrote:
> On Mon, Apr 14, 2025 at 02:36:11PM +0200, Roman Bogorodskiy wrote:
> > Hi,
> >
> > I'd like to test the bhyve driver using libvirt-tck, which seems to be
> > very useful both from the continuous integration perspective,
> >
Roman Bogorodskiy (2):
NEWS: bhyve: document new features
docs: drvbhyve: document virtio-rnd support
NEWS.rst | 14 ++
docs/drvbhyve.rst | 21 +++--
2 files changed, 33 insertions(+), 2 deletions(-)
--
2.49.0
- 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
---
docs/drvbhyve.rst | 21 +++--
1 file changed, 19
Document the virtio random number generator device support
and support.
Signed-off-by: Roman Bogorodskiy
---
NEWS.rst | 14 ++
1 file changed, 14 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 4f1e8ecbdf..603c373390 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -24,6 +24,20
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
---
src/conf/domain_conf.c | 10 +-
src/conf/domain_conf.h | 8
2 files changed, 9 insertions(
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
---
src/bhyve/bhyve_command.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Changes since v1:
- Split domain_conf and bhyve changes into separate commits
- Convert virDomainNetNotifyActualDevice() as well
Roman Bogorodskiy (2):
conf: use const virDomainDef pointers
bhyve: use const virDomainDef pointer in bhyveBuildNetArgStr()
src/bhyve/bhyve_command.c | 2
from the network XML definition, and if it's
not specified, we try to determine interface corresponding to the
default route.
Signed-off-by: Roman Bogorodskiy
---
meson.build | 2 +
po/POTFILES | 1 +
src/network/bridge_driver_bsd.c |
@@
> * bhyve_command.c: bhyve command generation
> *
> * Copyright (C) 2014 Roman Bogorodskiy
> + * Copyright (C) 2024-2025 Future Crew, LLC
> *
> * This library is free software; you can redistribute it and/or
> * modify it under the terms of the GNU Lesser General
Alexander Shursha wrote:
> Signed-off-by: Alexander Shursha
> ---
> src/bhyve/bhyve_parse_command.c | 60 +++
> .../bhyveargv2xml-passthru.args | 7 +++
> .../bhyveargv2xml-passthru.xml| 22 +++
> tests/bhyveargv2xmltest.c
Peter Krempa wrote:
> On Tue, Feb 25, 2025 at 19:36:24 +0100, Roman Bogorodskiy wrote:
> > Alexander Shursha wrote:
> >
> > > Signed-off-by: Alexander Shursha
> > > ---
> > > src/bhyve/bhyve_parse_command.c | 60
virDomainHostdevDefNew() has been using g_new0() for a while now. As it
calls abort() on OOM, it's not necessary to check whether
the return value is NULL.
Signed-off-by: Roman Bogorodskiy
---
src/conf/domain_conf.c | 3 +--
src/libxl/xen_common.c | 4 +---
src/libxl/xen_xl.c
Michal Prívozník wrote:
> On 4/4/25 08:46, Michal Prívozník wrote:
> > On 4/3/25 18:28, Roman Bogorodskiy wrote:
> >> Michal Prívozník wrote:
> >>
> >>> On 4/2/25 19:24, Roman Bogorodskiy wrote:
> >>>> The 'plain' optimization
Michal Privoznik via Devel wrote:
> From: Michal Privoznik
>
> After previous cleanups, all functions have their stack smaller
> than 2048 bytes and thus the workaround is no longer needed.
Thanks, now that works for me too.
Reviewed-by: Roman Bogorodskiy
> Signed-off-by: M
The 'plain' optimization type also triggers the clang stack frame size
issues, so increase limit for it as well.
Signed-off-by: Roman Bogorodskiy
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index 56823ca25b..0a402a1
for the unsupported interface type
to print the requested network type string instead of an integer to make
it more user-friendly.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_command.c | 44 ++-
src/bhyve/bhyve_process.c | 30 +++---
Roman Bogorodskiy wrote:
> FWIW, I was able to resolve this and a couple of other minor issues
> relatively simply.
>
> https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/59
Thanks for reviewing this one!
> > > On QEMU side, use of UEFI has always required manual
Daniel P. Berrangé wrote:
> > I imagine that this is a valid configuration for qemu and probably other
> > drivers, but not for bhyve, because it doesn't support direct kernel
> > boot (neither for Linux nor FreeBSD). However, I wasn't able to find
> > anything similar in the driver's capabiliti
Add the bhyveDomainDefValidate() validation which currently checks
whether the requested NVRAM is supported.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_domain.c | 43
1 file changed, 43 insertions(+)
diff --git a/src/bhyve/bhyve_domain.c b/src
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_driver.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c
index 684346952d..db7d440a97 100644
--- a/src/bhyve/bhyve_driver.c
+++ b/src
As a preparation for NVRAM support, introduce nvramDir configuration
item.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_conf.c | 4
src/bhyve/bhyve_utils.h | 2 ++
src/bhyve/meson.build | 5 +
3 files changed, 11 insertions(+)
diff --git a/src/bhyve/bhyve_conf.c b/src/bhyve
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
---
src/bhyve/bhyve_firmware.c
Roman Bogorodskiy (5):
bhyve: conf: introduce nvramDir
bhyve: generate NVRAM bhyve arguments
bhyve: firmware: try to guess NVRAM settings
bhyve: introduce bhyveDomainDefValidate()
bhyve: support removing NVRAM on domain undefine
src/bhyve/bhyve_command.c | 8
the future.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_command.c | 8 ++-
src/bhyve/bhyve_process.c | 132 ++
src/bhyve/bhyve_process.h | 8 +++
3 files changed, 146 insertions(+), 2 deletions(-)
diff --git a/src/bhyve/bhyve_command.c b/src/bhyve
Signed-off-by: Roman Bogorodskiy
---
NEWS.rst | 8
1 file changed, 8 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index e924c08fbf..102e49373a 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -23,6 +23,14 @@ v11.4.0 (unreleased)
That option suppresses registration of pkttyagent with
Add a couple of examples of the explicit NVRAM configuration, and also
an automatic configuration, along with ``.
Signed-off-by: Roman Bogorodskiy
---
docs/drvbhyve.rst | 20
1 file changed, 20 insertions(+)
diff --git a/docs/drvbhyve.rst b/docs/drvbhyve.rst
index
From: Alexey Dokuchaev
For quite some time now FreeBSD provides its own version of the grep(1)
tool, and the GNU grep from the ports collection is available as
ggrep(1). So remove the detection code and just request ggrep.
Signed-off-by: Alexey Dokuchaev
---
build-aux/meson.build | 15 +---
Michal Prívozník wrote:
> On 5/9/25 19:11, Roman Bogorodskiy wrote:
> > Roman Bogorodskiy (5):
> > bhyve: conf: introduce nvramDir
> > bhyve: generate NVRAM bhyve arguments
> > bhyve: firmware: try to guess NVRAM settings
> > bhyve: introduce bhy
s the
test driver, so it looks like all drivers are covered by this series.
Roman Bogorodskiy (4):
domain_capabilities: add console capabilities
bhyve: capabilities: report NMDM console
qemu: capabilities: report supported console types
libxl: capabilities: report supported console types
Roman Bogorodskiy wrote:
> This series implements NAT networks support for FreeBSD using the Packet
> Filter (pf) firewall.
ping
Extend domain capabilities with information about the supported console
device types.
Signed-off-by: Roman Bogorodskiy
---
src/libxl/libxl_capabilities.c | 23 ++-
tests/domaincapsdata/libxl-xenfv.xml | 13 +
tests/domaincapsdata/libxl-xenpv.xml | 13
Extend domain capabilities with information about the supported console
device types.
Signed-off-by: Roman Bogorodskiy
Reviewed-by: Michal Privoznik
---
src/qemu/qemu_capabilities.c | 32 +++
src/qemu/qemu_capabilities.h | 3
on.
To address that, extend domain capabilities like that:
...
pty
type2
...
...
Signed-off-by: Roman Bogorodskiy
Reviewed-by: Michal Privoznik
---
src/conf/domain_capabilities.c | 12
src/conf/domain_capab
Extend domain capabilities to report the NMDM console support.
Signed-off-by: Roman Bogorodskiy
Reviewed-by: Michal Privoznik
---
src/bhyve/bhyve_capabilities.c | 5 +
tests/domaincapsdata/bhyve_basic.x86_64.xml | 5 +
tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 5
on.
To address that, extend domain capabilities like that:
...
pty
type2
...
...
Signed-off-by: Roman Bogorodskiy
---
src/conf/domain_capabilities.c | 12
src/conf/domain_capabilities.h | 8
src/conf/schemas
channels, and sometimes it's not obvious if there's
any difference between these devices' supported types.
Interestingly, formatdomain.html doesn't provide much information about
'console type'. I was able to find the only occurrence of non-pty
console, which is type='
Extend domain capabilities with information about the supported console
device types.
Signed-off-by: Roman Bogorodskiy
---
src/qemu/qemu_capabilities.c | 32 +++
src/qemu/qemu_capabilities.h | 3 ++
.../qemu_10.0.0-q35.x86_64+amdsev.xml
Extend domain capabilities to report the NMDM console support.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_capabilities.c | 5 +
tests/domaincapsdata/bhyve_basic.x86_64.xml | 5 +
tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 5 +
tests/domaincapsdata
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
---
src/bhyve/bhyve_driver.c
Use the "kern.proc.pid" sysctl and retrieve information from the
kinfo_proc struct.
Signed-off-by: Roman Bogorodskiy
---
src/util/virprocess.c | 104 +++---
1 file changed, 78 insertions(+), 26 deletions(-)
diff --git a/src/util/virprocess.c
Roman Bogorodskiy (3):
bhyve: implement domainInterfaceStats
virprocess: implement virProcessGetStatInfo() for FreeBSD
bhyve: implement domainMemoryStats
src/bhyve/bhyve_driver.c | 84 +++
src/util/virprocess.c| 104
The virNetDevTapInterfaceStats() function already works on FreeBSD, so
it's just a matter of wrapping that for domainInterfaceStats.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_driver.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/src/
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
---
src/bhyve/bhyve_driver.c
Use the "kern.proc.pid" sysctl and retrieve information from the
kinfo_proc struct.
Signed-off-by: Roman Bogorodskiy
---
src/util/virprocess.c | 104 +++---
1 file changed, 78 insertions(+), 26 deletions(-)
diff --git a/src/util/virprocess.c
it's worth the effort for now. Probably it'll make sense to implement a
FreeBSD version of virProcessGetStat() once there are more users of this
code.
Roman Bogorodskiy (4):
bhyve: implement domainInterfaceStats
virprocess: implement virProcessGetStatInfo() for FreeBSD
bhyve: implement
The virNetDevTapInterfaceStats() function already works on FreeBSD, so
it's just a matter of wrapping that for domainInterfaceStats.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_driver.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/src/
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
Signed-off-by: Roman Bogorodskiy
---
NEWS.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 7d7df72a50..184df16547 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -47,6 +47,17 @@ v11.5.0 (unreleased)
* **Improvements**
+ * Include supported console
Roman Bogorodskiy wrote:
> This series implements NAT networks support for FreeBSD using the Packet
> Filter (pf) firewall.
ping
esented as:
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
Reviewed-by
ng the 'bind' value.
Other changes: added validation to bhyve_domain.c, and unified error
messages used in bhyve_command.c and bhyve_domain.c
Roman Bogorodskiy (5):
bhyve: support serial type 'tcp'
bhyve: increase number of supported consoles to 4
docs: drvbhyve: docume
of type 'tcp'
- A domain that uses unsupported port, such as target.port=4 which
translates into com5.
Signed-off-by: Roman Bogorodskiy
Reviewed-by: Daniel P. Berrangé
---
src/bhyve/bhyve_command.c | 4 +-
.../bhyvexml2argv-4-consoles.args | 15 +
.../
Signed-off-by: Roman Bogorodskiy
Reviewed-by: Daniel P. Berrangé
---
docs/drvbhyve.rst | 19 +++
1 file changed, 19 insertions(+)
diff --git a/docs/drvbhyve.rst b/docs/drvbhyve.rst
index 7eec4a2123..0962bccef4 100644
--- a/docs/drvbhyve.rst
+++ b/docs/drvbhyve.rst
@@ -619,3
Use the same error messages for serial devices validation which are
already used in bhyve_domain.c
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_command.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c
index
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
---
src/bhyve/bhyve_domain.c | 27 ++
} else if (strstr(def->os.bootloader, "grub-bhyve") != NULL) {
return virBhyveProcessBuildGrubbhyveCmd(def, driver, devmap_file,
devicesmap_out);
diff --git a/src/bhyve/bhyve_conf.c b/src/bhyve/bhyve_conf.c
index f18b24f91d..182e00ee1d 100644
--- a/src/bhyve/bhyve_conf.c
+++ b/
of type 'tcp'
- A domain that uses unsupported port, such as target.port=4 which
translates into com5.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_command.c | 4 +-
.../bhyvexml2argv-4-consoles.args | 15 +
.../bhyvexml2argv-4-consoles
Signed-off-by: Roman Bogorodskiy
---
docs/drvbhyve.rst | 19 +++
1 file changed, 19 insertions(+)
diff --git a/docs/drvbhyve.rst b/docs/drvbhyve.rst
index 7eec4a2123..2ecd1358a3 100644
--- a/docs/drvbhyve.rst
+++ b/docs/drvbhyve.rst
@@ -619,3 +619,22 @@ Example
esented as:
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
---
src/bhyve/
Roman Bogorodskiy (3):
bhyve: support serial type 'tcp'
bhyve: increase number of supported consoles to 4
docs: drvbhyve: document TCP console support
docs/drvbhyve.rst | 19 ++
src/bhyve/bhyve_capabilities.c| 3 +-
src/bhyve/bhyve
bridge driver
changes as with this patch alone pf backend cannot be used just yet.
Roman Bogorodskiy (1):
network: introduce Packet Filter firewall backend
meson.build | 2 +
po/POTFILES | 1 +
src/network/bridge_driver_conf.c | 4 +
src
from the network XML definition, and if it's
not specified, we try to determine interface corresponding to the
default route.
Signed-off-by: Roman Bogorodskiy
---
meson.build | 2 +
po/POTFILES | 1 +
src/network/bridge_driver_conf.c |
Daniel P. Berrangé wrote:
> On Sat, Apr 26, 2025 at 09:42:36AM +0200, Roman Bogorodskiy wrote:
> > Implement NAT networking support based on the Packet Filter (pf)
> > firewall in FreeBSD. At this point, the implementation is very basic.
> > It creates:
> >
>
Daniel P. Berrangé wrote:
> On Wed, Jul 16, 2025 at 06:28:47PM +0200, Roman Bogorodskiy wrote:
> > Use the same error messages for serial devices validation which are
> > already used in bhyve_domain.c
> >
> > Signed-off-by: Roman Bogorodskiy
> > ---
&
effects on the virDomainObj object.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_process.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/bhyve/bhyve_process.c b/src/bhyve/bhyve_process.c
index 5e77a9c4d6..79be6f7aba 100644
--- a/src/bhyve
Signed-off-by: Roman Bogorodskiy
---
NEWS.rst | 19 +++
1 file changed, 19 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 6cc8f23225..447259d66e 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -40,6 +40,17 @@ v11.6.0 (unreleased)
be modified by setting the
When a domain configured with "", 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
---
src/bhyve/bhyve_firmware.c
Roman Bogorodskiy wrote:
> Signed-off-by: Roman Bogorodskiy
> ---
> NEWS.rst | 19 +++
> 1 file changed, 19 insertions(+)
ping
92 matches
Mail list logo
