Virtual Network API for QEMU
Hi, According to this support matrix 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? Thanks, Radek Simko
On 3/27/21 8:39 AM, 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.
I'm afraid I don't understand your question. Which hypervisor are you using that you think virConnectNumOfNetworks isn't supported. The only possible meaning I can get from the above sentences is that you think virConnectNumOfNetworks isn't supported when qemu is the hypervisor, which is definitely *not* true. As a matter of fact, essentiall *all* of the functions in the matrix are supported when qemu is the hypervisor, pretty much every one of them ever since their original introduction (e.g., the function you reference has been supported since libvirt 0.2.0, which was released in February 2007). Are you possibly misinterpreting the contents of the support matrix?
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?
Thanks,
Radek Simko
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@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.
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
I see, thank you for the extra context and quick response Michal. I wasn't aware of the userspace SLIRP stack nor the darwin limitation - will give either a try. My main requirement is basically getting SSH to work, so I can do some provisioning, anything else would be a bonus for me. Radek Simko On Thu, Apr 1, 2021 at 11:09 AM Michal Privoznik <mprivozn@redhat.com> wrote:
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 --all
Aside: 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
Recompiling with these few changes helped and the networking drivers _seems_ to be working on macOS. At least I got past the error I was getting initially. I'm just now dealing with a slightly different set of problems related to libvirt sockets on macOS. The Homebrew formula ships a launchd plist which doesn't seem to do socket activation, unlike systemd. I worked around that by setting the socket dir path manually in the config: unix_sock_dir = "/usr/local/var/run/libvirt" which did make libvirtd create "libvirt-sock" in that directory as expected, but per docs there should also be a secondary read-only socket "libvirt-sock-ro" https://libvirt.org/daemons.html#monolithic-sockets and it's not there for some reason. Is there any additional configuration needed to activate that secondary socket? Feel free to tell me if this is getting too off-topic btw. - The big picture is that I'm trying to get libvirt working on darwin and automate RPi virtualization via Vagrant (vagrant-libvirt) and taking it step by step. Radek Simko On Thu, Apr 1, 2021 at 2:54 PM Andrea Bolognani <abologna@redhat.com> wrote:
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 --all
Aside: 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
I eventually managed to spin up all the processes (libvirtd, virtlogd, virtlockd) individually and under root, which also helped exposing the read-only socket. I gathered from reading through the libvirt source code that the read-only socket is only activated under privileged mode which has led me down that path. With all this running, I went back to my automation efforts with Vagrant libvirt and realized that it wants to make a call that doesn't seem supported on macOS (yet): Call to virDomainCreateWithFlags failed: Unable to create TAP devices on this platform: Function not implemented ^ which I suppose confirms the mentioned worries of Michal So I can say that while running libvirt on macOS isn't super smooth it's possible. :) The sharp edges around permissions and launchd plist files is something that can be smoothed out eventually and that is probably something to resolve on the distribution side (e.g. Homebrew) anyway, not necessarily on libvirt's. Radek Simko On Fri, Apr 2, 2021 at 5:47 PM Radek Simko <radek.simko@gmail.com> wrote:
Recompiling with these few changes helped and the networking drivers _seems_ to be working on macOS. At least I got past the error I was getting initially.
I'm just now dealing with a slightly different set of problems related to libvirt sockets on macOS. The Homebrew formula ships a launchd plist which doesn't seem to do socket activation, unlike systemd. I worked around that by setting the socket dir path manually in the config:
unix_sock_dir = "/usr/local/var/run/libvirt"
which did make libvirtd create "libvirt-sock" in that directory as expected, but per docs there should also be a secondary read-only socket "libvirt-sock-ro" https://libvirt.org/daemons.html#monolithic-sockets and it's not there for some reason. Is there any additional configuration needed to activate that secondary socket?
Feel free to tell me if this is getting too off-topic btw. - The big picture is that I'm trying to get libvirt working on darwin and automate RPi virtualization via Vagrant (vagrant-libvirt) and taking it step by step.
Radek Simko
On Thu, Apr 1, 2021 at 2:54 PM Andrea Bolognani <abologna@redhat.com> wrote:
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 --all
Aside: 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
participants (4)
-
Andrea Bolognani -
Laine Stump -
Michal Privoznik -
Radek Simko