add nexus 9000v and vsrx support

[carlmontanari]

Since this is already done and working, I'm skipping the issue opening part -- feel free to close this or let me know if you would like to see any changes.

Tried to pretty much stick to the standard formula here. The vSRX stuff was lovingly stolen from #140, I did have to increase the memory for it to boot nicely though. I also removed the script to pull from the box image as redirects were breaking it and the image is fairly old anyway.

N9kv bits require the BIOS image, since its super tiny I just included it here so there is a known good version rather than wget it from somewhere as you had done in the testing branch from a while back.

Carl

[plajjan]

Thank you!

I wonder why I never merged #140. I think I've just missed it :/

I strongly prefer using authors original commits though (sort of how git was intended to work), so I think I will be merging #140. Will read through an extra time. If you had based your work on his (rebase on his branch, merge it in or just cherry-picked the relevant commits) and then made your changes on top, that would be much better (merging this would conceptually be like merging #140 and also including your changes on top). By copying the content of the files rather than bringing in git commits, you sort of hide the history.

You've included this OVMF binary file. Who produces that? License? Regardless of size, we have to be sure that we have permission to distribute it :)

Thanks for your work, I'll try reading through the diff soon.

[carlmontanari]

Understood on all counts! Once you've reviewed let me know and I can close this and open a PR for just the nexus bits with any necessary edits. For the vSRX piece I did have to crank the ram up to 4096 to get it to happily boot, and unfortunately the script to pull the box from Vagrant's hosted thing did not work for me (but was a nice touch and I'm sure it worked before!).

Regarding the OVMF file... good question! :) I've had it sitting around and am not 100% sure where I snagged it from, but I believe I just got it from the GNS folks here. Given that I don't have a good answer for this I can remove it and it can be an exercise for the user to get that from GNS or wherever else if you'd like?

Thanks for vrnetlab -- have been finally digging in lately and I wish I spent the time to dig in like a year ago!

[nanisyako]

I am still having trouble of booting nxs9kv, Carl I did follow your pull request but still booting just hang in unhealty.

[carlmontanari]

@nanisyako the nxos boxes boot very slowly. how long did you let it sit before trying to connect? I usually see somewhere around 7-8 minutes for the nxos devices to go to healthy state.

Also make sure you had the ovmf file when you ran the make container step, without that it'll never boot :)

[nanisyako]

it has been 14 hours in the unhealthy state. I did actually,I got the ovmf file even tho I don't know what it is from GNS3 and get the cisco nx9.3.1 from my cisco portal.

vrnetlab/vr-nxos:9.2 "/launch.py" 14 hours ago Up 14 hours (unhealthy)

[carlmontanari]

Cant really help w/out any information, and PR is probably not greatest place for this. In general you should be able to launch the host w/ qemu/kvm. If you can't do that you have something else wrong. So start there. Then connect to the console to see if its just booting over and over or if its hung or whatever. Also logs are your friend. Dont recall off the top of my head where I found them, but helped me immensely to see what was going on while getting things rolling.

[nanisyako]

Cant really help w/out any information, and PR is probably not greatest place for this. In general you should be able to launch the host w/ qemu/kvm. If you can't do that you have something else wrong. So start there. Then connect to the console to see if its just booting over and over or if its hung or whatever. Also logs are your friend. Dont recall off the top of my head where I found them, but helped me immensely to see what was going on while getting things rolling.

I just had to increase the memory to fix the problem btw. but not able to connect any ports more than 8 in nexus, any idea?

[danoost]

Hey folks, I've just stumbled across this PR while looking to submit my own... I've got Nexus NX-OS 9000v 9.3(7) (and I think 9.3(3) also) working well over at my fork, based on the work of @jpmondet at their fork.

It seems like nobody had found a good source for the bios.bin that makes all the difference, instead relying on committed blobs. I've found that it's a special build of Tianocore EDK II: specifically the OVMF-pure-efi.fd flavour (or maybe it just works with either this or one of the various blobs I've had success with). This can be found on their official build server, as discussed at the Cisco documentation. My fork includes a Dockerfile that will download and extract that BIOS, and pass it correctly to QEMU.

The EDKII bios is licensed as BSD+Patent, so there shouldn't be any licensing issues there.

Hopefully this extra information is useful to you, @plajjan. It would be great to see this VM merged in, regardless of which changeset ends out being the best. I can open a pull request for my fork, but I don't want to go stepping on @carlmontanari's toes too much 😉