<IdleBot_cef0f9d0>
I feel that calling the host side of virtio-net «virtio-net network driver» is a bit confusing…
<IdleBot_cef0f9d0>
Then again, if there are VM-to-VM sockets, maybe one could even tunnel all the traffic via sockets to a VM dedicated just to multiplexing the network traffic
<IdleBot_cef0f9d0>
(but I do not understand if there is any option for zero-copy VM-to-VM socket)
<qyliss>
Sorry, that was an error
<qyliss>
Host side should be virtio-net device, and the only driver it would need would be TAP
<qyliss>
I GOT VHOST-USER-NET WORKING IN CROSVM
<qyliss>
I decided to just spend a little more time finishing up what I was trying with the first attempt before I started over
<qyliss>
And I got it to work!
<alj[m]>
nice!
<qyliss>
Was able to curl an HTTP server on the host from the VM
<qyliss>
Talking to the actual internet would mostly involve messing around with host routing, so not very interesting to the problem domain despite being a cooler demo
<qyliss>
So I'll leave it with this.
<leah2>
yay :)
<IdleBot_cef0f9d0>
qyliss: want the magic lines for quick kind-of-acceptable NAT setup?
<qyliss>
I think I'll spend some time reading about virtio-fs now.
<qyliss>
I'm not sure yet if it'll be a good fit but definitely seems worth knowing about.
<philipp[m]>
Since joining the room on matrix.org is kinda broken: I aliased it to #spectrum:matrix.org. Two people tried to get in and one made it.
<qyliss>
philipp[m]: that sounds cool! Can you explain a little more what that means to somebody who has never used Matrix?
jb55 has quit [Ping timeout: 240 seconds]
<philipp[m]>
qyliss: matrix rooms are more like a federated db, if that makes sense. All Servers that have users joined try to keep all the state and talk to each other. A room can have as many pretty names as you like on as many servers as you like.
<philipp[m]>
Since the thing that seems to be broken is the pretty name -> internal name translation on matrix.org, I added another pretty name on my own server to the same distributed db room.
<philipp[m]>
The irc bridge is still hosted by matrix.org, of course.
jb55 has joined #spectrum
<qyliss>
Oh, cool!
<qyliss>
philipp[m]: So people should be able to join #spectrum:matrix.org, and get exactly the same thing as if they'd done it the normal way through the freenode bridge?
<philipp[m]>
should...
<philipp[m]>
And they need to join #spectrum:xndr.de since I don't have access to the matrix.org namespace.
<philipp[m]>
Yeah, typo up there. Sorry for the confusion.
<qyliss>
AIUI, even if that server went away, the room would still exist?
<philipp[m]>
The room, yes. The pretty name: No.
<philipp[m]>
It was more of a test what exactly is wrong with the room.
<qyliss>
mmm, right
<philipp[m]>
I wouldn't reccomend using that name in official documentation, even though this matrix server should not go down for years to come.
<qyliss>
hmm, okay
<philipp[m]>
I'll poke around some more and try to find you something that could be used in that way, if you want me to.
<philipp[m]>
qyliss: I created a throwaway user on matrix.org and added the alias #spectrumos:matrix.org joining via that seems to work and only depends on matrix.org.
<qyliss>
philipp[m]: okay, shall we put that in the documentation?
<philipp[m]>
Can't hurt to add it as an alternative method, I think.
<philipp[m]>
Is there a feature set defined anywhere that the minimal vm kernel needs to have except being bootable via kvm? For example you could probably do without usb support, but that is probably needed down the line.
<philipp[m]>
I'm thinking of cubes-like passthrough scenarios here.
<philipp[m]>
Or is the idea to have a barely bootable kernel and add features as needed?