Re: [9fans] Static ip configuration for a standalone cpu server in qemu on Linux

[Alexander Kapshuk <alexander.kapshuk@gmail.com>]

With the tap device up:
ip addr show dev tap0
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
    link/ether 9a:44:ad:1f:39:d9 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::9844:adff:fe1f:39d9/64 scope link
       valid_lft forever preferred_lft forever

And the qemu command using the mac address given in the fqa example:
qemu-system-x86_64 \
-boot order=d \
-drive file=$HOME/Plan9.raw.img,format=raw \
-netdev tap,id=eth,ifname=tap0,script=no,downscript=no \
-device e1000,netdev=eth,mac=52:54:00:00:EE:03

And the ether= attribute removed from /lib/ndb/local,

Both pings below work now.
ping 10.0.0.2 # Linux
ip/ping 10.0.0.1 # Plan 9

tcpdump -nS -vv -i tap0
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size
262144 bytes
16:35:00.265147 IP (tos 0x0, ttl 1, id 46876, offset 0, flags [DF],
proto UDP (17), length 195)
    10.0.0.1.48952 > 239.255.255.250.1900: [udp sum ok] UDP, length 167
16:35:01.266364 IP (tos 0x0, ttl 1, id 47164, offset 0, flags [DF],
proto UDP (17), length 195)
    10.0.0.1.48952 > 239.255.255.250.1900: [udp sum ok] UDP, length 167
16:35:02.266828 IP (tos 0x0, ttl 1, id 47770, offset 0, flags [DF],
proto UDP (17), length 195)
    10.0.0.1.48952 > 239.255.255.250.1900: [udp sum ok] UDP, length 167
16:35:03.267406 IP (tos 0x0, ttl 1, id 48737, offset 0, flags [DF],
proto UDP (17), length 195)
    10.0.0.1.48952 > 239.255.255.250.1900: [udp sum ok] UDP, length 167
16:35:28.213321 IP (tos 0x0, ttl 255, id 5, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24833, length 44
16:35:28.213374 IP (tos 0x0, ttl 64, id 2728, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24833, length 44
16:35:29.212816 IP (tos 0x0, ttl 255, id 6, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24834, length 44
16:35:29.212873 IP (tos 0x0, ttl 64, id 2867, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24834, length 44
16:35:30.223989 IP (tos 0x0, ttl 255, id 7, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24835, length 44
16:35:30.224042 IP (tos 0x0, ttl 64, id 2906, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24835, length 44
16:35:31.223030 IP (tos 0x0, ttl 255, id 8, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24836, length 44
16:35:31.223086 IP (tos 0x0, ttl 64, id 3895, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24836, length 44
16:35:32.222034 IP (tos 0x0, ttl 255, id 9, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24837, length 44
16:35:32.222090 IP (tos 0x0, ttl 64, id 4241, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24837, length 44
16:35:33.233714 IP (tos 0x0, ttl 255, id 10, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24838, length 44
16:35:33.233769 IP (tos 0x0, ttl 64, id 4545, offset 0, flags [none],
proto ICMP (1), length 64)
    10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24838, length 44


On to the standalone CPU + auth server setup instructions now.
Thanks very much for all your help.
On Sun, Aug 26, 2018 at 7:56 AM Alexander Kapshuk
<alexander.kapshuk@gmail.com> wrote:
>
> Understood.
> I'll give it a try and let you know how I go.
> Thanks.
>
>
> On Sun, Aug 26, 2018, 00:20 hiro <23hiro@gmail.com> wrote:
>>
>> nothing in the fqa mentions the tap device's mac address (which linux
>> generated randomly in order not to conflict with whatever you might be
>> using on the other side).
>>
>> look at the tap device as an ethernet interface that is plugged into
>> the same L2 switch as the VM's virtual interface.
>>
>> you don't want mac address collisions in one L2 network, so yes, use a
>> different one for the VM.
>>