When your VIRL lab starts going funny: throw moar compute at it

[wintermute000]

I was trying to run up INE's CCIE SP topology on VIRL. This consists of 10x CSRs and 4x IOS-XRvs, all of which need 3Gb each.


Now my VIRL was running on workstation on a 32gb RAM desktop which I though was adequate, but the lab would take ages to start, and I would always have two or three routers shut down shortly after booting up. This was unexpected as one of the things Cisco introduced in the recent versions was over-provisioning, and according to the management UI, I had heaps of (overprovisioned) RAM left. Coming from a vsphere background, I thought overprovisioning was fine, it should page share, balloon etc.... like how people squeezed 20+ CSR VMs onto 32Gb hosts...


Various openstack messages were debugged, forums trawled, settings tweaked, VMs rebooted, etc.

two hours later I gave up and ran up VIRL on my ESXi and threw 12 cores and 64Gb at the VM. BAM! Everything humming along as it should with nary a peep of complaint. VM RAM usage hovers around 45Gb. in case anyone doesn't realise, Cisco's updated their terms of use to allow you to install your license on ESXi and workstation as long as you don't use both concurrently. Despite the convenience and power saving, I don't plan on ever going back to workstation!

Lesson: do not rely on VIRL's overcommit - it does not act like a bare metal hypervisor and handle overprovisioning. maybe CPU had a hand in it too, was getting nasty messages about RPC calls timing out or taking unexpectedly long, etc.

[deanwebb]

Good to know... thanks!