Easing libremesh virtualization

[irina556]

1. Remove the host interface
   Removes an interface that was created on the host after having started a node with qemu_dev_start

2. Put the message in ansible for access to cloud nodes
   By raising a cloud of nodes we could access each one by clusterssh. However, the output message was not entirely clear. For this reason, it is modified so that the user can directly copy it and thus build the cloud of nodes.

3. Add the "files" directory in ansible
   Since the qemu_cloud_start.yml playbook uses this directory, it is left created to prevent the user from having to do so.

4. Port change
   When you wanted to start a node giving it access to the internet using --enable-wan for qemu_dev_start, a collision with the port occurred since dnsmasq uses port 53 by default, which in general in the different Linux distributions is already occupied by the systemd-resolved service. To solve this, another port is assigned so that this collision does not occur.
   It is worth noting that bind-dynamic was used because simply assigning another port on some PCs did not work and on others it did.

5. Change ifconfig to ip
   In the linux_bridge.py and linux_bridge_port.py modules used by ansible, there were calls to ifconfig, and since modern Linux distributions do not have this command to view the TCP/IP configuration, it was not possible to run the node cloud (unless installing the net-tools package for ifconfig use). To avoid this inconvenience to any other user, the ifconfig calls are modified with the ip surrogate.

6. Added a playbook called "cloud_and_node_packages" in which the installation of some packages needed to run the qemu-dev-start file (iptables,dnsmasq) and others needed such as clusterssh and bridge-utils to run qemu_cloud_start.yml was automated, in case the user's host did not have them installed.

7. Creation of detailed documentation for virtualization: VIRTUALIZING.md
   Although there was already some documentation in TESTING.md, a new file was created in which the fact of raising LibreMesh virtuals is explained in a more detailed and procedural way. In this way, more complete knowledge is given to any new user about what he can and must do to set up virtual nodes.

[ilario]

Hi! The link should point to the file that will be in the libremesh/lime-packages default branch repository.

[G10h4ck]

ping @irina556

[G10h4ck]

I think it is more readable if you change the first -o with --options

[G10h4ck]

Are you sure DNS server for virtual machines will work as is without any change if the dnsmasq is listening on port 5353 ?

[ilario]

@irina556 are you reading? Can you fix or should we just merge and then fix?

[G10h4ck]

@ilario would you volunteer to test and do the last polishing I have suggested, so we can merge it?
This work seems valuable to me but @irina556 is not responding since months so we should found another way to merge this before it rots in merge conflicts.

[ilario]

@ilario would you volunteer to test and do the last polishing I have suggested, so we can merge it?

I would gladly do that, but I have little space on my hard drive also due to the 24 GB of the buildroot.
In order to get rid of those, I would need another place where to compile.
repo.libremesh.org was an option but it requires some complicated maintenance and updating, if I understood correctly.

Have you tried asking her GSoC mentor(s)?
If I recall correctly there was some people between @germanferrero, @spiccinini and/or @Patacon13.

[Patacon13]

@ilario would you volunteer to test and do the last polishing I have suggested, so we can merge it?

I would gladly do that, but I have little space on my hard drive also due to the 24 GB of the buildroot. In order to get rid of those, I would need another place where to compile. repo.libremesh.org was an option but it requires some complicated maintenance and updating, if I understood correctly.

Have you tried asking her GSoC mentor(s)? If I recall correctly there was some people between @germanferrero, @spiccinini and/or @Patacon13.

Hi! Irina didn't see the previous messages. I've messaged her about the fixes that @G10h4ck proposes, so she's going to make them. Thanks for notifying!

[G10h4ck]

Hi! Irina didn't see the previous messages. I've messaged her about the fixes that @G10h4ck proposes, so she's going to make them. Thanks for notifying!

@Patacon13 @irina556 any news? I am about to re-target libremesh, it would be good to be able to merge this PR before of that

[irina556]

Hello! I apologize for the time I was not there. I haven't been able to review the changes because I had a problem with the computer I did the project on. It was burned, so I have lost all the information and the environment in which I have worked. In the same way, now I review the comments and I will do what I can. But currently I am without a computer so I can do tests

[G10h4ck]

@irina556 did you managed to get a computer ?

[a-gave]

Hi!
I add just small notes on this.
I've tried it and it seems to work normally also with firmware images based on openwrt-22.03.5 and with openwrt-23.05.0-rc2.
But for both versions I had to use the generic-kernel.bin instead of ramfs.bzImage [0]

cd lime-packages/tools;
./qemu_dev_start --node-id 1 --enable-wan wlo1 \
    libremesh-2023.1-rc1-ow22-default-x86-64-generic-rootfs.tar.gz \
    libremesh-2023.1-rc1-ow22-default-x86-64-generic-kernel.bin

A second note
This tool qemu_dev_start seems to work only with images built by buildroot and not ones built by the imagebuilder.
I tried to just see if the firmware images built with imagebuilder ever boot on qemu using instead the produced generic-ext4-combined.img images, for both openwrt versions 22.03.5 and 23.05.0-rc2, using this script below taken from the README of Temba [1] and the boot goes on without errors:

gunzip libremesh-2023.1-rc1-ow22-default-x86-64-generic-ext4-combined.img.gz
qemu-system-x86_64 -M q35 -drive file=libremesh-2023.1-rc1-ow22-default-x86-64-generic-ext4-combined.img,id=d0,if=none,bus=0,unit=0 -device ide-hd,drive=d0,bus=ide.0

[0] The ramfs.bzImage is not produced anymore since openwrt-21.02.7. It seems like the bzImage is now the default format for the kernel in x86.

cat target/linux/x86/Makefile | grep bzImage
KERNELNAME:=bzImage

[1] https://farga.exo.cat/exo/temba#run-x86_64-in-qemu

[ilario]

Shall we merge this and move all the comments to an issue? @G10h4ck @spiccinini @irina556 @Patacon13 @altergui

[spiccinini]

+1 for me given that it was independently tested