We are very pleased to announce the availability of Ravello Repo. Repo is a library of public blueprints shared by experts in the infrastructure community (individuals and companies), for the benefit of the rest of the community. These blueprints represent multi-VM snapshots of entire application environments with networking and storage. Anybody can copy a blueprint from Repo into their private library and spin up an instance of the application environment in Ravello (on AWS or Google cloud) with one click.

Repo use-case #1: Learning labs for everyone

Repo currently has blueprints of OpenStack labs, Puppet and Ansible testing labs, Linux version migration testing labs, Arista Networks testing labs and more. Anyone who is interested in learning about these subjects can use their existing Ravello account (or open a new Ravello account), and within 5 minutes have a full scale lab to study, practice, customize and use. Say you are studying for your VMware VCDX exams. Or you are practicing for your Cisco CCIE certification. You can use these blueprints as a starting point for a live environment or build and share your own blueprints. The lab environment runs in the public cloud (on Ravello on AWS or Google cloud) and users do not need any local hardware. Users can also edit these lab blueprints and contribute them back to the community via Repo.

Repo use-case #2: Simulating Data center labs for research

Infrastructure experts often need custom the data center labs for research. For example, say you need to see how OpenStack, Docker containers and Mesosphere and next generation firewall technology from Check Point or Palo Alto Networks could work together. With Repo, you can start with a full blown OpenStack environment and add and configure other components as required. Once everything is working well, document your findings and share it with the community.

Repo use-case #3: Labs for software or virtual appliance evaluations

Typically, ISVs have technical marketing and systems engineering teams build out reference architectures and implementation guides for their software. The intent is to help users set up the ISVs software according to the ISVs recommended best practices. For today’s users, that simply isn’t enough because:

• they lack the servers and networking hardware to build out lab environments per ISV specifications.
• they find that building the environments from scratch is difficult and error prone.
• it’s often difficult to get online help for the user’s specific configuration and setup.

With Repo, ISVs or their users can share complete blueprints with the community. New or existing users can spin up entire lab environments without any hardware. This speeds up the evaluation process for users and the sales cycles for the ISVs. Users can also customize their environments and easily share it with the ISV or the broader community to assist in case of problems.

Repo doesn’t cost anything

There is no charge to copy a blueprint from Repo or to post a blueprint to repo. Once a user copies a blueprint from Repo into their own Ravello account, they will be charged a nominal storage cost (typically a few cents per month) to store the blueprint in their account. They only pay for compute and volume storage when they run an application instance from the blueprint in their Ravello account.

We’d love to hear your feedback - once you’ve checked out the blueprints on Repo, let us know what you think and what else you’d like to see there - via twitter @ravellosystems or in the comments section below.

The post Introducing Repo: A community repository for infrastructure blueprints appeared first on The Ravello Blog.

Dear vExperts,

You are the pioneers of learning and sharing your knowledge to guide the entire VMware community. In order to support and accelerate innovation in the virtualization community, Ravello is excited to announce a free lab service for all 2015 vExperts. The estimated value of this cloud-based lab is $2500 per vExpert per year - and Ravello is picking up the tab in full for this party. In case you were wondering why its for current vExperts only, the reason is simple - we are a relatively young company with limited funding. But we invite VMware and the partners in its ecosystem to join us and contribute towards making free VMware labs available to more vExperts.

What is Ravello’s Free Lab Service for vExperts?

We hope our free lab service will provide you with additional resources, flexibility and agility to achieve your goals. Our mission is to enable you with smart labs to test new virtualization products and features, and collaborate and share complex designs, architectures and best practices - through which we hope that the entire VMware community can benefit. You can learn more and activate your free lab service here. In a nutshell:

1. Starting today, each 2015 vExpert gets 1,000 free CPU hours per month on Ravello (with AWS/Google Cloud capacity included) for personal or home lab use. You can run full fledged VMware labs with vCenter, multiple ESXi nodes and other VMware and partner products such as VSAN, NSX, Veeam etc in your Ravello lab.
2. For the next one year, each month, your Ravello account will be topped up with exactly 1,000 free CPU hours in a “use it or lose it” model -the hours don’t rollover so we encourage you to make the most of your free lab each month.

It’s been an exciting few months at Ravello

We’ve been keeping busy and having fun the last few months. Here’s what we have been up to:

• Running VMware workloads on AWS/Google: Our nested hypervisor, HVX, is still the only way to run VMware workloads unmodified on AWS/Google Cloud (running as a vmdk with all its VM drivers, networking etc intact). We are helping lots of customers who have massive VMware environments but want to clone their dev/test, CI, sales demos and PoC environments in the public cloud for agility & cost reasons.
• Running the VMware hypervisor itself - ESXi on AWS/Google: We literally took things to the next level by enabling hardware extensions such as Intel VT and AMD SVM in the cloud which allows third-party hypervisors such as ESXi and KVM to use public clouds like AWS and Google just like hardware. This is also an industry-first and currently the only way to run ESXi on AWS (join our beta). We got some fantastic feedback from the community and we humbly thank them for their support & guidance.
• Giving back to the virtual community: We started with a pilot program for vExperts a few months ago and now we are officially launching Ravello’s free lab service for all 2015 vExperts, where the underlying cloud capacity from AWS/Google is fully funded by Ravello. I’m personally super excited about this and look forward to working with you and hearing from you. We also just launched Ravello Repo a place to share infrastructure blueprints built by the community, for the community. Anybody can spin up their own copy of the application environment in their own Ravello lab with one click using these blueprints. Repo already has OpenStack, Arista and ESXi Autolab blueprints available for free download and we are eager to see what else you folks will come up with!

Let’s take virtualization to the next frontier.

Cheers,
Team Ravello

PS: On a side note, we’re looking for rockstar TMEs with strong technical backgrounds to join team Ravello - please email us at pm@ravellosystems.com

The post Ravello’s Free Lab Service for all 2015 vExperts appeared first on The Ravello Blog.

Splunk is a SIEM market leader with an active ecosystem of resellers, application developers, partners, customers – all of which need a Splunk lab for sales demos, customer PoCs, training and development testing. Ravello's Network & Security SmartLab presents an option to set up Splunk labs on public cloud - Google & AWS at costs starting $0.14/hour.

Splunk – a SIEM market leader

Gartner has identified Splunk as a market leader in Security Information & Event Management (SIEM) segment which has seen a phenomenal growth (16% Y/Y) in recent years. The key reasons for this growth –  an increase in disparate machine data present in enterprises, and recent cyber attacks & data breaches. Enterprises are struggling piece together machine data, logs, events from multiple sources to gain meaningful insights into the state of their systems, network and security. Integrating with multiple third-party technologies, this is where Splunk shines. By analyzing everything from customer clickstreams and transactions to security events and network activity from a wide variety of nodes and network & security appliances, Splunk paints a holistic picture for IT Ops.

Everyone needs Splunk environments

Splunk has a large ecosystem of loyal customers, resellers, partners and application developers. Many network, security, and information system ISVs integrate with Splunk’s solution. Splunkbase – Splunk’s App Repository – reveals 762 specialized applications that cover a wide range of functions ranging from Application Management, IT Ops, Security & Compliance, Business Analytics to Internet of Things. Each of these application developers/ISVs require a fully functional Splunk environment comprising of multiple appliances, LAN hosts, network nodes (log/event sources), complete with Splunk Enterprise & Data Collection Machines for their sales demo and development test environments. Splunk resellers and partners also need environments to deploy multi-tier, multi-node hosts to showcase the power of Splunk in a ‘real-world-like’ setting. Customers looking to purchase SIEM tools also need PoC environments where they can evaluate the capabilities of the Splunk in a production-like environment before making a buying decision.

Where can I setup my Splunk lab for demos, PoCs, training?

ISVs, resellers, enterprises have explored provisioning their data-centers to run these transient workloads for sales demo, PoC, training, upgrade & development test environments, and have experienced a sticker shock – it is expensive! In addition, it takes weeks to months to procure, provision the hardware, and get the environment running, and then there are opportunity costs associated when the environment is not being used.

Public clouds, such as AWS and Google are ideal for such transient workloads – providing the flexibility to move to a usage-based pricing to avoid these opportunity costs. Splunk has an AMI (Amazon Machine Image) that allows it to run on AWS. And while it is excellent choice for ‘cloud native’ deployments, it doesn’t lend itself very well to mocking-up a production datacenter environment –  a requirement for Splunk demos, customer PoCs, application development & testing use-cases. AWS networking limitations (e.g. lack of support for Layer 2 networking, multicast and broadcast etc.) make it impossible to mirror data-center environments on public cloud natively.

A nested virtualization platform with software defined networking overlay – such as Ravello – brings together the financial benefits of moving to cloud while avoiding technological limitations. Running workloads on Ravello Network & Security SmartLab brings all the benefits of running in datacenter  – one can use the same VMware and KVM VMs with networking interconnect. And, since Ravello is an overlay cloud running on top of AWS & Google, one also reaps the economic and elastic benefits of Tier 1 public cloud. In essence, using Ravello, Splunk and its ecosystem of application developers/ISVs and customers can run sales demos, PoCs, training environments in datacenter-like environments without investing in hardware resources.

Steps to create Splunk environment on Ravello

I used 3 VMs to create a representative Splunk environment on Ravello – first Windows 2012 to install Splunk Enterprise (indexer), second Windows 2012 to install Splunk forwarder for data collection, and a third VMware Data Collection Node (DCN) node.

Uploading the 3 VMs to my Ravello Library using Ravello Import Tool was simple.

Ravello VM uploader gave me multiple options - ranging from directly uploading my multi-VM environment from vSphere/vCenter to uploading OVFs or VMDKs or QCOW or ISOs individually. I chose to upload my Windows VMs and DCN as an OVF.

Verifying settings

1. Verification started by asking for a VM name for the Windows VMs
2. Clicking ‘Next’, I validated the amount of resources (VCPUs and Memory) that I wanted my vSRX to run on.
3. Clicking ‘Next’, I was taken to the Disk tab. It was already pre-populated with the right disk-size and controller.
4. Next I verified network interface for the Windows 2012 Server. I chose it to have a DHCP address. Ravello’s networking overlay provides an inbuilt DHCP server.
5. Clicking ‘Next’, I was taken to the Services tab. Ravello’s network overlay comes with a built-in firewall that fences the application running inside. Creating “Services” opens ports for external access. Here, I created “Services” on ports 3389 and 8000 to open ports for RDP and Web access to Splunk web interface
6. I went through the steps 1-6 for the other VMs

Publishing the environment to AWS

1. With my application canvas complete, I clicked ‘Publish’ to run it on AWS. I was presented with a choice of AWS Regions to publish it in, and I chose AWS Virginia. My environment took roughly 5 minutes to come alive.
2. Once my VMs were published, I installed Splunk Enterprise on first Windows 2012 and Splunk Forwarder on second Windows 2012. Upon installation, I could login to the Splunk interface to be able to configure my data sources and get Splunk forwarder to send data to Splunk indexer
3. Once Splunk had finished indexing, I was able to see dashboards and execute searches.

Conclusion

Ravello’s Network & Security SmartLab offers an unique and simple way to create data center representative Splunk environments (without hardware investments) on AWS & Google. Just sign up for a free Ravello trial, and drop us a line. Since we have gone through the setup recently, we will be glad to help you create your own Splunk lab on Ravello.

The post Splunk demo, PoC, training environments with L2 networking on Google & AWS appeared first on The Ravello Blog.

Author:

Michael J. Clarkson Jr.

President at Flakjacket Inc., Michael is Red Hat Certified Architect Level II (E,I,X,VA,SA-OSP,DS,A), Cloudera Certified Administrator Apache Hadoop

OpenStack Kilo Blueprint

Now that Kilo has had a bit of soak time and with the next release of Red Hat OpenStack Platform to be based on it I thought it time to revisit OpenStack. Using the same methods as the Juno installation from my previous blog entry, I set up Kilo running on CentOS 7 using the RDO Packstack based release. The blueprint is now available on Ravello Repo, ready for you to kick the tires. The answers file lives in /root/answers.txt on the controller node. Copy the blueprint to your account and go nuts. The VMs have cloud-init so you will need your SSH keypair. The default user for SSH with the keypair is centos. Password for the root user and the OpenStack users admin and demo is ravellosystems. Once the instance is deployed the Horizon UI is available at https://PUBLIC.IP.OF.CONTROLLER from any modern browser. Just accept the self signed certificate at the warning screen.

Get it on Repo

REPO by Ravello Systems, is a library of public blueprints shared by experts in the infrastructure community.

What’s new in Kilo?

There are a lot of improvements and bugfixes in existing services as well as some new projects beginning to see tech preview adoption. Some of the high points are:

• Nova performance optimization takes better advantage of the hypervisor’s tuning options.
• Better support for hypervisors including VMWare, Hyper-V, and of course KVM.
• NFV features including CPU pinning for VMs, large page support, and NUMA scheduling.
• Flavor support for Ironic.
• Support for Federated authentication via Web Single-Sign-On.
• Trove DBaaS resizing support.
• Tighter Ceilometer integration.
• Improved VXLAN and GRE support in Neutron.
• Subnet allocation in Neutron for better control of which projects are on which subnet/vlan.
• Tons of new Neutron ML2 plugins.
• Tighter integration with Ceph and Gluster for backending Cinder and Glance.
• Better support for Ceph as a full replacement for Swift.
• Improved Heat functionality including nested stacks.
• Project Sahara now has full support for Hadoop CDH, Spark, Storm, MapR, HBase, and Zookeeper.
• Many, many more.

Here are the release notes.

Ravello Repo

What is this Ravello Repo I mentioned earlier? As part of the rollout of our free service for current North American RHCEs, we created a centralized repository on which Ravello users can share the amazing blueprints they create with others in the community. The success of the open source model is proof that sharing is caring and on Repo we continue in that spirit. The Repo is available to any Ravello user and sharing is encouraged. All of the blueprints I’ve referenced on previous blog entries are there along with labs for vSphere, Arista Networks, and Mirantis OpenStack. Come join the party!

Free Service for North American RHCEs

Do you have a current RHCE? Are you from somewhere in North America? We have a free service for you to reward your hard work. Free for personal use you get 1000 vCPU hours every month. This is a use it or lose it service, but you can use the hours as you see fit (as long as you don’t violate our Terms of Service). Sign up here.

The post OpenStack Revisited – Kilo Ravello blueprint to build lab environments on AWS and Google Cloud appeared first on The Ravello Blog.

Author:

Dr. Nate Brady
Systems Engineering Manager at Skyhigh Networks

Nate is a Systems Engineering Manager at Skyhigh Networks managing a growing team of SEs based out of US. Nate is an expert in Networks, Security and Risk Management domains

Skyhigh Networks

Skyhigh Networks is the leading Cloud Access Security Broker (CASB) facilitating secure adoption of cloud-based services. Our solution is two fold: Skyhigh for Shadow IT enables enterprises to detect over 13,000 cloud services that employees may be using and complement usage statistics with a 50-point risk assessment for each service as well as a full workup on usage, anomalous usage, and integration with existing perimeter devices to block access or warn users of impending danger. Skyhigh for Sanctioned IT facilitates cloud adoption by extending traditional controls, such as sharing policies, audit logging, and data loss prevention (DLP) to common cloud services such as Salesforce.com, Box, Office 365 and many others. Our frictionless deployment model has helped us to gain a strong customer base comprising of over 300 enterprises many of which appear on the Fortune 500 list.

Ravello to the rescue: SE Training and Customer Mock-Ups

As a SE manager at a company growing as fast as Skyhigh, I needed a way to let new systems engineers immerse themselves both in Skyhigh’s own technologies as well as those commonly deployed at our customers. For example, Skyhigh for Shadow IT integrates with common proxy and firewall technologies to add intelligence about cloud service risk to existing policies. Additionally, Skyhigh for Sanctioned IT allows customers to extend the reach of common DLP systems, such as Symantec and McAfee, to the cloud. While these integrations make life easy for our customers, it means that our SEs need to have a working knowledge of many different technologies. This is where Ravello has been our savior.

Using Ravello, we can build complex environments either from templates or entirely from scratch. This means that new SEs can quickly come up to speed by deploying use case specific training templates and seasoned SEs can create mock-ups of customer environment in almost no time.

With Ravello, we are able to provide new SEs with a “lab in the cloud” on their very first day. All they need is a web browser and an Internet connection and they can build anything from a simple proxy server to a complex security infrastructure including firewalls, proxies, DLP and SIEM as well as server and desktop infrastructures.

In some cases, customers ask see our product deployed in very specific circumstances but struggle to provide a dedicated lab environment for us to conduct a proof of concept. Ravello allows us to create these environments quickly and securely on behalf of our customers, saving them time and resources while also helping to shorten the sales cycle significantly.

While the environments vary from one enterprise to another, typical customer deployments feature at least a firewall, proxy, active directory, DLP, and some Windows servers and workstations – adding up to upwards of 14 CPUs and 32GB RAM. Then it all has to be connected in the typical route/switch environment that is familiar to the datacenter but foreign to IaaS providers.

With Ravello – our engineers can have their own lab in the cloud which allows to them to learn new technologies and mock up customer use cases on without having to contend for resources - in a cost effective manner. This is phenomenal!

Dr. Nate Brady
Manager of Systems Engineering, Skyhigh Networks

Once again, Ravello to the rescue! Not only does Ravello make the creation of these environments a snap, it’s far more cost effective. By running an extra layer of virtualization, Ravello can fit several small virtual machines onto a single large instance.

Skyhigh Networks’ Requirements

To provide a great toolset to our engineering community as well as make life easier for our customers, we had some very special infrastructure needs:

• No CapEx investments – We experience variable workloads depending the SE and customer. As a SaaS company, we wanted to avoid maintaining a fixed-capacity datacenter and cost-effectively leverage the utility of the cloud.
• Scale on-demand – To accommodate for spikes demands, we wanted a platform that could scale without impacting the customer’s PoC experience.
• Zero change deployment – A large number of our technology partners provide VMware appliances. It was extremely important to be able to deploy these systems in the public cloud without any changes.
• Infrastructure templatization - To facilitate quick development of training and mock-up environments, we needed a way to templatize common environments to be used as a starting point for customization
• Ease of collaboration - We wanted a platform that made it easy to collaborate with prospects so that they could verify that the mock-up was configured to their specifications.
• Usage-based costs – To reduce the overall cost of sales, the Skyhigh team was looking for a strictly usage-based pricing model.

We considered several options that partially satisfied some of these requirements. We looked into developing ‘PoC hardware kits’, but quickly moved away from this idea due to logistical challenges associated with shipping hardware to every SE in the company (and potentially some prospects, too!) Next, we evaluated using private cloud providers to host these environments but could not justify the high fixed costs involved. Public clouds were also considered, but the inability to run native virtual appliances, limited access to virtual machine consoles, and a lack of availability of L2 networking features made this unfavorable.

Ravello is really flexible - we can take any of our VMs and run them on public cloud and access them just like we would in our own labs - down to the console access. These capabilities allow us to use our existing knowledge about virtualization platforms like VMWare and apply them to cloud instances rather than relearning a new technology – drastically reducing learning curves for our engineers.

Dr. Nate Brady
Manager of Systems Engineering, Skyhigh Networks

Ravello - a perfect match for Skyhigh’s needs

We tried Ravello for one of the PoC setups, and were very happy that Ravello delivered on all our needs.

Since Ravello runs on AWS & Google cloud, we were able to create PoC environments without investing in hardware or building our own datacenter. Ravello runs on Tier 1 clouds where there is no shortage of capacity, quota or overage concerns – we were able to scale our PoC environments on-demand – spinning as many environments as needed. Further, Ravello’s HVX (high performance nested hypervisor) and networking overlay allowed us to run our existing VMware appliances and VMs without making any modifications – this really helped in reducing the learning curve.

Quick deployment of training and PoC environments is crucial to our sales cycle. Thanks to Ravello’s blueprint feature we were able to ‘templatize’ several environments, and use it as a starting point for customization for PoCs – saving us days of work. With Ravello’s network overlay, we were able to recreate the same network topology as our prospects production environment down to the very subnets and IP addressing. Further, with Ravello’s user-permissions feature we were able to selectively share applications with our prospects and collaborate on developing PoC environments quickly – speeding up the sales process. Finally, with Ravello’s usage based pricing, we were paying only for the duration when our PoC & training environments were up – which significantly helped in containing costs.

Overtime, we have standardized on using Ravello for PoC environments for a vast majority of deployments.

Benefits realized with Ravello

I’d like to highlight some of the benefits realized through Skyhigh’s adoption of Ravello as the platform of choice for our customer PoCs

Shortened sales cycle - With an on-demand access to Ravello’s environment with rich networking capabilities, the Skyhigh team does not have to rely on prospect’s environment to showcase its service in action. Eliminating this dependency has helped compress our sales cycle.

Reduced effort for lab environments - With re-usable topologies (blueprints) being used as a starting point for lab environments, we have been able to eliminate many of the repetitive tasks gaining improvement in efficiency for setting up new labs and customer mock-ups.

Effective sales engineer training & on-boarding - Encouraged with the success in using Ravello for training our SEs, we have begun using Ravello to create mock-up environments for customers who request them. Easy access to ‘disposable training labs without penalty’ has enabled our SEs to hone their skills, and has also helped in onboarding new SEs quickly.

The post Skyhigh Networks – On-demand customer PoC environments on AWS & Google Cloud appeared first on The Ravello Blog.

The last time I started learning what VMware was all about, I stopped at the high-level theoretical overview of the availability, scalability, management and optimization challenges that VMware technologies help organizations overcome. Having no physical servers at my disposal, the first time I went through the long list of VMware technologies vMotion, High Availability, vFlash and all the others - I didn’t do anything. This time, however, I used my ESXi lab set up on Ravello to try to get something done. The result: I migrated a VM using vMotion from one ESXi host to another.

I won’t bore you with my summary of the study guide I’m using to understand the differences between Fault Tolerance and High Availability or my (hopefully effective) ways to remember what DPM or SIOC stand for (if you’re studying for the VCA-DCV, drop me a line if you care to share notes). Instead I wanted to share what I needed to know to migrate a VM using vMotion and how I did it.

First - while I did learn what vMotion is supposed to do - I had no idea how it is actually done. What needs to be configured where, and how. I started with knowing that I will need a set up that consists of (at least) two ESXi hosts, so that I can migrate a VM from one to another.

My ESXi lab

For this I used my basic lab, consisting of two ESXi nodes, vCenter, an NFS server and a Windows client running my vSphere client (I could have used the vSpere web client, but this was my basic set up so went with that).

I previously created and saved his whole ESXi lab as a blueprint in my Ravello library, so I didn’t have to upload, install or configure anything. I used the blueprint, and published an application from it - basically running a nested ESXi lab on Google Cloud. A few minutes after I hit publish - I could console into my Windows Client and run vSphere, where I had my two ESXi hosts already configured, as well as several VMs that I created there in the past. One of them - ubuntu cloned VM (not the best name, yes) - was already running.

Poetry in vMotion

Since I didn’t know anything about how to actually use vMotion, I searched for some resources and found a video from VMware that was fairly useful in pointing me to the “migrate” option on the VM. However, when I tried to do that, the vMotion option was greyed out, saying that the host the VM was running on wasn’t enabled for vMotion. With a little digging around and a little help from my friends, I realized that I needed to configure the switch on the hosts to enable vMotion.

As you can see from the following set of screenshots, once I enabled vMotion on the host, I was able to migrate my running VM using vMotion. I celebrated with this song.

VM on ESXi host 1
Change host
New location
Migrating VM
VM running on ESXi host 2

Next time - a deep dive into vSphere core components. If you are also working on your VCA or VCP certification and have cool tips, useful guides and especially - if you have ideas for good hands-on exercises or are using Ravello for your VCA, VCP or VCDX study labs - let me know!

The post My Virtual Way: Lab to migrate a VM with vMotion (and still without hardware) appeared first on The Ravello Blog.

Author:

Mirko Grabel

Mirko Grabel is a ‘Kick-Ass’ Technical Marketing Engineer with Cisco, and an active CCIE certified speaker at Cisco Live. He has global technical responsibility for ISR, CSR and ASR product lines.

Cisco’s Cloud Services Router (CSR) running IOS-XE is a very popular network appliance used in a variety of scenarios – as a VPN gateway, as a MPLS termination, to connect DCs, to provide an internet split-out for branches, to connect branches to HQ. Coupled with LISP, CSR can also be used to extend the DC with hybrid cloud infrastructure. There are numerous ‘how-to’ articles on the web that articulate how CSR can be used to connect cloud infrastructure to DC or HQ to secure hub-to-spoke or spoke-to-spoke traffic with DMVPN and IPSEC. To create topologies for these use-cases, however, one requires infrastructure to run the CSR routers and networking interconnect to connect them.

In most organizations, it takes weeks to months to procure and deploy new hardware – servers, racks, switches, and it is expensive. CSR’s Amazon Machine Image (AMI) offers an alternative to try out some of CSR features without having to invest in physical hardware. However, due to networking limitations on AWS (e.g. broadcast and multicast packets are heavily filtered, L2 unavailable), many CSR features are unsupported without tunneling on the AMI (e.g. OSPF, IGMP, PIM, OTV, VxLAN, WCCPv2, MPLS, EoMPLS, VRF, VPLS, HSRP). Further, only one network interface can be configured as DHCP. This presents a difficulty in creating full-featured CSR environments that I need as a CCIE to play with different features, and mock-up PoC environments.

This is where Ravello helps. Ravello is a SaaS solution powered by nested virtualization and software defined networking overlay. Ravello enables networking professionals like me to create full-featured networking labs with a multitude of networking & security of VMware or KVM appliances (including Cisco’s CSR 1000v!) on top of public cloud (AWS or Google Cloud), and benefit from unlimited capacity and usage based pricing. Ravello’s software defined networking overlay exposes a clean L2 network – just like a DC environment – and offers built-in network services such as DNS, DHCP, Firewall, Virtual Switch and Virtual Router – should I need it. Further, it allows me to bring in my own router (CSR 1000v in this case), if I want specialized network functionality as a part of my environment.

Connecting DCs in the Cloud

A little skeptical of the tall claims made by Ravello, I decided to put Ravello’s Network Smart Lab to test. (Data-center functionality – running VMware & KVM VMs with L2 access – at public cloud prices and flexibility just seemed too good to be true!) I embarked on creating a CSR deployment connecting two different data-centers through VPN tunnel on Ravello. To emulate a DC, I added some LAMP servers and pointed CSR to be their Gateway on Ravello. With a click, I made two copies of this setup and associated public IPs to CSR’s external network interfaces. Using Ravello’s ability to run VMs in multiple clouds, I published one of the copies of my setup to run on AWS and another in Google. Once both environments were up and running, I configured each CSR instance in AWS and Google cloud to point to the other’s public IP, and voila – my two DCs running on AWS and Google were securely connected!

The rest of this article details configuration to get my multi-DC environment connected through CSR 1000v on Ravello.

Environment Setup

Getting this environment set up on Ravello involved 4 simple steps –

• Uploading my CSR 1000v and LAMP servers to Ravello
• Configuring networking on CSR VM
• Publishing the environments on AWS and Google
• Configuring the CSR

1. Uploading VMs

I used the Ravello Import Tool to upload all 3 of my VMs. Ravello’s VM uploader gave me multiple options - ranging from directly uploading my multi-VM environment from vSphere/vCenter to uploading OVFs or VMDKs or QCOW or ISOs individually. I uploaded my CSR1000v as an QCOW image.

2. Configuring Networking

Upon uploading the CSR 1000v, Ravello asked to confirm the resources (CPU, Memory, Storage) for my VM. Since Ravello had already identified the resources, it was more of a verification exercise.

[column size="1/2"][/column]
[column size="1/2 last"][/column]

Clicking on the Network tab, I added two network interfaces to the CSR – one each for internal and external networks. I configured a static IPs on the interfaces and chose “VirtIO” as the device type. I also associated ‘Elastic IP’ to the external interface so that I could access it from anywhere.

[column size="1/2"][/column]
[column size="1/2 last"][/column]

To enable SSH access to my VMs, I opened port 22 in the “Services” tab.

Next, I created an ‘Application’ on Ravello. An ‘Application’ in Ravello’s terms is essentially a multi-VM environment. To create my DC, I dragged and dropped my CSR and LAMP VMs on the application canvas.

Next, I saved my application as a ‘Blueprint’ – which was similar to taking a snapshot of the entire multi-VM setup. Blueprint enabled me to make additional copies of this ‘application’ environment.

3. Publishing environment on Google & AWS

With blueprint of this environment in hand, I was able to create two application copies. I modified the IPs on the second copy so that it didn’t conflict with the first copy. Next, I published an instance of each to run in Google Cloud and AWS respectively. Publishing the application was a piece of cake – a one-click action.

4. Configuring CSR

With my DC environments set up in AWS and Google cloud, the next step was to configure the CSR to connect the two environments through a VPN tunnel. Here is how I configured the CSR for this environment using CLI.

Defined the hostname first

hostname CSR1000V-AMAZON

For convenience’s sake if I mistype something, I disabled domain lookup.

no ip domain lookup

To get SSH access, I needed a domain name, so I set one up.

ip domain name ravellosystems.com

Next, I generated SSH key pair

crypto key generate rsa

Then configured a username & password for CSR

username admin privilege 15 password 0 XXXXXX

Next I allowed SSH on the incoming lines

line vty 0 4
login local
transport input ssh

To give out IPs to my client VMs, I also set up a local DHCP Server

ip dhcp excluded-address 10.0.2.0 10.0.2.9

ip dhcp pool DHCP
network 10.0.2.0 255.255.255.0
default-router 10.0.2.1
dns-server 8.8.8.8

And here comes the tricky part – how to get the IPSEC tunnel to fly. Here is the full config required for this. Details for each command can be found in the Cisco config guides.

crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key PASSWORD address 0.0.0.0

crypto ipsec transform-set TRANSFORM_SET esp-aes 256 esp-md5-hmac mode tunnel
crypto ipsec profile 1
set transform-set TRANSFORM_SET

interface Tunnel0
ip address 192.168.255.2 255.255.255.252
tunnel source GigabitEthernet1
tunnel mode ipsec ipv4
! The tunnel destination is the elastic IP of the other side!
tunnel destination 85.190.189.58
tunnel protection ipsec profile 1

Here is the simple IP interface configuration, nothing fancy...

interface GigabitEthernet1
description EXTERNAL
ip address 192.168.0.3 255.255.255.0
negotiation auto

interface GigabitEthernet2
description LAN
ip address 10.0.2.1 255.255.255.0
negotiation auto

My default route points to the internet (required to find the other Elastic IP) and my inter DC traffic (just traffic going to 10.0.1.0/24) points to the other side of the tunnel:

ip route 0.0.0.0 0.0.0.0 192.168.0.1
ip route 10.0.1.0 255.255.255.0 192.168.255.1

The tunnels are on-demand tunnels so they only come up once traffic is present. Also to see some counters increase, I created 2 SLAs – one that works just in the tunnel and one that pings end-to-end from one LAN to the other.

ip sla 1
icmp-echo 10.0.1.1 source-ip 10.0.2.1
frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 192.168.255.1 source-ip 192.168.255.2
frequency 10
ip sla schedule 2 life forever start-time now

To check if my CSR sees the right interfaces I have to type this tedious long command. So, I made an alias for it –

alias exec sps show platform software vnic-if interface-mapping

Upon doing a similar configuration on the CSR running in Google Cloud (and pointing it its peer in Amazon), the two DCs were securely connected through a VPN tunnel.

Verifying it works

To verify that this setup works, I typed in sh ip sla stat. Increase in the number of successes for the counters confirmed that my VPN was setup and active (hurrah!).

Conclusion

Ravello’s Network Smart Lab offers an unique and simple way for networking professionals to create full-featured CSR environments for PoCs and network design (without needing hardware investments) on AWS & Google. Drop me a line if you would like to play with my CSR Blueprint setup.

The post How to emulate DCs in public cloud and connect them using Cisco CSR 1000v? appeared first on The Ravello Blog.

I was on the phone with Chris Porter today (side note - I was quickly impressed with his knowledge) and he made an interesting point about running dev/test workloads in the cloud. “If my production is on AWS, I’d certainly want to run my dev & test there”, he said. “But if my production is on premises on VMware, I’d like dev/test environments in the cloud that can be turned on and off on demand but the problem is they need to be very very similar to my on prem production deployment” . It sparked an interesting conversation on migrating from VMware to AWS, on cloud migration tools, cloud networking constraints, when to re-architect an application for a full-fledged production application migration process and how to approach the problem when it’s for dev/test only.

I’m a huge advocate of the no-migration approach to moving dev & test workloads to the cloud- in fact I may be guilty as charged for coining the phrase “Migration is for the birds, my VMs are nested” but the fact remains that when you need to move your dev & test workloads to the cloud, you do need to consider the various scenarios and migration options out there. Ravello’s nested virtualization approach puts us in an entirely different category - we are a cloud provider that provides VMware-like or KVM-like environments in AWS/Google Cloud. As a result, we haven’t had too many conversations with customers about some of the migration tools out there such as Racemi, CloudVelox, Hotlink but we do guide customers to use the AWS import utility to convert VMs, re-do their networking and re-think their application architecture if they are migrating their entire production application to AWS. But when they are looking at migrating dev & test workloads to the cloud, we (obviously) strongly recommend Ravello.

To summarize, here is a quick cheat sheet I came up with:

If you run your production on premise - say on VMware for example - then you have ample reason to migrate your dev & test to the cloud. The promise of just-in-time environments that can be created and destroyed on demand, coupled with never having capacity constraints (yes, no more QA environment bottlenecks as you get closer to release) is sufficient justification. However the challenge has always been the issue of high fidelity dev & test environments. How do you have confidence in your test results if the environment in the cloud looks very different from your on-premise production environment? This is why increasing number of VMware customers are turning to other VMware based clouds such as vCloud Air, or vCloud partner cloud providers so that they can get similar environments on premise and in the cloud. Some would argue that it’s not the same as having the price, reliability and flexibility of some of the leading clouds in the world such as AWS & Google Cloud. And I would argue that Ravello has stretched the “sameness” frontier by recreating VMware and KVM like environments in AWS & Google by using nested virtualization. Majority of Ravello’s customers such as 888 Holdings are running their production on either VMware or KVM in their private data center and instead of converting their VMs or modifying the networking in their dev/test environments to run them on AWS, they simply “nest” them as-is on Ravello.

If your production and dev/test is already in the cloud - migration is a moot point isn’t it? And if your production is on-premise and dev/test is already in cloud, you seem to be on the right track as long as you haven’t changed your dev & QA environments to “fit” them to the cloud of choice. And finally if your production is in the cloud and for some strange reason your dev/test is on premise, you better have a very good justification because in terms of capacity utilization it’s not ideal to have your prod running 24x7 in the cloud while your dev & test workloads which tend to be more bursty are running in house.

In any case, I'm eager to hear your thoughts on running production on premises on VMware and your dev/test workloads on AWS. How did you approach the problem? And shameless plug..but you do get a 14-day free trial if you'd like to try Ravello for dev/test.

The post Migrating dev & test workloads from VMware to AWS appeared first on The Ravello Blog.

There is a funny analogy between TV and self paced learning. How many of you are still watching only regular cable - without any DVR, without any on-demand content? Very very few, I bet. And I’m sure most of us have wondered- is this the future of TV? Everything on-demand?

I feel the exact same way about software training courses. No doubt instructor-led and classroom courses have their advantages but self-paced learning is quickly becoming a necessity for every software course today. Before I jump into the reasons, let’s look at this 2 min video by Hacker Academy. Big shoutout to them - they are one of the smartest bunch of people I have come across. In this video they show you how their self-paced security training automatically spins up live just-in-time lab environments for students across the globe. The best part is not just the zero touch provisioning but also the fact that labs are fully configured for the associated module and then self-destruct after a set time. Wow. Future of security training indeed.

Hacker Academy walks through student & trainer flows for their online security labs

[video url="https://www.youtube.com/watch?v=O8r4W8zwqjg"]

Top 5 reasons self-paced learning with smart labs are all the rage

1. Anytime, anywhere learning- duh, no brainer right? Everybody is busier than ever and users are increasingly happier with with self-paced learning that they can consume on their own schedule than having to block their schedule.
2. Hands-on learning - if I had to choose between self-paced labs without labs and an instructor led course with a lab, I’d definitely choose the latter. I’ve always been a huge fan of learning by doing. But when you give me a lab to learn and play with on my own time - now that’s magic.
3. Zero touch provisioning of labs - having spoken to plenty of trainers out there I know that provisioning labs for a training course is nothing short of an expedition each time. Even with lots of automation there are all sorts of variables due to the type of hardware available, the number of students attending etc. This is why having one API call to provision 100 isolated, pre-configured labs makes all the difference from a trainer’s perspective
4. Just in time labs that self-destruct - in an ideal world, we’d all have infinite budgets and could leave different lab scenarios running all the time for any number of students. Well, reality bites and we all come to appreciate that labs that are spun up on-demand and self-destruct after 2 hours are easy on the budget making for an affordable solution that can actually be rolled out in the real world
5. No scale limits - whether 1 student takes the course on a certain day or 100. With cloud-based smart labs there would be no impact whatsoever because the infrastructure is rented on-demand from AWS/Google and you only pay for capacity that’s used. So if your software just got mentioned by Oprah and everybody and their mother decided to learn about it on the same day -you’d be all set :)

You can learn more about Ravello's virtual training solution and start with a 14 day trial to see how you can setup your own training labs in the cloud.

The post The future of training is here: Self paced learning with just-in-time lab environments appeared first on The Ravello Blog.

As most of you probably know besides implementing a hypervisor merely capable of running regular VMs, we’ve also implemented a CPU virtualization extensions called VT-I for Intel or SVM for AMD cpus. These extensions, in essence, allow running other hypervisors such as KVM or VMWare’s ESXi on top of Ravello. In this blog I’m going to focus on using DHCP for the 2nd level guests running on ESXi. This blog is optional in case you do not want to use only static IPs for 2nd level guests.

Overview

This article describes how to use DHCP for the 2nd level guests running on ESXi in Ravello. In Ravello, DHCP is not available for 2nd level guests by default. The reason for that is that Ravello system is totally unaware of those 2nd level guests and those guests cannot reach Ravello’s built-in DHCP server by broadcasting DHCP DISCOVER packets. DHCP requests from i 2nd level guests, will not be answered and therefore the guest OS will not receive a DHCP address. In order to use DHCP in the 2nd level guests, you will need to:

1. Define the networking in your Ravello Application and vSphere environment for supporting another DHCP server.
2. Install and configure your own DHCP server VM as a 2nd level guest to service the other 2nd level VMs.

There are few ways how to do those. This blog describes how to do both the easiest way.

Defining the networking in Ravello to support another DHCP server

There are two important factors that need to be in mind when defining the networking:

1. The new DHCP server should respond only to the the 2nd level guests.
2. The 2nd level guests should get responses only from the new DHCP server.

Here is an example how to do so:

1. For each ESXi node in your Ravello Application, add (at least) one NIC dedicated to a separate network that will be used only by those 2nd level guests:
   1. Set a reserved DHCP IP or a static IP for the NIC on the ESXi running guests. Do this for all ESXi running guests in such a way all IPs will be in the same network.
   2. In my example, I have 2 ESXi machines with 2 NICs. The first NIC is using the default Ravello’s network (10.0.x.x). The 2nd guest is using a new network (20.0.x.x) because I have set the reserved DHCP IP of the 2nd NIC to 20.0.0.3 and 20.0.0.4.
   3. You can look at the settings of the NICs here:
      
      
2. For each ESXi, add another VM network for this NIC:
   
3. Set the guest networking to use only this NIC:
   

Installing your own DHCP server

You can use any DHCP you prefer. In this blog I will describe how to install ISC DHCP server on a vanilla Ubuntu machine. In addition, due to the network topology I selected in this example, the new DHCP server will be another VM in Ravello’s application connected only to 20.0.x.x network.

1. Deploy a new Ubuntu machine in your Ravello Application and give it a static IP/reserved DHCP IP in the 20.0.x.x network. In my example I have used reserved DHCP IP 20.0.100.100.
2. Make sure your repositories are updated sudo apt-get update
3. Install the ISC DHCP server sudo apt-get install isc-dhcp-server
4. Enable packet forwarding - sudo vi /etc/sysctl.conf and remove the comment from net.ipv4.ip_forward=1
5. Reboot the DHCP server machine to enable packet forwarding sudo reboot
6. Make your DHCP server to act as a DNS as well - sudo apt-get install bind9
7. Edit the DHCP settings - sudo vi /etc/dhcp/dhcpd.conf and perform the following (note that in my example here the IP of the DHCP server is 20.0.100.100):
   1. subnet 20.0.0.0 netmask 255.255.0.0 {
range 20.0.1.10 20.0.1.100; # you can set any range in the network as you prefer
option routers 20.0.100.100;
}
   2. option domain-name-servers 20.0.100.100;
8. Restart the DHCP service sudo /etc/init.d/isc-dhcp-server restart

The overall networking of your Ravello application should look something like this:

The post How to setup DHCP for 2nd level guests running on ESXi in Ravello appeared first on The Ravello Blog.

Background

This guide will show you how to install the vCenter 6.0 Windows version in your nested ESXi lab on Ravello. This does not cover VCSA 6.0 - that’s coming next. If you haven’t yet installed vSphere we suggest you start with: How to create vSphere 6.0 image on Ravello

As most of you probably know besides implementing a hypervisor merely capable of running regular VMs, we’ve also implemented CPU virtualization extensions called VT-I for Intel or SVM for AMD cpus. These extensions, allow running other hypervisors such as KVM or VMware’s ESXi within the Ravello Cloud environment. f his blog will focus on installing and configuring VMware vCenter server 6.0 in a Ravello’s public cloud which can be extremely useful for testing and/or running ESXi enabled virtual labs. I will show here how to create your own VMware vCenter 6.0 image in the library for easily importing vCenter into any Ravello application. VMware vCenter has 2 different installation options, Deploying the Linux based appliance or installing on Windows

Ravello’s recommendation is to install vCenter 6.0 Windows version.

Installing vCenter server 6.0

1. Login to your Ravello account and create an new Application (do not use a pre-existing blueprint) and give it a name.
2. From the library, Add the Windows VM previously uploaded/created.
   1. You can upload an existing windows VM image into your library from DC or upload windows ISO, take an empty Vm from Ravello library and install it
3. Please note the following requirements:
   1. You must have at least 8 GB RAM.
   2. You must have at least 18 GB free disk space.
   3. It is highly recommended to use 4 vCPUs to increase performance of this VM.
4. Enable and configure RDP as a published service.within the Application:
   1. Select RDP under services tab for this VM in Ravello
   2. Check it as external
      
   3. Make sure RDP service is running in Windows
5. Publish the Application and wait (~5 minutes) until the VM is available.
6. RDP to the Wndows VM.
7. Navigate to VMware downloads website and download the vCenter 6.0 for Windows ISO to the Windows VM.
8. You will need an active myvmware account to login with and download. Accepting the EULA when prompted. This way a matching valid trial license is provided to you.
9. Download the ISO file. As the file is ~3GB, it takes a few minutes to download.
10. Mount the ISO file.
11. Run the installation EXE and follow the steps. The installation takes ~15 minutes to complete.

Verify the installation

1. RDP to the Windows VM.
2. Open a web browser and browse to http://localhost
3. Login to vCenter using the SSO username and password used during the installation (usually the username is administrator@vsphere.local).
4. If you managed to login successfully, Congratulations!! Installation was successful.

Saving vCenter server to the library

Once the vCenter server is properly installed and configured, you are welcome to finally save it to Ravello’s library for future usage. To save the vCenter server VM to Ravello’s library, read here.

The post How to setup vCenter 6.0 on Windows in nested ESXi on Ravello appeared first on The Ravello Blog.

Its that time of the year again. The biggest virtualization event of the year, VMworld 2015 is just around the corner. In recognition of the fact that the VMware ecosystem of partners is a)huge and b)awesome, we figured it would be a fun contest to build live on-demand labs over the next few weeks to showcase the most amazing VMware partner products out there. This is our humble tribute to the phenomenal partner ecosystem and we can't wait to see which partner products will *shine* in these labs. These live labs may run natively on Ravello or run on nested ESXi on Ravello. Either way, it’s all goodness because the labs will be using resources from AWS/Google allowing anybody, anywhere in the world to spin up self-demos on demand and play with the partner products in an isolated sandbox in the cloud, without having to worry about data center capacity or lack of hardware.

VMworld Partner Lab Palooza - the contest details

What you need to do:

1. Build your favorite VMware TAP partner product demo lab on Ravello before VMworld. Each lab must be fully functional, and hey, if it’s smaller than 3 VM deployment is it really a fully functional lab setup?
2. Showcase your lab by doing either one or more of these:
   1. Write a how-to blog for setting up partner lab (example) and/or
   2. Upload a video of your demo lab video on youtube (example) and/or
   3. Create a live self-demo - automated lab spin up with an API call (example) and/or
   4. Share a blueprint on Ravelo Repo (example)

3. Submit your lab showcase by tweeting the link to @ravellosystems and the judges will review each submission for completeness.

Awesome, guaranteed prizes -get your Ravello scooter or win a chance to be fighter pilot for a day 

1. Every single partner lab showcase that’s deemed complete and goes live in Aug 2015 gets the author a Ravello branded scooter
2. The three best lab showcases win a $1395 gift certificate to be a fighter pilot for a day (can be exchanged for another experience)

The rules:

• You may use the Ravello two week free trial or your vExpert accounts to build the lab. You don’t need to be a current Ravello customer to participate.

• You may ask the community or the Ravello team to help you if you get stuck - this is a friendly contest :)

• Multiple entries per person are allowed but we can only give one prize per head - so no, you can’t win a dozen scooters just for fun.

• Contest is open to everybody except Ravello employees.

To start with, here’s a running list of VMware partners that we know are going to VMworld and you might consider building your labs for. If you don’t see a partner name on the list just tweet me @ravellosystems and I’ll be happy to look into it and add it.

EMC (eg: Isilon, vVNX)

Cisco (eg: CSR, VIRL)

Netapp (eg: ONTAP)

Tegile

Dell

HP

Palo Alto Networks

Check Point

Fortinet

A10 networks

Nutanix

Veeam

Tintri

Nimble

Scale

Sophos

Brocade

Commvault

McAfee (Intel)

Simplivity

Trend Micro

Nexenta

Red Hat

Pure Storage

IBM

PernixData

Pivotal

Primary Data

Rubrik

Platform9

Arista Networks

<this is a running list and more VMware TAP partners are being added to the list>

If you have any questions you can always email us at pm@ravellosystems.com or tweet us using @ravellosystems handle.

The post VMworld Partner Lab Palooza – a contest powered by Ravello Systems appeared first on The Ravello Blog.

Isilon OneFS is a scale out NAS storage solution from EMC and uses intelligent software to scale data across vast quantities of commodity hardware. It replaces the three layers of traditional storage model - file system, volume manager and data protection and provides a unified clustered file system with built-in scalable data protection, and obviating the need for volume management. EMC makes available for download, the Isilon OneFS 7.2.0.1 Simulator at no charge for non-production use. In order to install it in a real data center like environment so as to get a feel of user interface and administrative tasks requires ESXi infrastructure. Now, one could invest in hardware and setup a multi host ESXi lab environment to install the EMC Isilon OneFS simulator. The other alternative is to leverage the public clouds like AWS and Google Cloud infrastructure to setup ESXi lab and install and configure EMC Isilon OneFS simulator modules.

AWS and Google Cloud natively do not support nested virtualization, but Ravello platform HVX(runing on top of AWS and Google Cloud) implements Intel VT/ AMD­V (including NPT nested pages support) in software which enables users to run ESXi with hardware acceleration in AWS or Google.

This enables you to build complex and large ESXi lab setup which mimics your data center and run and test EMC Isilon simulator components on top of it. The entire lab can be provisioned on-demand, is available across the world and you pay for only when you use it.

In this blog we will cover installing and configuring an EMC Isilon OneFS Simulator 3 node cluster as a second level guest running on a Nested Ravello ESXi hosts managed by VMware vSphere 6.0.

Once we have the first Isilon node deployed within vSphere, we will save it as a vCenter template so that additional nodes are much easier to add to the Isilon Cluster.

Prerequisite

• A Ravello account. If you don’t already have one, you can start your free trial.
• A working VMware vSphere 5.5 or 6.0 environment running on your Ravello Cloud. More information can be found in this post.
• One or more ESXi nodes setup with access to external network as found in this post.

Virtual infrastructure Requirements

• VMware ESXi 5.5.x or 6.0
• VMware vCenter 6.0 (Windows or Linux)
• VMware vCenter Converter Standalone 5.5 or 6.0

Disk Space

• 17 GB of free space for the first node
• 16 GB per additional node

Additional VMs

• Windows Server Jump host within the Ravello environment/application

High level overview of the steps involved

1. Download the EMC Isilon VM from the EMC trialware site. (An EMC Support account is not required)
2. Deploy the VM using VMware vCenter Converter Standalone
   1. Convert the VM for use with VMware vSphere
   2. Deploy the VM to vCenter Server
3. Save the VM as a vCenter template and/or to the vSphere Library (for vCenter 6.0 only)
4. Configure the first node in the cluster
5. Configure subsequent nodes in the cluster

Ravello Environment

VMware vSphere 6.0a

• ESXi 6.0a
• vCenter Server for Windows 6.0a

Each ESXi node requires 3 NICs:

• 1x External Ravello Network
• 1x Internal vCenter Only Private Network
• 1x Bridged Internal Private Network to External Ravello Network

Network Template

Cluster Name: ISI-01

Reserve a min of 3 IPs for each network

Internal Only Isilon Network

• Int-A Low 192.168.0.101 NIC1
• Int-A High 192.168.0.103 NIC1
• Netmask: 255.255.255.0

External Network

• Ext-1 Low 20.0.0.101 NIC2
• Ext-1 High 20.0.0.103 NIC2
• Netmask: 255.255.0.0
• Gateway: 20.0.0.2

[caption id="attachment_5481" align="aligncenter" width="919"] Ravello Networking Overview[/caption]

[caption id="attachment_5484" align="aligncenter" width="1069"] ESXi vSphere Networking configuration[/caption]

For vSphere networking, in addition to the vswitch configuration found in this post.

Add an additional vswitch to each node for the internal Isilon network.

Each node must be configured with local storage. If you have followed the instructions in this post, there should be a 100GB local disk attached to your ESXi node. Within the vSphere Client, add this disk to each ESXi node.

[caption id="attachment_5485" align="aligncenter" width="370"] ESXi Disk Configuration[/caption]

[caption id="attachment_5486" align="aligncenter" width="353"] ESXi NIC1 Network Configuration[/caption]

[caption id="attachment_5487" align="aligncenter" width="353"] ESXi NIC2 Network Configuration - Note that the Gateway is not defined. This creates our internal only network for vSphere guests.[/caption]

[caption id="attachment_5488" align="aligncenter" width="364"] ESXi NIC3 Network Configuration - This is the internal vSphere to external Ravello network allowing access to the vSphere guest VMs from the Jump host[/caption]

[caption id="attachment_5489" align="aligncenter" width="348"] External Service to allow access to the Isilon management console[/caption]

1. Download the EMC Isilon OneFS Simulator

Download the EMC Isilon OneFS Simulator from EMC’s trialware site.

2. Deploy the Isilon VM using VMware vCenter Converter Standalone

Using the Converter Standalone version that matches your vSphere environment.

Follow the step by step instructions from the “Running virtual nodes on ESX” section of the Virtual Isilon Install Guide PDF available in the Simulator download from EMC’s trailware site.

More information about VMware vCenter Converter can be found on VMware’s Pubs Site.

Ravello specific configuration

Before you save as a template or power on the VM set the Typematic Rate to 2000000:

keyboard.typematicMinDelay = 2000000

3. Save the VM as a vCenter template and/or to the vSphere Library (vCenter 6.0 only)

4. Configure the first node in the cluster

Follow the step by step instructions from the “Install the virtual Isilon cluster” section of the Virtual Isilon Install Guide PDF available in the Simulator download from EMC’s trailware site.

Ravello specific configuration

Deploy the Isilon template to the local storage of the first ESXi node

5. Configure subsequent nodes in the cluster

Follow the step by step instructions from the “Add the rest of the nodes to the cluster” section of the“Virtual Isilon Install Guide.pdf” available in the Simulator download from EMC’s trailware site.

Ravello specific configuration

Deploy the Isilon template the local storage of the remaining ESXi nodes

Accessing the management console

To access the management console, open a browser to https:\\<Ext Network IP of node 1>\

[caption id="attachment_5493" align="aligncenter" width="1572"] Verify the nodes are connected[/caption]

[caption id="attachment_5494" align="aligncenter" width="972"] Cluster Overview[/caption]

Special Notes

Make sure that for Islon guest VM running on top of ESXi in Ravello, The sum total guest CPUs should be =< ESXi host CPUs and same for memory. We have not tested this setup for heavy duty file scanning and other Isilon functional tests. This setup is meant to be used for user trial, demo, training etc. In order to setup a lab with more intensive EMC Isilon OneFS functional operations, would need performance optimizations on underlying ESXi hosts running in Ravello.

The post How to run EMC ISilon OneFS simulator in VMware ESXi environment on AWS and Google cloud for user trials, demos and training appeared first on The Ravello Blog.

Ravello offers many cool capabilities – one that has gained immense popularity amongst product companies is the ability to launch full-featured product test-drives & sales demos on cloud with a click of a button. To create a test-drive for your software product, simply upload your virtual machines/appliance on Ravello, take a blueprint snapshot of the setup, and integrate with our REST APIs to launch as many instances of this setup as you want – on public cloud of your choice AWS or Google Cloud.

Here is a short video of how a 3 Tier, 4 VM product demo lab can be spun up on Ravello with one click –

[embed]https://www.youtube.com/watch?v=Q7apf3aRs9E[/embed]

This capability enables the following use-cases –

• Self-driven Product Test Drive by Customers: Product companies want their prospective customers to play with their offerings – more product test drives means more business and growth. Now, using Ravello, these companies are adding links on their websites that when clicked create full-featured product test-drive environments in the cloud in a matter of minutes. With detailed insights into prospect’s activity in these test-drive environments, product sales team are able to focus on ‘high conversion’ targets and efficiently grow the product top-line.

• On-demand Product Demos for Sales Engineers & Channel Partners: Product sales teams need a repeatable way to showcase the product capabilities as a part of sales demos. Often they have to ship hardware to customer sites, and/or spend significant time setting it up. Sometimes they run into resource constraints when the demos are housed in data-center. Turning to Ravello, product companies are now integrating their demo portal with Ravello's cloud based platform to launch repeatable sales demos and benefit from infinite capacity of public cloud.

• Self-paced Training Labs: Technology trainers are using these capabilities to offer self-paced training labs for trainees to practice their skills. The benefit of using Ravello – no setup time needed, and trainers only pay for the time the labs are running – reducing the cost of offering labs by as much as 75%. Here is how Hacker Academy is using Ravello to offer self-paced learning labs.

[embed]https://www.youtube.com/watch?v=O8r4W8zwqjg[/embed]

Interested in trying? Drop us a line.

The post Customer-driven product test-drives, on-demand demos & self-paced trainings on cloud appeared first on The Ravello Blog.

Ravello’s nested virtualization and overlay networking technology allows for fast application development and testing by encapsulating entire application environments in cloud agnostic capsules. This capability makes it easy to quickly spin hundreds of versions of the capsules in the cloud, which is typical of a continuous integration setup. There is often times a need to connect the Ravello environment to another public cloud, or an on-premise private cloud servers, databases, repositories, etc. For example, in a continuous integration setup where the code repository is on premise, there needs to be a connection to the Ravello environment in the cloud via a secure tunnel.

The goal of this article is to showcase how to setup a secure VPN between two Ravello environments, one in AWS EC2 and one in Google Cloud. This setup mocks a scenario where, while one environment is running Ravello in either Google or AWS, the other could be an on-premise data center or customer’s VPC in AWS or some third party data center.

IPSEC or OpenVPN?

The two options we will describe here are ISPEC and OpenVPN.

Each has its known advantages and disadvantages as described here.

In addition to those known advantages and disadvantages, there are also Ravello’s specific advantages and disadvantages. Here is a list:

• In order for IPSEC to work properly, you need a static public IP. In Ravello you therefore need to use “elastic IP”. Currently, when using elastic IP, you must use Ravello’s proxy/router which has some performance bursts (this is scheduled to be fixed in the next few months). So please be aware that using IPSEC in Ravello might have some performance bottlenecks every once in a while.
• OpenVPN is using a client-server topology in which only the client needs access the server. This is great for an on-premise OpenVPN client as you do not need to open any firewall in your on-premise site.
• OpenVPN is works better in Ravello with port forwarding (rather than “elastic IP”. However, when working with port forwarding in Ravello, the destination port might change in some cases (for example adding/removing some additional supplied services). Such a port change will force a matching configuration change in the VPN Client.

IPSEC

The following settings will need to be adapted to your environment, in order to route the traffic through the pfSense gateway, which will be one of the endpoints of the VPN tunnel.

Ravello GUI

1. WAN Static IP: 10.10.10.1 (the other node will use 10.10.10.2)
2. WAN Elastic IP: 85.190.178.133
   [column size="1/2"][/column]
   [column size="1/2 last"][/column]
3. LAN: 192.168.1.1 (the other node will use 192.168.2.1)
   
4. Supplied services (on WAN interface)-
   1. UDP ports needed are 500(phase 1 IPSEC), 4500 (Phase 2 IPSEC) and 88 (Kerberos).
   2. TCP ports needed are 80 and 443 (for web interface).

pfSense GUI

The VPN IPsec tunnel setting will be created through the web interface of the pfSense virtual appliance.

Copy and paste the Elastic IP of your pfSense appliance into your browser (use https:// prefix) to access the Web UI admin page (85.190.182.122) Login credentials are:
username: admin
password: pfsense (unless you have changed it yourself earlier)

The setup of the tunnel is comprised of two phases:

Phase 1 specifies how the tunnel connects to its remote peer (the other end of the tunnel).

Phase 2 specifies which local network traffic/subnets should be sent through the tunnel. This division makes it possible for the tunnel to handle requests from multiple local subnets. In this example, there will only be one local subnet: 192.168.2.0/24 connecting to 192.168.1.0/24 through the tunnel that has the to endpoints 85.190.182.122 and 85.190.178.133

Before configuring the IPSEC, It is crucial not to forget to add firewall rules in the WAN interface to allow incoming connections (3 rules for UDP ports 88,500,4500):

Also, do not forget of course to enable IPSEC:

Phase 1 configuration

Navigate to VPN > IPsec from the top navigation. Double click the first row in the table. The main components of the Phase 1 configuration are:

Phase 2 configuration

Click Save to navigate back to the main VPN IPsec configuration page. Click the + sign under the first row in the table to see the Phase 2 summary. Double click the row to make changes.
The main components of the Phase 2 configuration are:

The 2nd IPSEC peer

If you are using another pfSense machine in another application, you will need to perform the previous steps in a similar way (just change the source and destination addresses - you will also need to change the address in LAN interface itself).
If connecting your Ravello environment to a private data center, you will need to configure the VPN IPsec settings in your specific router. The steps and terminology involved are similar, but the navigation/UI differs from vendor to vendor.

Establish the VPN IPsec tunnel

In order to establish the VPN IPsec tunnel, navigate to Status > IPsec and click the “Connect” button on the right of the row.

A successful tunnel will display similarly to the screenshot below:

Using OpenVPN instead of IPSec

As written above, For improved performance in Ravello, OpenVPN peer to peer should be used instead of IPSEC. This is because with OpenVPN you can control the port of the remote VPN endpoint and by that you can use port forwarding instead of elastic IP. Elastic IPs along with VPN can result in performance overhead due to external Internet routing infrastructure used.

To configure pfSense as OpenVPN Peer to Peer with a shared key read this.

It is crucial not to forget to add a firewall rule in the OpenVPN server to allow incoming connections:

So after setting OpenVPN client and server, set the OpenVPN server WAN interface to use port forwarding and add a supplied service to UDP port 1194.

Then, in the OpenVPN client, you will need to set:

1. Server host or address to the hostname of the VPN server.
2. Server port to the port used for OpenVPN port (UDP 1194) forwarding in the OpenVPN server (usually 10002 - note that this port number might change after OpenVPN VM restart).

So all in all, the server configuration should look something like this:

and the client should look something like this:

LAN testing

Allowing traffic in OpenVPN/IPSEC interface

In order to allow traffic between 2 sides, you need to add a rule in the firewall. In my example, I allowed all OpenVPN traffic for any protocol on both sides (this includes ping/ICMP packets). A similar thing should be done when using IPSEC instead of OpenVPN.

Testing traffic through the tunnel

Finally, in order to ensure that the local traffic is routed through the tunnel, navigate to Diagnostics > Ping and ping a local IP address from the other end of the tunnel (note - make sure “Source Address” is set to “LAN”).

[column size="1/2"][/column]
[column size="1/2 last"][/column]

Networking configuration of other machines/Vms in the environment configured with VPN

If no inbound internet access is required to the Vms in the Ravello application environment

This is the recommended settings for your VMs. You probably just need to be able to access the internet from those VMs and to be able to access those VMs from other VMs in your application or in the remote site of the VPN. If you for some reason do need inbound access from the internet to VM, please go to this section.

So, in order to configure your machines to properly use the VPN, You need to:

1. Give those machines a static IP address (In this example I will give 192.168.2.2).
2. In case you are using the 192.168.1.x or 192.168.2.x networks (this is how we recommend in this blog), you need to set the Netmask to 255.255.255.0. In case you are using a different network, you will need to assign the matching netmask.
3. Set the Gateway to the VPN’s machine address (In this example I will give 192.168.2.1 as this is the VPN’s address).
4. No need for DNS.

So all in all, your network configuration should look something like this:

If the Vms in the Ravello application environment are configured with DHCP address

This requires additional networking configuration and should be avoided for now, when using with VPN IPSec tunnel.

If inbound internet access is required to the Vms in the Ravello application environment

In case you need inbound traffic from the internet to the VM, it is recommended that you will add another network interface in the VM for that using a new network in your application (10.20.0.x in my example here). You need to configure the routing table in your VM in such a way that the connections to the remote application through the VPN will be routed via the VPN as the gateway and other traffic will be routed using a new gateway defined in Ravello.

Hardening

1. Make sure using only the following Published Services:
   1. TCP ports needed are 80 and 443 (for web interface).
   2. VPN ports:
      1. For IPSEC - UDP ports needed are 500(phase 1 IPSEC), 4500 (Phase 2 IPSEC) and 88 (Kerberos).
      2. For OpenVPN, UDP 1194 is needed.
2. Change the “admin” password:
   In the web interface, Click “System”->”User Manager”

   Click the “e” icon to edit

   Enter a new password twice (one for confirmation) and click “Save”

3. If for some reason you use HTTP and not HTTPS, use HTTPS web access
   Click “System” -> “Advanced”

   Change “HTTP” to “HTTPS” and click “Save” (at the bottom of the page). Please note that depends on your certificate, you might get a warning message such as this the next times you enter the web interface:

Important Notes

IP fragmentation/Jumbo packets/MTU

When a packet is nearly the size of the maximum transmission unit (MTU) of the physical port, and it is encapsulated with IPsec headers, it probably will exceed the MTU of the interface. This situation causes the packet to be fragmented after encryption (post-fragmentation), which requires the IPsec peer to perform reassembly before decryption. In addition, sometimes fragmented IP packets might cause other problems and even get lost in the way.

Moreover, in Ravello, IPSEC VPN needs Elastic IP (see here) which is causing another encapsulation and therefore increases the size of the packet.
This scenario is even more common with jumbo packets which are split to several maximum-MTU packets.
It is therefore highly recommended to reduce the MTU size of the VMs running in Ravello to something much smaller than 1500 (1300 to be 100% safe). If you will not reduce the MTU size of your VMs, packets might get lost.

Reverse DNS resolving

Ravello’s DNS sometimes uses the cloud provider’s DNS for resolving host names into IPs and for reverse resolving IPs to host names. When connecting two applications in Ravello using DNS, you might have a routable IP address on remote application with an internal IP - like for an example 192.168.1.2. If you try to nslookup this IP, you might get an internal cloud provider machine. Just be aware of this situation when using DNS.

The post How to setup VPN for environment running in Ravello from a vanilla pfSense image appeared first on The Ravello Blog.

One of the great things about building and running applications in Ravello is that you can, almost literally, drag and drop in machines from a range of virtualization platforms - VirtualBox, VMWare, Qemu-kvm, pretty much anything really. Then you can use these images to build your environment and run them without caring about the underlying cloud provider. In this blog, I will describe how to build a machine image for Ravello and some of the key modifications that need to be made both to a generic image and to a RHEL7 image in order for it to work properly.

To get started, you only need a disk image and machine information. However,it is incredibly important to remember that the machine image in question is, by necessity, going to be copied and cloned when you actually use it in a blueprint in Ravello.

As everyone who has done clones in a virtualization environment knows, if a machine is going to be cloned or copied you need to disable anything that was designed to lock a physical NIC to a machine. Almost universally this includes udev, with a popular technique being to drop a directory in udev (IE: mkdir -p /etc/udev/rules.d/60-net.rules). RHEL7, and thus CentOS 7, adds a couple additional wrinkles, because of course it does.

The changes introduced in the jump from EL6 to EL7 may very well be the most radical of any linux distribution update ever. In addition to normal things like software revisions we have:

• SystemD replacing init.
• A major version kernel update
• grub and anaconda changes
• NetworkManager replacing /etc/init.d/network
• biosdevname now compliments udev
• And at one point in the beta, net-tools was not installed as part of core.

Ubuntu, Debian, and Fedora have / had similar changes but they’ve been staggered across multiple releases, Red Hat got them all in in one. Anyway, in a world where init has gone away, the key changes here for virtual and cloud environments ironically come down to the network. Udev pinning interfaces to MAC addresses was a problem with cloning virtual hardware but fairly simple to resolve: drop a directory or device into udev(mkdir -p /etc/udev/rules.d/60-net.rules). The change to NetworkManager* however, requires some fiddly bits and biosdevname / net.if_names requires that you pass flags in to the kernel at boot.

* NetworkManager, strictly speaking, does not have to be disabled, but a number of automation tools or modules make a lot of assumptions around networking and so break on EL6 -> EL7 - often because of interface names and NetworkManager (IE: PackStack). It’s easier just to turn it off for now.

We have a fork here; if you’re kicking the machine you can add the options to the bootloader section (“bootloader --location=mbr --boot-drive=sda —append “net.ifnames=0 biosdevname=0”). If you’re working on an existing image, you’ll need to update the grub config:

sed -i -e 's/quiet/net.ifnames=0 biosdevname=0 quiet/' /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg

And to disable network manager:

systemctl disable NetworkManager
systemctl enable network

 
After doing both of these changes you’ll need to manually configure the interface eth0 ala an EL6 machine:

rm -f /etc/sysconfig/network-scripts/ifcfg-e*
cat </etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="dhcp"
ONBOOT="yes"
TYPE="Ethernet"
EOT

All of this can be loaded into your kickstart in the post-install section if you desire. I’d use the append technique as opposed to sed for turning off net.ifnames and biosdevname if you decide to do it that way though.

Next up is cloud-init. You need a minimum of one package for this, located in the extras repo, cloud-init. You also probably want dynamic resizing of storage volumes though, so you will want to tack on cloud-utils-growpart . After that you’ll want to make sure the cloud user exists and is configured the way you want it to be as well as cloud-init is on at boot:

useradd -g adm,wheel,systemd-journal -G users cloud-user
sed -i -e 's/centos/cloud-user/' /etc/cloud/cloud.cfg

I like to drop it into sudoers with a ALL=(ALL) NOPASSWD:ALL

echo “cloud-user ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/cloud-user

And that’s it, everything you absolutely need to know to build your own image. If you booted an CentOS 7.1.1503 disk and followed along you’ll have a rough approximation of this (Virtual Machine) - so go ahead and use that to get you started. A kickstart encompassing all of these changes is available here.

The post Preparing Linux Images for Ravello appeared first on The Ravello Blog.

In this blog I’m going to focus on how to extend your VMware vSphere on-premises datacenter to the public cloud. With Ravello, you can run ESXi nodes in AWS or Google Cloud, and easily connect it to your data center. Hence, you can spin up as many VMware ESXi nodes as you need, on demand, and simply pay for what you use. We call this, the InfinityDC. Both, the on-premises data center as well as the ESXi nodes running in AWS can be managed using the same VMware vCenter, providing for a seamless, scalable fabric.

My data center setup consists of 3 ESXi nodes, 1 NFS server and 1 vCenter appliance to manage the whole deployment. The Ravello application in Google cloud has 3 ESXi hosts and represents a VMware vSphere environment you set up in public cloud. The Ravello “application” in Google Cloud and my data center are completely isolated. I have used pfsense to establish a VPN between these two sites. The vCenter in my data center controls all the 6 ESXi hosts. The VPN is configured using the instructions outlined in this blog.

Settings the VPN

The VPN is configured as OpenVPN peer to peer (better performance than IPSEC in Ravello) as explained in the VPN blog.

The on-premises data center

Notes:

• OpenVPN server is running in this environment.
• All machines are using static IPs only.
• In this example, ESXi machines have only one network interface.
• In this example, vCenter machine has no inbound internet connection (for security reasons - this entire environment is closed for inbound connection (other than the VPN server of course)). I have used console (rather than RDP) to work with it.
• In order to be able to connect over VPN to remote ESXi machines from the remote datacenter, I had to reduce the MTU of vmk0 interface in all 3 ESXi hosts running in on-premises DC (see “IP fragmentation/Jumbo packets/MTU” section in the VPN blog). I have reduced the MTU (from 1500 to 1300) by running the following command esxcli network ip interface set -i vmk0 -m 1300

Ravello application running on Google Cloud

Notes:

• OpenVPN client is running in this application environment.
• All machines are using static IPs only.
• In this example, ESXi machines have only one network interface.
• In order to be able to connect over VPN to remote ESXi machines, I had to reduce the MTU of vmk0 interface in all 3 ESXi hosts running in Google (see “IP fragmentation/Jumbo packets/MTU” section in the VPN blog). I have reduced the MTU (from 1500 to 1300) by running the following command esxcli network ip interface set -i vmk0 -m 1300

Running VMs in the remote datacenter

In order to deploy VMs in the Ravello ESXi environment, you have several options. The straightforward way to accomplish that is by:

1. Copying the needed files (either ISO files or actual VMs (vmdk+ovf)) to the remote NFS server. You can do this using SCP for example or using the vSphere client plugin.
2. Once the files are located in the remote NFS machine you can normally deploy/install the VM and run it.

Long distance vMotion

Since vCenter 6.0 version, VMware supports long distance vMotion.

You can perform such vMotion and move running VMs from your on-premises datacenter to your Ravello remote datacenter without any downtime.

The post InfinityDC: How to extend your on-premises vSphere data center to the cloud appeared first on The Ravello Blog.

In this document we describe how to enable ingress connectivity to the nested VMs running on top of VMware ESXi™/ vCenter in Ravello, also referred to as 2nd level VMs. Since Ravelo DHCP does not support nested virtual machines we will use static IP configuration.. For more information on using DHCP, and the additional configuration needed, see this post from Ohad, detailing the steps.

The Ravello DHCP servers do not give out IPs to the nested virtual machines, so we need to configure them with static IPs and create a virtual IP so they can be accessed from the Internet or remotely from outside of the Ravello Application Environment.

The steps included here:

Add an additional NIC to an ESXi node

1. Add an additional NIC to a hosted ESXi node in the Ravello UI . This additional NIC will be used to create an uplink for a segregated vSwitch on ESXi. The nested VMs will use this switch as an external gateway

2. Define a subnet for nested VMs by configuring the newly created NIC with IP/Subnet information.
   In this example, I am using subnet 20.0.0.x/16 to define my external network:
   1. IP address: 10.20.30.3
   2. Subnet: 255.255.255.0
   3. Gateway: 10.20.30.2
   4. DNS: 10.20.30.1 (optional)

   The IP address 10.20.30.3 can be used for the first nested guest VM or it can remain a placeholder.

   The optional DNS Server can be any IP. Ravello will create the DNS server as defined. You may also substitute your own DNS server running within the same Application Environment. his DNS server can then be assigned statically in your nested ESXi VMs.

3. To reserve additional IPs for nested VMs select Advanced > Add and enter a different IP address from the same subnet and use the same gateway address as in step 2.

4. To provide ingress connectivity to a specific TCP/UDP port go to the Services tab and click on Add Supplied Service. Then fill in a port number and select the designated address of the VM (i.e. 10.20.30.10 – as in our example used in the previous step).

   Common ports to enable are:
   22 for SSH
   3389 for RDP
   443 for HTTPS
   80 for HTTP

   To configure 1:1 network address translation, select “IP” as the protocol in the services. This forwards all traffic from the public IP to the private IP and can be useful when running a nested virtual router or networking virtualization software such as VMware NSX.

   To use port forwarding without consuming a public IP for a service, configure “Port forwarding” on the virtual interface:

   When the virtual machine has been started, the port mapping shows in the summary of the virtual machine. In my case, port 22 on the virtual machine is reachable through 104.197.108.68:10001.

   It is also possible to provision more than one routed subnet on the same physical ESXi interface. This prevents you from having to create a new vSwitch and interface when you wish to configure virtual machines to use a separate subnet.

   As shown below, I’ve created an additional virtual IP in a separate subnet with a separate router:

   When we look at the network topology, a separate router is created and traffic can be routed between the virtual machines in different subnets.

5. Using the vSphere Client (shown here) or the vSphere Web Client connect either directly to the hosted ESXi node or vCenter and create a new vSwitch of type “Virtual machine port group” (not VMkernel) on the ESXi node that will run the nested VMs. Bind it to the additional NIC created in step 1. VMs that need external connectivity must have their vNICs assigned to a port group on this vSwitch.

   Do not assign an IP address or VMkernel IP Stack to the new vSwitch.

6. For each nested VM you want to access remotely, assign a static IP from the pool created in step 2. In the nested VMs assign a static IP configuration. Use an IP address and gateway from step 2:
   1. IP: 10.20.30.x
   2. Netmask: 255.255.255.0
   3. 10.20.30.2
   4. DNS: 10.20.30.1, 10.0.0.1
7. Test external access by connecting to a known website or pinging a remote server from within a 2nd Level VM. After verifying external access, you can test accessing the VM from an external source.

   You can find the external IP/hostname on the summary tab of the ESXi node. There is a drop down list for the available NICs with IP information for each additional IP you defined.

   Replaced image and IP addresses since the previous 20.0.0.0/16 range is not a RFC1918 range. Just to prevent confusion and angry network admins.

The post How to configure SSH and RDP access for nested VMs running on top of ESXi hosts in Ravello Systems appeared first on The Ravello Blog.

Author:

Matthew Ebben

Director of Worldwide Systems Engineering at vArmour Networks, the data center security company that transforms how organizations protect their virtualized and cloud assets in a world without perimeters.

Say you’re the maker of the world’s first distributed security system; one which runs across multiple types of compute environments and tightly integrates with data center and network management systems to enable dynamic security. Sounds cool, right? Indeed, it is.

However, when said distributed security system leverages a POC process that handles live, production data, how can you help show customers immediate value without the complexity that can come with production change windows, IT governance practices, and VLAN configurations?

Understandably, when you are positioning a Proof of Concept (POC) to be installed in production environments, integrating with production vCenter instances (or other virtualization management solutions) and analyzing or enforcing production traffic, it can cause customer anxiety on the impact it could potentially have on their IT operations.

Because of this, we often find ourselves relegated to lab environments where there is less “interesting” traffic to monitor and show the full value of the product. Compounding this problem is the fact that most lab environments are not treated the same way as production and often have configuration issues that require more time troubleshooting than we expect - causing delays for customers to experience our product.

With Ravello Systems’ ability to nest various types of hypervisors in their multi-cloud, multi-tenant virtualization environment, we can now provide customers access to their own “virtualized data center” running vArmour DSS Distributed Security System on AWS and Google Cloud.

We have created a standard Ravello Blueprint image that includes multiple ESXi hosts running a handful of test VMs, each wrapped in its own micro-perimeter by vArmour’s micro-segmentation capability, all under management by VMware vCenter.

VMs are dynamically inserted into the security policy at startup and boot off of an NFS datastore for demonstration of vArmour’s support of fully stateful VM migration, without expensive state synchronization protocols. The virtual switching in use is a mixture of vSphere Distributed Switches and vSphere Standard Switches, as vArmour and Ravello support both switch types.

The VMs in our environment are split up into separate subnets and VLANs, as you typically find in production data centers, and are routed by a separate VM functioning as a lab network router. All of this is accessed by RDP into a Windows Server 2012 Jump box using an obfuscated FQDN and port-forwarding. With this approach, each environment is set up exactly the same, with the same VMs, same access rights, same credentials, etc. The only thing ever provided to a user is an FQDN:port combo and a username/password. Security policy is set in a way which prohibits a user from exporting any VMs, licenses, hypervisors, vCenters, etc. With this configuration, a customer is able to run vArmour DSS the same way they would in their own data center.

vArmour application in Ravello running on AWS and Google Cloud

Customer-accessible vArmour Components running on Ravello VMs

The beauty of the Ravello platform is we can have as few or as many environments as we want running simultaneously, all completely managed by vArmour, with no ability for one customer to affect another customer’s environment. The other nice thing about having this environment in the cloud is that since it’s not a customer data center, we can generate fake malicious traffic patterns without giving the SecOps guy a heart attack. Creating this sort of traffic in a hosted environment lets us show the power of vArmour’s traffic metadata analysis, specifically, our laterally-moving threat detection and east-west flow visibility, in a way we sometimes are unable to in production environments.

While the initial use case is around streamlining the sometimes complex evaluation point of the security sales cycle, we’ve begun to explore a number of other highly-compelling use cases for the Ravello offering. These include:

• On-Demand SE demo/self-education environments
• Channel partner on-demand labs
• Partner/ISV integration development environments
• Training labs
• QA system scalability testing environments

By hosting our demo environment with Ravello, we’re able to streamline deployment processes that can present challenges for any organization. These Ravello labs are quick and easy way to illustrate the value of our products, without the heavy lifting that often accompanies traditional POC activities.

The post Running vArmour ESXi demos on AWS and Google Public Cloud appeared first on The Ravello Blog.

We recently announced general availability of InceptionSX which lets you run the nested ESXi hypervisor on AWS or Google Cloud. But for the last two years we have had customers running their enterprise application environments with VMware VMs and complex networking on Ravello using just HVX.

The setup, install and performance is entirely different for the two So here is a quick cheat sheet explaining the differences.

	HVX: Running VMware VMs or virtual appliances on Ravello	InceptionSX: Running nested ESXi hypervisor on Ravello
Useful for	Labs for enterprise applications (virtualized workloads) such as Sharepoint, Oracle, custom Java or .Net applications Labs for VMware virtual appliances such as F5, CheckPoint, Arista, Cisco	Labs for testing hypervisor features such as long distance vMotion, and related VMware products such vCenter, VSAN, NSX, vRealize Operations etc and VMware partner products such as Veeam, Zerto, Nutanix etc which need the hypervisor itself as part of the lab
Architecture	You can run all your virtualized enterprise workloads with existing VMware VMs and existing VMware virtual appliances on Ravello HVX, without any VM conversions required. Ravello has developed a nested hypervisor with software-defined networking, called HVX, that runs in cloud VMs instead of running on bare metal servers. It runs on AWS/Google and exposes the same VMware interfaces, drivers, networking that the application expects. This mode is called HVX.	Without Ravello, it is not possible to run ESXi on AWS/Google Cloud. This is because the ESXi hypervisor, at boot time, looks for hardware extensions and instead discovers that AWS is running Xen and Google is running KVM. However, Ravello HVX exposes hardware extensions like IntelVT and AMD SVM in the public cloud so that you can run the ESXi hypervisor on it if required. This is for use cases where you need to test ESXi hypervisor features and this mode is called InceptionSX.
Typical use cases	Enterprise app dev/test environments Sales demos, POCs for any software environment such as virtual appliances Virtual training labs in the cloud Self-learning/ home labs for enterprise applications, virtual appliances	ESXi dev/test environments for hypervisor or software with ESXi modules ESXi sales demos, POCs ESXi or vSphere virtual training labs Self-learning/ home labs for ESXi, vCenter, NSX, VSAN etc
Performance	HVX is very lightweight and hardly adds any performance overhead. Expect to see the same overhead as going from physical to virtual when going from virtual to Ravello.	InceptionSX is running ESXi on HVX on either Xen (AWS) or KVM (Google). The performance is still very good but slightly lower than just HVX due to the extra layer of nesting
Installation & licensing	No ESXi install or licensing required	Install your own vSphere ISO and use your own vSphere license

The post Running VMware VMs on Ravello HVX versus installing ESXi hypervisor itself on Ravello appeared first on The Ravello Blog.