Re: Virtual Network API for QEMU

[Radek Simko]

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

Re: Virtual Network API for QEMU

[Radek Simko]

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

Re: Virtual Network API for QEMU

[Andrea Bolognani]

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

Re: Virtual Network API for QEMU

[Radek Simko]

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 
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
> . You can even configure it's IP address should
> you need to do so:
>
> https://libvirt.org/formatdomain.html#userspace-slirp-stack
>
> Michal
>
>

Re: Virtual Network API for QEMU

[Radek Simko]

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 
wrote:

> On 3/27/21 1:39 PM, Radek Simko wrote:
> > 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?
>
> 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.
>
>

Re: Virtual Network API for QEMU

[Michal Privoznik]

On 3/27/21 1:39 PM, Radek Simko wrote:

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?


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.

Re: Virtual Network API for QEMU

[Laine Stump]

On 3/27/21 8:39 AM, Radek Simko wrote:

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.


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

Virtual Network API for QEMU

[Radek Simko]

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