vPTX on AMD with svm instead of vmx

[jopicap]

Dear community,

on Ubuntu 24.04.2 LTS, I am trying to create vPTX box by using command

netlab libvirt package vptx vptx-24.4R1.qcow

Script starts well, but then:

[COMPLETE] Pre-install hooks completed

[COPY]    Creating a copy of vptx-24.4R1.qcow in /tmp/build_vptx

┌──────────────────────────────────────────────────────────────────────────────────┐
│ STARTING Starting the network device virtual machine                             │
└──────────────────────────────────────────────────────────────────────────────────┘

We'll start the VM from the newly-created virtual disk. When the
VM starts, execute 'netlab libvirt config vptx' in another
window and follow the instructions.
===================================================================


Domain 'vm_box' defined from template.xml

error: Failed to start domain 'vm_box'
error: the CPU is incompatible with host CPU: Host CPU does not provide required features: vmx

My CPU AMD Ryzen 7 7735HS supports svm not vmx. The error might come from the mandatory feature requested in the generated template.xml:

  <cpu>
     <arch>x86_64</arch>
     <model>IvyBridge</model>
     <topology cores="4" sockets="1" threads="1"/>
     <model fallback="allow">qemu64</model>
     <feature name="vmx" policy="require"/>
  </cpu>

Question is:

• is there a way to rerun the script just at the failing step after having replaced "vmx" by "svm" - and will that work - as a short term solution?
• or can the netlab function to create the vPTX modified so that it supports both CPU platforms - as a long term solution?

WR
Joe

[ssasso]

Hello @jopicap , according to juniper documentation, vJunosEVO seems to require the vmx extension (--cpu IvyBridge,+vmx), and also seems to require that svm is disabled (<feature name="svm" policy="disable"/>).

Could you try to boot a vJunosEVO instance directly with kvm/libvirt, without specifiyng the vmx feature, and see if it works?

[jbemmel]

Hi Joe,

See https://www.juniper.net/documentation/us/en/software/nce/nce-510-virtual-switches-mist-cloud-managed/amd-cpu_unofficial_tweaks.html

I would suggest creating a PR that modifies https://github.com/ipspace/netlab/blob/dev/netsim/install/libvirt/vptx.xml.j2 based on detecting the underlying CPU ( e.g. ansible_processor_vendor == 'AuthenticAMD', although we may have to enable detection of those facts )

[ipspace]

I would suggest creating a PR that modifies https://github.com/ipspace/netlab/blob/dev/netsim/install/libvirt/vptx.xml.j2 based on detecting the underlying CPU ( e.g. ansible_processor_vendor == 'AuthenticAMD', although we may have to enable detection of those facts )

Ansible is not involved in rendering the XML or the Vagrantfile template, so one would have to rely on Python variables (which would have to be copied into the relevant data that's fed to Jinja2)

[ipspace]

It looks like all Juniper products expect to run on Intel CPU (we had a similar problem a long time ago with vSRX, see #10).

Looking at the code, we render the box-building XML template as a Jinja2 template, so it should be relatively easy to find out the CPU type (see #10 for details) and adjust the XML accordingly. The same thing would have to be done for the Vagrant template in templates/providers/libvirt.

I don't have an AMD server ready (yet) to work on this, but of course I'd merge a reasonable PR.

[jbemmel]

@jopicap could you try #2332?

It's a bit rough and untested (as I don't have vPtx images and never worked with them), but I think something along these lines might do the trick

[ipspace]

I happened to have a Minisforum UM890 (with Ryzen CPUs) waiting to be installed, so I got it up and running today (don't get me started on the beauties of systemd/netplan/resolved... 🤦‍♂️😤) and was able to get vPTX box built and a lab successfully started on the AMD CPU.

The fixes are in the dev branch, hope they'll work for you.

Just in case: this is how you can run netlab straight from the local copy of the Git repo: https://netlab.tools/install/clone/

Also: @jbemmel thanks a million for the research and the link to Juniper-suggested hack.

[jopicap]

Back to work...
You did it. I installed netlab from Github as an additional Python venv and rerun netlab libvirt package vptx vptx-24.4R1.qcow.
This part now runs until it connects to the console. Unfortunately, there is no output on console. So, I cannot put the initial config. virsh list says, VM vm_box is running. When rebooting (virsh reboot vm_box) still nothing happens on the console.

To test if something is wrong with my host, I tried same process with vEOS and arubacx which worked completely fine for both. Both vagrant boxes are now available.

Side note: My lab host is Minisforum UM773 lite (64 GB RAM)

[ipspace]

OK, I retried (sometimes I miss things). I'm using Ubuntu 24.04.2 on Minisforum UM890 Pro - AMD Ryzen 9 8945HS, and created a box for vJunosEvolved-23.4R2-S2.1.qcow2 with zero hassle (apart from shutdown taking forever, which is to be expected).

It could be that 24.4R1 no longer works with that trick (it is unsupported, after all), or that your CPU is missing some crucial bits, or... I don't know enough to go beyond "it works on my AMD CPU" 🤷‍♂️

[ipspace]

... and yes, I can confirm that vJunosEvolved-24.4R1.8.qcow2 does not start. Try an older version?

[jopicap]

That's it. Everything is in place now:

Juniper Linux Distribution 3.0.2 re0 ttyS0

re0 login:
vptx login: vagrant
Password:
--- JUNOS 23.4R2-S2.1-EVO Linux (none) 5.2.60-yocto-standard-gbbed0c6 #1 SMP PREEMPT Thu Jul 25 08:41:39 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
vagrant@vptx> show interfaces terse | match re0
re0:mgmt-0              up    up
re0:mgmt-0.0            up    up   inet     192.168.121.33/24

vagrant@vptx> show chassis fpc
                     Temp  CPU Utilization (%)   CPU Utilization (%)  Memory    Utilization (%)
Slot State            (C)  Total  Interrupt      1min   5min   15min  DRAM (MB) Heap     Buffer
  0  Present         ---None---

vagrant@vptx>

That was a great help! Thanks a lot.