Same IP address received from DHCP when running multiple GNS3 VM's on same VirtualBox host

[eantowne]

NOTE: This is an edge case.

Ubuntu (not sure what version this started with) does not use the MAC address to request DHCP lease, it uses Machine-ID. this causes the same IP address to be leased to Multiple VM's based on the same .ova. Resetting the MAC address for a NIC has no effect.

Tested Hypervisor: Virtualbox 6.1.22 Host OS: Pop-OS 20.10 (Ubuntu)

NOTE: NOT tested on any other hypervisor, but conceivably should have same behavior.

Recommendation:

Implement the below in order to cause the VM to generate a new Machine-ID on boot. It is important to note that if the master VM is booted, then this process will have to be executed again.

sudo rm /etc/machine-id /var/lib/dbus/machine-id
sudo touch /etc/machine-id
sudo chmod 444 /etc/machine-id
sudo shutdown -h now

[josephmhiggins]

This is all within the realm of virtualbox 7.0.6 and 7.0.8 and per David Bombal, nested virtualization became available in 7.0. Virtualbox released virtualbox 7.1.10 3 days ago. I should be able to install it and try it out. I do not understand Virtualbox because the announcement was that: Announcement: VirtualBox 6.1.46 released (Vadim Galitsin) Announcement: VirtualBox 7.0.10 released (Vadim Galitsin)

I do not know what 6.1.46 is, maybe it is for Linux? I will only look at 7.0.10

[josephmhiggins]

@Ean, I recommend closing this out. I have discussed this regarding VMware upgrades from 2.2.xy to 2.2.yz. The Gns3VMs get the same mac address. The fix was to remove the GNS3 VM from VMware and rename the directory GNS3VM to GNS3VM2.2.XY and the bring in in GNS3 VM 2.2.yz and use a directory name of GNS VM.. Off-hand,, multiple GNS3VMs in Virtualbox seems non-sensical because they support "infinite" number of VMs and an "infinite" number of interfaces. I do not understand why someone would want to have 5 different GNS3VMs in Virtualbox.

Edit: you can't have 5 different GNS3VMs in VMware - it does not work and there is no reason to try to make it work.

I recommend a "Won't Fix"...and anything under Virtualbox 7.0.10 is an absolute non-starter.

[eantowne]

@josephmhiggins,

As noted, this is an edge-case issue.

I somehow missed your response in 2023, this issue has nothing to do with nested virtualization.

There is a use case (until 3.0 is fully released and adopted for use by all parties, important to note that release and adoption are 2 wildly different things).

Use case: Imagine a college teaching networking. They automate the creation and destruction of multiple GNS3 VM's per-day to accommodate multiple classes and keep the students lab environment clean. Each student gets their own VM, because, well students will be students and we do not want them interfering with each other. Same idea as to why chemistry students do not all conduct labs with the same equipment at the same time.

Could the automated lab environment incorporate this fix, conceivably, but it would be better to have the fix be native in the VM at the time that the VM is being built.

The implementation of this fix should be simply an addition to the build process for the VM, and should probably be applied to all GNS3 VM build templates, not just the VirtualBox VM. The reason for this is that this Ubuntu behavior, not specific to a certain hypervisor. Here is a reference: https://kb.vmware.com/s/article/82229 (this document has a couple of other methods for fixing this issue as well)

To be fair I have not tested this since this issue was created in 2021. So I have no idea if it still an issue, but I suspect it may be.

[josephmhiggins]

The duplicated hosted up my ability to defeat Jeremy's statement: "Understand there is no rollback possible once you open an older project in version 2.2" I ended up defeating it with my "gns3 end project" - which takes 5 seconds to implement.

mac-addresses are only of any relevance on the same subnet/private vlan. Why not just have every gns3vm in your class be on a different private vlan and the teacher can clear out the cache/reboot whatever is talking to each students gns3vm.

I do not understand why my gns3vm should be able talk to your gns3vm.

Years ago, i had a gns3vms named gns3vm-2.21, gns3vm-2.22, and gns3vm all in vmware, although they were never on at the same time. Finally, I moved to only permitting one gns3vm, named GNS3 VM, in vmware.

I threw out my windows 10 host yesterday.

Strictly speaking, it is silly for the GNS3 VM to have the same mac-address every time. But it looks like too much unnecessary work to resolve it (I briefly looked at github for some kind of "mac address randomization" - I did not find it, but it probably exists. I also thought about requesting a OUI block from IEEE, but they probably would want alot of money)

[eantowne]

Once again, methods are provided in the VMware reference I provided as well as the method I provided in my original post.

• "I do not understand why my gns3vm should be able talk to your gns3vm." - This is not relevant to the issue at hand. This is NOT the intent.
• "I threw out my windows 10 host yesterday." - Also not relevant, but good to know I guess?
• "it is silly for the GNS3 VM to have the same mac-address every time" - Agreed, but not relevant in this case since it is not the MAC address being used for the DHCP, it is the "machine-ID"

[eantowne]

As a side note, I am not even sure that anything in this repo is even being used anymore.

@grossmj , is this repo still handling the method/process for build of the GNS3 VM's at version release?

[grossmj]

@grossmj , is this repo still handling the method/process for build of the GNS3 VM's at version release?

@eantowne yes we still use this repo to build the GNS3 VM's :)