:: Re: [DNG] A way of holding telephon…
Top Page
Delete this message
Reply to this message
Author: Ralph Ronnquist
Date:  
To: dng
New-Topics: [DNG] Picking VM MAC addresses (was Re: A way of holding telephone-conferences with DEVUAN?)
Subject: Re: [DNG] A way of holding telephone-conferences with DEVUAN?
Steve Litt wrote on 8/4/20 3:06 am:
> On Wed, 8 Apr 2020 00:40:50 +1000
> Ralph Ronnquist via Dng <dng@???> wrote:
>
>
>> I've done two separate jitsi installations on tiny qemu hosts
>> (beowulf), single-cpu with 1G RAM (and 4G swap). An ad hoc test
>> indicated a load increase of about 0.2 per connections, and it worked
>> on the test with 8 connections (5 from myself, and 3 from someone
>> else).
>
> Hi Ralph,
>
> Could you please post the shellscript with which you spin up these qemu
> hosts? I've never been successful building a qemu host with full
> featured networking.


Ah, those hosts I rent from Vultr.com at $5.5/m, and admittedly I'm only
guessing they are qemu hosts from some droppings in dmesg. However, I think
I've learnt enough of qemu networking to call it easy, so let me digress this
thread momentarily about this.

The options are many and it depends on your taste. Basically, you'll need to
add two command line "-net" arguments": one for selecting network device in the
guest, and one for identifying the connection facility on the host. Perhaps
like so:
    -net nic,macaddr=04:07:a6:c8:34:e2 -net vde,sock=/tmp/vde.ctl


The first says to use the default net device in the guest with the specified
MAC address. The second says to use "vde" networking via the /tmp/vde.ctl
socket directory. vde is installed as "vde2", and I do it this way because it
lets me set up the host side once for any number of concurrent qemu guests.

So for completeness: I would have set up the host with something like the
following:
    # ip tuntap add tap0 mode tap user ralph
    # ifconfig tap0 10.10.10.1/24 up
    # sysctl net.ipv4.ip_forward=1
    # iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -j MASQUERADE
    # dnsmasq -i tap0 -a 10.10.10.1 -I wlan0 -I eth0 -K -D -N -b \
      --dhcp-sequential-ip --dhcp-hostsfile=/home/share/dhcphosts \
      -F 10.10.10.2,10.10.10.254,255.255.255.0,10.10.10.255
    $ vde_switch -t tap0 -d


That one is a little bit of a mouthful but it's easily scriptable:
    1. create a tap owned by "ralph",
    2. configure it with IP 10.10.10.1,
    3. enable kernel forwarding,
    4. add NAT masquerading for packets from the tap0 network and
    5. set up a DHCP responder and DNS forwarder for that interface taking
static ques from the file /home/share/dhcphosts (with lines like
"04:44:25:2f:17:12,beowulf-i386,10.10.10.2", though fully optional)
    6. finally, run the vde networking switch as user ralph


Skip point 5 and use static IP set up in the guest if the host's port 53 is
already taken by some other program; dnsmasq gets unrecoverably sulky if it
can't grab that, but there are also other ways to service DHCP. And if you want
to go ipv6, you'll need different steps 2 and 5, but the rest stays the same.

I set up the host side with tap0 "owned" by "ralph" so I can run vde_switch and
the qemu guests as "ralph" (rather than "root"). The set up survives any number
of qemu up/down, separately or concurrently, and I think of it as the easiest
way. It also seems to perform better even than having a separate tap for each
qemu; at least it did that one time when I tested it.

btw, the MAC address choice has some rules apart from needing to be different
from any other MAC address your networking will get to know of. My rule of
thumb is to start with 04, end with 2, and fill the middle "randomly", but keep
the same MAC address allocated for its individual guest system, which I also
keep documented in /home/share/dhcphosts.

hth

Ralph.