Learning Open vSwitch will require more effort than simply reading the basic cookbooks, but it also doesn't necessarily...
take a costly proof-of-concept process.
One way to get started is to build a simple Open vSwitch testing network with a Linux-based hypervisor and very basic commodity hardware.
Open vSwitch works on Linux and VMware hypervisors
Open vSwitch is an open source virtual switch that has become the default option for most Linux-based hypervisors, such as Xen and KVM. Since it's the default virtual switch for both KVM and Xen, you'll find it in virtually all OpenStack installations. Open vSwitch is also used in VMware NSX environments, but there are no special features in that environment that can't be found in an open source distribution.
First steps to Open vSwitch testing network
You can find Open vSwitch as a package for virtually any Linux distribution that supports KVM, Xen and VirtualBox. If you are looking to run Open vSwitch natively on VMware vSphere, you have to engage your VMware salesperson to deploy an NSX proof of concept (POC). However, VMware, like most enterprise software vendors, offer POCs as part of the sales cycle. This normally requires some level of commitment from the customer, which includes ensuring technical and financial resources for the process. It may also include paying for professional services and providing a non-production platform to run the POC. If you aren't ready for the purchase cycle, you may want to kick the vSwitch tires via a Linux distribution or VMware's free Hands-On-Lab.
Building an Open vSwitch network lab
You can run Open vSwitch code on white-box switches that are either from a vendor or ones that you build yourself using x86 hardware. However, you'll probably need to get started by deploying Open vSwitch for testing within a server farm or home lab that has limited access to physical network hardware.
The good news is that while practicing with traditional networking requires lots of hardware in order to configure and manage as many ports as possible, you can design virtual switching labs with just a single server or modern PC.
A way to design a more complex lab would be to start with a workstation or server running VMware ESXi, VMware Workstation or VirtualBox. Once the base hypervisor is installed, you can deploy a virtual instance of KVM with an Open vSwitch. Within the KVM instance you can spawn small VMs as test nodes. This alone would be a pretty good lab, but if your workstation has enough CPU and RAM, you can spawn a second KVM host with the same setup. There's also the option of adding network function virtualization (NFV) devices, such as a virtual firewall between the two KVM environments. This scenario would require a robust hardware environment. Ideally, the system would have a minimum of a quad-core processor, 32 GB of RAM and solid-state storage devices (SSDs).
A simpler environment would require a common workstation setup with an x86 server that supports virtualization extensions (AMD-V & Intel VT), and traditional spinning disks with 8 GB of RAM.
An even more common configuration would be a system running a hypervisor, such as Virtualbox, Xen or KVM, with VMs and vSwitches running within that environment. By installing the hypervisor directly on your hardware, you can have a basic lab with as little as 4 GB of RAM in the system. This lab would include the KVM Host, two Open vSwitches and two Linux nodes for testing. Performance might be a little sluggish, so I would suggest using a very light Linux distro for the test nodes. If you have only your home laptop or desktop and still need to do everyday computing in addition to this Open vSwitch lab, you can leverage desktop virtualization as a solution.
Nesting in an Open vSwitch testing network
With a combination of modern hardware and software you can run nested VMs within desktop virtualization solutions. Nesting is the ability to run a hypervisor within a hypervisor. You'd basically take the lab pictured above and run it inside a desktop hypervisor. Virtualbox and VMware Workstation and Fusion support nested hypervisors.
This abstraction does come at a cost. if you choose to run the lab within your preferred desktop virtualization solution, you will need enough RAM to run your host operating system, such as Windows or Mac OS X. A general rule of thumb would be a minimum of 6 GB of RAM if you choose a nested lab. A more appropriate configuration would be 8 GB of RAM and SSD devices for storage.
Testing in the cloud?
It's worth noting that while we examined traditional x86 resources, such as servers, physical laptops and desktops, cloud vendors such as Bare Metal Cloud and Ravello Systems offer options for running KVM in the cloud. This may also further reduce the barrier to entry. Whatever option you choose, the power available to learn networking has never been so abundant.
Managing Open vSwitch in an OpenDaylight environment
Cisco 1000v vs. Open vSwitch
Comparing NSX and Hyper-V networking