The ultimate guide to virtualization swap files!

Most operating systems natively support RAM over-extension. This is accomplished by using a temporary file on the hard drive to store RAM blocks that are not currently being actively processed so that more RAM is available for blocks that do need current processing. This file is called a swapfile or a pagefile depending on the OS. This is never a good thing, because disk is always slower than Ram speed (don't believe me? click here) But it is sometimes a necessary thing.

Managing Swapfiles and Pagefiles can be confusing in VMware or Hyper-V because there are multiple files to configure at different levels.

1. Guest VM's native OS swapfile
2. Host related swapfile
3. Hypervisor's per-guest VM swapfile

1) Guest VM's native OS swapfile

Even though you may assign 4 GB of RAM to a virtual machine, the OS running in that system may choose to create it's own pagefile on whatever virtual disks you provide according to its native behavior based on the full amount of "physical" RAM that it sees. The Hypervisor has no role in if or how a guest OS chooses to build or use a swapfile. This must be completely managed from within the Guest OS. However, remember that as a virtualization administrator you could certainly create a dedicated virtual hard drive file that is placed on a fast storage tier and then within the Guest OS ensure that this disk is used for paging. 

2) Host related swapfile

Just like the guest OS, your virtualization host has a swapfile or pagefile to support not having enough memory to perform its duties associated with being a virtualization infrastructure: (provisioning new VMs, vMotioning, etc) 

2a) VMWare System Swapfile using the Web Client: This is done via Hosts and Clusters -> Host -> Manage Tab -> Settings SubTab -> System Swap

vCenter Server Web Client configuring Host System Swap File

Edit System Swap Settings:

• Enabled - if unchecked = ALL RAM ALL THE TIME - NO SWAPFILE!
• The Datastore - Use a specific datastore
• Host Cache - use part of the host cache.
• Preferred swap file location - Use the host's preferred swap file location 

2b) Windows Server with Hyper-V: this is managed via the system control panel -> Advanced Tab -> Performance -> Settings... -> Advanced Tab -> Virtual Memory -> Change... 3) VM related swap files.

Server 2012 R2 Hyper-V server configuring Host PageFile

• If all page files are removed = ALL RAM ALL THE TIME - NO SWAPFILE!
• Don't forget to click "SET" after configuring a pagefile on a disk, otherwise nothing happened.

Hyper-V Server or Windows Server Server Core Host Swapfile

Modification is done by script or command line entries:

Add a 2 Gb Pagefile:

wmic pagefileset create name="E:\pagefile.sys"

wmic pagefileset where name="E:\\pagefile.sys" set InitialSize=2048,MaximumSize=2048

Delete a pagefile:

wmic pagefileset where name="C:\\pagefile.sys" delete

3) Hypervisor's per-guest VM Swapfile 

Modern hypervisors create a temporary swap file for hypervisor related memory management needs. This is NOT a swapfile that the Guest OS could ever see or use for its own swapfile needs! However, you may want this to be placed on an efficient disk to ensure that VMs boot as efficiently as possible. There are some key differences in how ESXi and Hyper-V use these files.

VMWare:

The host creates VMX swap files automatically, provided there is sufficient free disk space at the time a virtual machine is powered on. If it cannot be created, it prevents power on! 

This file is used because while physical memory is reserved for the system at powered on, memory for needs like the virtual machine monitor (VMM) and virtual devices can be swapped after initialization. The VMX swap feature means that a the 50MB+ for live VMX memory needs can shrink to only 10MB, freeing up memory resources for other needs. This is critical in overcommitted memory situations. 

By default, the swap file is created in the same location as the virtual machine's configuration file, but you may change the swapfile datastore datastore to another shared storage location. Moving the swapfile to a local datastore may improve local performance, but it may also slow vMotions later because pages swapped to a local swap file on the source host must be transferred across the network to the destination host

Hyper-V:
Smart Paging in Hyper-V is used only when the following is true:

• The VM is being restarted (directly or via a host restart)
• The hypervisor discovers that there is no available RAM
• No memory can currently be reclaimed any other VMs running on the host

At that time the Smart Paging file is used by the VM as memory to complete startup. Within 10 minutes, that memory mapped to the Smart Paging will need to be provisioned into RAM and the the Smart Paging file will be deleted.  The Smart Paging feature is ONLY to provide reliable restarts (not cold boot or running out of RAM later) of VMs

3a) How to configure the vSphere web client to configure VM support swapfile: Hosts & Clusters -> Host -> Manage Tab -> Settings SubTab -> Virtual Machines -> Swap File Location

vSphere Web client configuring Default Swap File Location

vSphere Desktop Client to configure VM support swapfile: Select Host -> Configuration Tab -> Software Group - Virtual Machine Swapfile Location

This setting can also be overridden on a per-VM basis if needed in the VM Swapfile Location property

3b) Hyper-V SmartPage: Select a VM -> Right Click (Or Actions) - Settings -> Smart Paging File Location

The file location is determined during installation, then reconfigured on a VM by VM basis in their management related properties:





I hope that you feel a little more solid on the 3 types of swapfiles that you will run into when managing virtualization!

Keep it virtual!

An easy to understand description of VLANs for Cisco, HP, VMWare, or Microsoft

VLANs can be confusing for virtualization administrators, because it takes a really solid understanding of networking to then be abstracted into a virtual environment, which can then be configured multiple ways.
Let's make sure we're on the same page with VLANs first

Let's think about a physical environment that is segmented without any VLANS

 

If we think about networks from a chronological perspective, we start with just the green local area network at the top. All your local clients were in a local broadcast domain with a single network ID. And the living was easy.

Then LANs continued to grow and grow, which caused too many broadcasts, traffic congestion, and security vulnerabilities... all because all the devices were playing in the same "sandbox."

 

So to divide the LAN we ran a dedicated cable from a newly dedicated interface on the router, installed a separate switch, and routed between the LANs, as seen in the diagram above.

 

Question: Why would anyone ever want anything better than that solution?

#1 - Money: High speed Ethernet interfaces on routers are a costly proposition, only superseded by purchasing entirely new routers to handle the traffic from each network. Additionally, every subnet needs a dedicated switch. What if a 48 port switch is serving a network of only 10 hosts? 37 wasted ports.

#2 - Management: To reassign a host to a different subnet means moving their patch cable to a physically different switch. This is a manual, physical process that requires going into the racks and mucking about - always an additional risk, easy to make mistakes

The good news is that soon one of the first network virtualization technologies came into being. Instead of having to buy additional switches and router interfaces, we can use virtual LANs (VLANs)

- VLANs allow us to virtualize networks using two key components:

1) Switch ports are virtualized so that instead of one switch you can have the effect of having two or three or more switches from a single physical switch, and then you can spread these multiple virtual switches across multiple physical switches!

2) Router interfaces are also virtualized, using sub-interfaces on physical routers or virtual VLAN interfaces on multilayer switches. Each virtualized router interface will be configured to "plug in" to the virtual switch. This means that one uplink could support a connection to 20 different subnets!

So how do you go about virtualization? It's all about playing a game of tag. Each switch's access port (a port going to an end station such as a server, desktop, phone, or router) will be tagged with a particular VLAN number, determined arbitrarily by the administrator.  (Side note, many administrators make their lives easier by creating a loose association between VLANs and subnet IDs. For example, the 192.168.5.0 subnet could be assigned VLAN 5 for simplicity.)

So each VLAN is identified by a number and the default VLAN is VLAN 1. All ports are assigned to VLAN 1 by default, meaning that the switch functions like an unmanaged switch, all ports will forward, filter, and flood with all other ports. Since this is the case, by default, VLAN tagging (inserting the tag ID into the frame) is skipped by default for VLAN 1. This skipping can only be done for one VLAN ID number, and is known as the "native VLAN". 

But now we choose to subdivide the switch by adding VLAN 2.  Generally on a switch you will have the opportunity to provide a VLAN name, which makes it a more sensical device (ie: HR_192.168.5.0 for the Human Resources subnet using 192.168.5.0)

Now that we two different VLANs an administrator needs to assign access ports to that VLAN.

This effectively turns a switch from this:

(Switch with all ports still on VLAN 1)

into this:




Remember, the devices connected to the switch know nothing about VLANs. But now the switch has virtualized two networks instead of one, which means that traffic must be ROUTED from one VLAN into the other, not just switch. 

In order to allow multiple switches and routers to participate in these VLANs we must modify the standard Ethernet frame and insert a VLAN tag number so that all devices can respect the defined VLAN boundaries. Tagging is done between devices over what are known as trunk ports. Trunk ports are used when connecting switches to each other or when connecting switches with multiple vlans to a router. Trunk ports are not assigned a VLAN number because their job is to carry ALL VLAN traffic upstream to a router and to take the returning packets and forward them to the correct access ports. VLAN ID numbers are stripped from the frames before they enter an access port.

That allows for this:

With this configuration you can see that we have the equivalent of 4 switches instead of two, with two switches in each broadcast domain. The great thing about the configuration above is that a device in VLAN 1 can switch to another device in VLAN 1 (or a VLAN 2 device to another VLAN 2 device) at high speeds. However, if a device wants to connect to another device across VLANs (VLAN 1 PC to a VLAN 2 Server, for example) then they had better know the know the IP address of the sub-interface (virtual interface) of their L3 routing service! In other words, they must route as if they were physically connected to different physical interfaces of the router.

But the real beauty of all this is that any device could be moved to a different subnet by reconfiguring the VLAN ID of an access port to a different number. As long as all the switches have the same VLAN ID numbers (and the router has VLAN associated sub-interfaces.

A little more about the native VLAN. The default VLAN is VLAN 1 (what all ports start off as). The default VLAN is also the native VLAN (untagged "assumed" VLAN number) by default. This was useful when connecting unmanaged and managed switches and in carrying management traffic back in the day. However, for security reasons, it is usually a best practice to change the native vlan to a different, unused VLAN ID number (such as 999). This ensures that are no assumptions, and therefore no annoying security holes. Now VLAN1 frames will be tagged as VLAN 1 just like all the other VLANs

When VLAN 2 is added, the VLAN tag is added to frames that are a part of VLAN 2. We now have two VLANs, and at least one of them must be tagged to be identified. 

Now, let’s add VLAN 3.  In this setup, two VLANs would need to be tagged, one would not because it was the original lan (VLAN)  The VLAN that is not tagged is known as the native VLAN.

There are a lot of questions of when and why to use the native VLAN or if you should use the native VLAN at all.  As always in IT, the answer is, it depends on what you are doing. VLAN 1 does not have to be your management VLAN.  It does not have to be the native or untagged VLAN. You can do whatever you need for your environment.  Typically, I do not use the native VLAN for security reasons, and I choose to tag everything. 

Remember that all of this is true whether you are dealing with a physical switch or a hypervisor driven virtual switch on Microsoft Hyper-V or VMWare ESXi. Trunk ports between switches, defined VLANs omnipresent, Access ports with VLAN ID numbers on individual access ports.

Keep it clean, keep it safe.

Get Trunk!!!

Remember - you can't carry traffic for multiple VLANs unless you...

Smiles,