Support and News Forum

I have followed all the steps listed out in the "how to" on installing vMX v17. Once I start the VFP the output hangs at the "Select kernel options and boot kernel" menu. The only item you are able to choose is "Serial Console".

Once you select serial console it begins to boot and stops almost immediately. Below is the output.
-------------------------------------
Loading vmlinuz... ok
Loading initrd...ok
-------------------------------------

When I check the unl_wrapper.txt log the only error I see is. All other logs are clean.
-------------------------------------
Jan 11 07:22:50 ERROR: QEMU Arch is not set (80015).
-------------------------------------

The VCP boots properly and Im able to access JUNOS. But since the VFP never boots, no interfaces appear for use.

I have also successfully gotten the vSRX v15, and Junos Space to boot, show interfaces and interact with the internet.

version 17.X need heavy CPU and PC to run.
As well you have to prepare image properly sir..

http://www.eve-ng.net/index.php/documen ... -16-x-17-x

UD

Uldis (UD) wrote: ↑

Thu Jan 11, 2018 9:04 am

version 17.X need heavy CPU and PC to run.
As well you have to prepare image properly sir..

http://www.eve-ng.net/index.php/documen ... -16-x-17-x

UD

I suspect it was a hardware issue. We tried on another server and it worked as it should. Thanks for the quick reply.

<t>Interesting. I am seeing the same thing. I've used EveNG pretty flawlessly in the past, but recently upgraded my laptop and now able to boot pretty much everything, except for the VFP of the VMX.<br/>
<br/>
Fusion v11 running on Macbook Pro i5 with 16G of RAM running High Sierra running 2.0.3-92 version of Eve-NG.<br/>
<br/>
no errors in the unl_wrapper.txt log file, but I get this far post-boot, then nothing. I've tried vmxvfp-17.1R1-domestic-VFP, vmxvfp-17.1R2.7, vmxvfp-17.2R1-S1, vmxvfp-18.2X75-D20.9 and all seem to hang at the same spot.<br/>
<br/>
<br/>
Loading vmlinuz... ok<br/>
Loading initrd...ok<br/>
<br/>
<br/>
here's the logs from unl-wrapper.txt. Nothing that looks terribly informative.<br/>
Nov 05 22:49:06 INFO: tunctl -u unl0 -g root -t vunl0_2_0 2>&1<br/>
Nov 05 22:49:06 INFO: sysctl -w net.ipv6.conf.vunl0_2_0.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_1 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_1.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_2 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_2.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_3 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_3.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_4 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_4.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_5 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_5.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_6 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_6.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_7 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_7.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_8 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_8.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_9 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_9.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_10 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_10.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: tunctl -u unl0 -g root -t vunl0_2_11 2>&1<br/>
Nov 05 22:49:07 INFO: sysctl -w net.ipv6.conf.vunl0_2_11.disable_ipv6=1<br/>
Nov 05 22:49:07 INFO: CWD is /opt/unetlab/tmp/0/38da5b39-aac3-49ab-a888-07ea1b19e1f5/2<br/>
Nov 05 22:49:07 INFO: starting /opt/unetlab/wrappers/qemu_wrapper -T 0 -D 2 -t "vMX-VFP-1" -F /opt/qemu/bin/qemu-system-x86_64 -d 0 -- -nographic -device virtio-net-pci,netdev=net0,mac=50:00:00:02:00:00 -netdev tap,id=net0,ifname=vunl0_2_0,script=no -device virtio-net-pci,netdev=net1,mac=50:00:00:02:00:01 -netdev tap,id=net1,ifname=vunl0_2_1,script=no -device virtio-net-pci,netdev=net2,mac=50:00:00:02:00:02 -netdev tap,id=net2,ifname=vunl0_2_2,script=no -device virtio-net-pci,netdev=net3,mac=50:00:00:02:00:03 -netdev tap,id=net3,ifname=vunl0_2_3,script=no -device virtio-net-pci,netdev=net4,mac=50:00:00:02:00:04 -netdev tap,id=net4,ifname=vunl0_2_4,script=no -device virtio-net-pci,netdev=net5,mac=50:00:00:02:00:05 -netdev tap,id=net5,ifname=vunl0_2_5,script=no -device virtio-net-pci,netdev=net6,mac=50:00:00:02:00:06 -netdev tap,id=net6,ifname=vunl0_2_6,script=no -device virtio-net-pci,netdev=net7,mac=50:00:00:02:00:07 -netdev tap,id=net7,ifname=vunl0_2_7,script=no -device virtio-net-pci,netdev=net8,mac=50:00:00:02:00:08 -netdev tap,id=net8,ifname=vunl0_2_8,script=no -device virtio-net-pci,netdev=net9,mac=50:00:00:02:00:09 -netdev tap,id=net9,ifname=vunl0_2_9,script=no -device virtio-net-pci,netdev=net10,mac=50:00:00:02:00:0a -netdev tap,id=net10,ifname=vunl0_2_10,script=no -device virtio-net-pci,netdev=net11,mac=50:00:00:02:00:0b -netdev tap,id=net11,ifname=vunl0_2_11,script=no -smp 3 -m 4096 -name vMX-VFP-1 -uuid 7e888b34-328c-4dac-9ce2-44f0d9d0b3cd -hda hda.qcow2 -machine type=pc-1.0,accel=kvm -serial mon:stdio -nographic > /opt/unetlab/tmp/0/38da5b39-aac3-49ab-a888-07ea1b19e1f5/2/wrapper.txt 2>&1 &</t>

visited the FAQ to load those images correctly (i think), 3 vCPU and 4G of RAM allocated (default). Curious if anyone else has noted similar boot issues. As mentioned in previous post, I can get the VCP to boot, along with an EOS image and a vSRX 15.1X OK.

+1.
The same situation.

It seems, it is resource problem.
https://forums.juniper.net/t5/vMX/vMX-c ... d-p/298032
In standard configuration VFP needs 8Gb RAM.
I've decrease number of interfaces(4) on VFP and it booted.

I ran into similar situation when i switched from a dedicated Ubuntu server for eve to vmware. After building the vmware vm from the eve iso, i copied my unetlab folder over and opened my lab. Everything worked but the vfp nodes, got stuck at initrd when booting. After hours of tinkering I changed the qemu version on the node config from tpl(2.4.0) to 2.6.2 and it boots fine now.

same here