@huanlu wrote:
Agenda
- Introduction to Packet from Adam Rothschild from the Packet.net team
- Tips and tricks to setting up your VIRL server on Packet's platformPlease note that this is phase 1 of the VIRL on Packet option. We are already working on UWM support for those that don't want to deal with entering commands in CLI and also are working with Packet to bring down the 30 minute set up time. We hope to have these in place in the next few months. Also, the boxcutter set up process also can be used with virtualbox if you don't have fusion/workstation on the machine in question.
Useful links:
http://virl.cisco.com/cloud/
Recording
Watch the session recording on the VIRL's youtube channel: https://youtu.be/MD8PJFmG8ZQ
You can also view past webinar recordings if you missed the parties.
Presentation Slides
Download the slides used in this webinar:
VIRL Personal Edition Webinar Feb 2016.pdf (870.0 KB)
Packet & Cisco VIRL - Packet Intro.pdf (11.3 MB)
Q&A
Q: I’ve heard and read many times "as low as $0.05/hour" - but what is the smallest instance that VIRL is supported on?
A: You can use that option (Type 0), but wWe would recommend the Type 1 bare metal system with 32 GB in RAM, which starts at $0.4.hr. See more on Packet pricing: https://www.packet.net/bare-metal/
VIRL also runs really nicely on the Type 3 system - 128Gb, but that may be an overkill unless you are spinning up the big virtual machines such as NXOSv or CSR1000v.Q: I experienced bare metal spin ups in about 8 minutes twice. So that's awesome. But unfortunately the remaining VIRL deployment took about 40 minutes. Any method to speed that up or to be able to save your "instance" for quick reinstall ?
A: No - these are baremetal systems, so there's on 'suspend and resume' capability. We are working with Adam and team on being able spin up much faster - hope to have something in place in the next few months. The speed up will come with custom image support that adam talks about in a couple of slides..the goal is total time <10 minutes
A: there is your custom image speedup in q3, we are hoping early q3Q: Does the packet environment expand your onsite VIRL (20+40=60 nodes)? Or does it run in place of your local VIRL? (0+40=40 nodes)
A: Hello Greg, if you mean when a packet instance is created do you now have a clustered VIRL server? The answer is no. Technically it runs in place of your local server.Q: Will you provide any details on the external networking connections for these bare-metal options? FLAT, FLAT1, SNAT connectivity to the outside world?
A: Essentially, that's all available either being plumbed to the outside ip address translated via the management interface. and flat will be bridged to your remote workstation via OpenVPN. Of course: there is no physical NIC that you can connect anything to. obviously :DQ: Are there advantages to choosing the method with the existing VIRL local server compared to the boxcutter variant? e.g. in deployment time or not having to change the web settings in VM Maestro?
A: no difference there -- just one way if you already have a VIRL installation and the other way if you are starting from scratch (no existing local server)
No speed difference between the 3 options 1. native terraform 2. boxcutter 3. virl server only a difference in how many files you need to edit and files (keys) you need to copy by hand
If you’re comfortable you can install terraform, git clone the repo, edit the files, apply. But suggesting this will get me stoned as a luddite by the 'everything in a gui its 2016' crowd.Q: If you go through this process that Alejandro just went through, how does the IP addressing get affected if you are not using the default IP addressing?
A: Basically when you launch on packet you must use default addressingQ: So if my server doesn't have enough RAM/CPU, I would use this method and rent out Packet compute resources? What if I just purchased VIRL, can I use Packets resources directly?
A: The "box cutter" method that they're talking about does not require a local VIRL installation. If you have not installed VIRL locally, you can use that method to use Packet resources.Q: Can you add other users besides guest and then have those users available next time you spin up the server?
A: yes, you can create new users and projects... and no, they will not persist across spin-upsQ: while a little off topic, can we get some sort of psuedo-official response to using Parallels on Mac for VIRL?
A: not yet, really because we dont have it in house to test it...Q: Can I install VIRL on my server and on Packet?
A: You can. the license, however, allows you to run only on one at the same time.Q: Hopefully we can setup precanned terraform files that would accomplish the same thing so you don't have to manually create the users each spin up. I'm thinking DFWCUG usage of Packet for Study Groups on weekends.
A: That's certainly a nice feature request.Q: Especially given the uncertain future of Fusion and Workstation products?
A: Yes this is concerning to us as well given our wide use of fusion and player and appcatalyst. Note that the boxcutter set up process also can be used with virtualbox if you don't have fusion/workstation on the machine in question.Q: Can you run VIRL locally and on Packet.net with same salt license?
A: yes, we are trying to be sensitive with our license duplicate checker just please if your on packet stay pointed at the packet salt master
A: Dont abuse us and we wont whine at you :)Q: The idea is to shut off the server when I'm not home and run it on the cloud
A: you can certainly do that -- just keep the cost of running this for an indefinite amount of time in mind :)Q: How is packet billed, monthly?
A: There is no monthly billing method for packet, they charge you on a hourly basisQ: It might require saving a UMW "users" file and copying it to the server as part of the spin up.
A: honestly beau i havent tested the virl.ini based user additions in quite some time since it basically wasnt used after uwm took over that role
Posts: 2
Participants: 1
