apparently the inputbox “Force IPv4” in VM instantiation does not work for me:
I have a VNet with IPv4+IPv6 address range assigned, and a template with NIC assigned to that VNet. The template uses a generic image (say, Fedora 33) with non-persistent disk. Now I want to instantiate it, and want to select the IP address myself. So I click on Instantiate, enter the VM name, and open the “Network” part near the bottom. Keep the selected network as is, and enter the desired IPv4 address to the “Force IPv4” field. Check the “Start on hold” checkbox, and then click on “Instantiate”.
Then I open the list of VMs (Instances/VMs), open the details of the newly created instance, and see that it has the first available IPv4 address in its “Info” tab instead the one I manually tried to set up. I tried even opening the “Conf” tab, clicking on “Update configuration”, opening the “Context/Custom Vars” tab, and overwriting the ETH0_IP, ETH0_IP6, and ETH0_MAC variables. When I click on Update, the original values are back. An when I release (un-hold) the VM, it indeed has that automatically selected IPv4 address assigned.
Am I doing something wrong, or is it supposed to work the way I expect? Soon I would need to instantiate about 400 VMs with manualy selected addresses from various parts of a /16 IPv4 range, so I am looking for a way how to do it.
thanks for the reply. I have tested it once again, and it looks like it is more complicated than only ignoring the FORCE_IPV4 parameter: firstly, I have created another clean VNet for testing, with a completely different address range (10.42.42.0/24). Now I want to instantiate a template, which has its network interface configured by default to another pre-existing VNet. So In the instantiation page, I open the network part of the template, then the list of available networks, select my newly created VNet, and enter 10.42.42.42 as forced IPv4 address. Now I click on Instantiate.
The newly created VM in the list of VMs has 172.2x.y.z address, which is the first available address from the network the just-instantiated template has as its default, not from the network I selected. And, of course, the NIC is connected to that network, not to the newly created testing network with 10.42.42.0/24 range.
Testing it further, it happens not only with IPv4/IPv6 addres ranges in the network, but also with an IPv4-only network. Also it happens regardless of the “Start on hold” parameter.
Hotplugging another NIC to the running VM assigns the requested IP address correctly, as well as adding second NIC with 10.42.42.42 address during instantiation.
I use ONe 5.12.0.3 CE (upgraded from previous versions on and on for several years). There is nothing special in oned.log - it looks like a successful instantiation:
Tue Mar 9 12:57:21 2021 [Z0][ReM][D]: Req:6112 UID:0 IP:127.0.0.1 one.template.instantiate invoked , 661, "test", true, "DISK=[
ALLOW_ORPHA...", false
Tue Mar 9 12:57:21 2021 [Z0][ReM][D]: Req:6112 UID:0 one.template.instantiate result SUCCESS, 4484
