Re: hubport connectivity problems

[lacsaP Patatetom]

Le mar. 28 mars 2023 à 19:53, Eric Nichols (DirWiz) <eric@dirwiz.com> a écrit :
>
> Many thanks to both for the info and the helpful advice.  On linux both
> solutions worked amazingly well.
>
> I have a few pieces of feedback on the windows version fwiw.
>
> Thomas's solution of using socket worked on windows except the window's
> firewall wanted to build in some exceptions.  The quick fix was to use:
> listen=127.0.0.1:1234
>
> lacsaP the mcast stuff on windows errored:
> can't bind ip=239.192.168.1 to socket unknown error
>
> I did a bit of googling and found a possible issue with windows and
> mcast:
> https://serverfault.com/questions/1002977/cannot-create-qemu-socket-networking-in-windows-host-using-multicast-fails-with
>
> It would be wonderful to re-imagine hubport as a virtual switch across
> multiple running VM's and handle all this socket/mcast complexity
> internally and away from the OS.  Bonus points if you could merge this
> new idea for hubport with SLIRP!
>
> Many thanks again!
> Eric
>
>
> On 3/28/23 6:05 AM, lacsaP Patatetom wrote:
> > Le mar. 28 mars 2023 à 09:36, Thomas Huth <thuth@redhat.com> a écrit :
> >>
> >> On 27/03/2023 21.52, Eric Nichols (DirWiz) via wrote:
> >>> Long time user, first time poster...
> >>>
> >>> My setup is simple.  Debian host running qemu 7.2.0 and 2 guest (Windows
> >>> 2010 workstation & 2022 server).  My goal is to setup a private guest only
> >>> network (no connection to host) with hubport.
> >>>
> >>> Based on the docs I've tried:
> >>> -netdev hubport,hubid=0,id=hub0 -device virtio-net-pci,netdev=hub0
> >>>
> >>> There is also the second option of:
> >>> -nic hubport,hubid=0,model=virtio-net-pci
> >>>
> >>> And also small mention that a hubport 0 will be setup if you just use a
> >>> virtual adapter and don't connect it to anything:
> >>> -net nic,model=virtio-net-pci,macaddr=52:54:00:00:00:03
> >>>
> >>> I did static IPs on both of the guests but can't ping or connect over TCP.
> >>> Any ideas?
> >>
> >> hubport basically emulates a hub *within* one instance of QEMU. Hubport
> >> alone does not connect to any other QEMU (i.e. guest) instance. It's mostly
> >> a legacy concept from the early days of QEMU - and unless you want to
> >> connect multiple NICs of one guest together, you likely don't need it. (see
> >> also https://www.qemu.org/2018/05/31/nic-parameter/ for some more 
> >> information).
> >>
> >> If you want to connect two local guests via a local network, you could have
> >> a look at the "-netdev socket" option. For example, start one QEMU with
> >> "-nic socket,model=virtio-net-pci,id=net0,listen=:1234" and the other QEMU
> >> with "-nic socket,model=virtio-net-pci,id=net1,connect=:1234" and you 
> >> should
> >> be able to see the network traffic of one guest on the interface of the
> >> other and vice versa.
> >>
> >>    HTH,
> >>     Thomas
> >>
> >>
> >>
> > hi, if you need more than 2 guests, you can start virtual machines
> > connected on the same virtual network bus :
> >
> > qemu \
> >    -drive file=hd1.img,media=disk \
> >    -nic socket,mac=52:54:00:11:11:11,mcast=239.192.168.1:1101
> > qemu \
> >    -drive file=hd2.img,media=disk \
> >    -nic socket,mac=52:54:00:22:22:22,mcast=239.192.168.1:1101
> > qemu \
> >    -drive file=hd3.img,media=disk \
> >    -nic socket,mac=52:54:00:33:33:33,mcast=239.192.168.1:1101
> >
> > regards, lacsaP.

thanks for W$ feedback.

on Linux, I also use VDE switch (which corresponds somewhat to the
desired hubport) to connect my VMs
(https://github.com/virtualsquare/vde-2)

vde_switch -d

qemu \
  -drive file=hd1.img,media=disk \
  -nic vde,mac=52:54:00:11:11:11
qemu \
  -drive file=hd2.img,media=disk \
  -nic vde,mac=52:54:00:22:22:22

I used to add slirpvde for dhcp but it has been abandoned : I now use
dnsmasq@tap0 (https://github.com/virtualsquare/vde-2/issues/39)

regards, lacsaP.