On 3/27/21 1:39 PM, Radek Simko wrote:> Hi, > According to this support matrix > https://libvirt.org/hvsupport.html#virNetworkDriver > <https://libvirt.org/hvsupport.html#virNetworkDriver> > there is no support for any APIs other than hypervisor ones for qemu. > For example virConnectNumOfNetworks is not supported. > > Is there any particular reason this is not supported? Has any > development in that area been attempted in the past? Would contributions > adding support be welcomed?To extend Laine's reply: Libvirt has two set of drivers: statefull (where libvirt keeps the state of resources like domains, networks, ...) and stateless (where libvirt merely translates from/to APIs exposed by hypervisor). QEMU can be an example of a statefull driver, ESX or hyperv are examples of stateless drivers. Stateless drivers also implement network APIs (again, by translating from/to APIs exposed by the underlying hypervisor - ESX or hypverv in this example), whereas statefull drivers use bridge driver. Therefore, QEMU doesn't implement any network APIs. This is even more visible with split daemons (where monolithic libvirtd is broken into smaller daemons) - if virnetworkd is not running then things like 'virsh net-list' return an error [*]. Is there any particular problem you're facing? Michal * - except not really, because these split daemons are socket activated, so virnetworkd is stared automatically when needed.
Thank you Laine and thanks Michal for the detailed explanation. To add some (missing) context from my side: I was attempting to virtualize Raspberry Pi on qemu via libvirt, where my host machine is macOS (both qemu and libvirt installed via Homebrew) and I while trying to set up the network I stumbled upon this: $ virsh -c qemu:///system?socket=/usr/local/var/run/libvirt/libvirt-sock net-list --all error: Failed to get the number of active networks error: this function is not supported by the connection driver: virConnectNumOfNetworks This error in combination with the compatibility matrix made me think it's just not supported. What is the right way of interpreting this error/state? Does the host OS play a role in the compatibility? Are there any known limitations on macOS, or is this likely just a broken/misconfigured installation on my side? Radek Simko On Mon, Mar 29, 2021 at 10:29 AM Michal Privoznik <mprivozn at redhat.com> wrote:> On 3/27/21 1:39 PM, Radek Simko wrote: > > Hi, > > According to this support matrix > > https://libvirt.org/hvsupport.html#virNetworkDriver > > <https://libvirt.org/hvsupport.html#virNetworkDriver> > > there is no support for any APIs other than hypervisor ones for qemu. > > For example virConnectNumOfNetworks is not supported. > > > > Is there any particular reason this is not supported? Has any > > development in that area been attempted in the past? Would contributions > > adding support be welcomed? > > To extend Laine's reply: > > Libvirt has two set of drivers: statefull (where libvirt keeps the state > of resources like domains, networks, ...) and stateless (where libvirt > merely translates from/to APIs exposed by hypervisor). > > QEMU can be an example of a statefull driver, ESX or hyperv are examples > of stateless drivers. Stateless drivers also implement network APIs > (again, by translating from/to APIs exposed by the underlying hypervisor > - ESX or hypverv in this example), whereas statefull drivers use bridge > driver. Therefore, QEMU doesn't implement any network APIs. > > > This is even more visible with split daemons (where monolithic libvirtd > is broken into smaller daemons) - if virnetworkd is not running then > things like 'virsh net-list' return an error [*]. > > > Is there any particular problem you're facing? > > Michal > > > * - except not really, because these split daemons are socket activated, > so virnetworkd is stared automatically when needed. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20210331/4380fe5d/attachment.htm>
On 3/31/21 10:39 PM, Radek Simko wrote:> Thank you Laine and thanks Michal for the detailed?explanation. > > To add some (missing) context from my side: > > I was attempting to virtualize Raspberry Pi on qemu via libvirt, where > my host machine is macOS (both qemu and libvirt installed via Homebrew) > and I while trying to set up the network I stumbled upon this: > > |$ virsh -c > qemu:///system?socket=/usr/local/var/run/libvirt/libvirt-sock net-list > --all error: Failed to get the number of active networks error: this > function is not supported by the connection driver: virConnectNumOfNetworks| > > This error in combination with the compatibility matrix made me think > it's just not supported. > What is the right way of interpreting this error/state? Does the host OS > play a role in the compatibility?Yes it does.> > Are there any known limitations on macOS,?or is this likely just a > broken/misconfigured installation on my side?Oh, now I get it. You are not building the network (bridge) driver. And looking into meson.build I can see why: # there's no use compiling the network driver without the libvirt # daemon, nor compiling it for macOS, where it breaks the compile if not get_option('driver_network').disabled() and conf.has('WITH_LIBVIRTD') and host_machine.system() != 'darwin' conf.set('WITH_NETWORK', 1) endif https://gitlab.com/libvirt/libvirt/-/blob/master/meson.build#L1649 But I'm not sure whether the comment is still true. I don't have any access to macOS so I can't confirm nor deny. But since you can, you can try changing that condition so that WITH_NETWORK is enabled and see whether compilation fails. On the other hand, I'm not sure whether our code would be able to talk to macOS and create briges/TAP devices/... But unless you need something specific for RasPI (i.e. generic HTTP/HTTPS) is enough, then you don't need libvirt network - you can use <interface type='user'/>. You can even configure it's IP address should you need to do so: https://libvirt.org/formatdomain.html#userspace-slirp-stack Michal
On Wed, 2021-03-31 at 21:39 +0100, Radek Simko wrote:> I was attempting to virtualize Raspberry Pi on qemu via libvirt, > where my host machine is macOS (both qemu and libvirt installed via > Homebrew) and I while trying to set up the network I stumbled upon > this: > > $ virsh -c qemu:///system?socket=/usr/local/var/run/libvirt/libvirt-sock net-list --allAside: if you have libvirt >= 6.9.0, which at this point is very likely, you shouldn't need to include the 'socket' parameter in the connection URI; in fact, for local connections, it should have worked without the parameter even before that. -- Andrea Bolognani / Red Hat / Virtualization