Create an Encrypted Disk on VMware

The following tutorial will show you how to create an encrypted disk on a Porticor appliance running on VMware. We go into detail, so this may look difficult at first. But the process simply consists of:

• Creating a VMware virtual disk
• Setting up the disk for encryption with Porticor and exposing it as an iSCSI target.
• Creating a VMware datastore from the secured disk.
• Using the datastore to carve out disks for your VMs.

 

Step 1: Create and initialize a Porticor Appliance.

See our VMware Getting Started article. At the end of this process, you will see the appliance's home page.

Step 2: Create a new Hard Disk on the appliance. This disk will eventually become your secure data store.

Go to your vSphere Client application. On the Porticor appliance, select Edit Settings, then Add Hard Disk.

Step 3: Rescan disks on the Porticor Appliance, so that the new disk is recognized.

Back on the Porticor GUI, go into the File Systems page, and press the Rescan button.

Step 4: Wait a few seconds and you will see the new disk, appearing as "uninitialized".

Step 5: Define the disk as an iSCSI target.
Select iSCSI Target from the drop-down list, and press the Secure The Disk icon.

Step 6: The disk is now ready to use.

Step 7: Optionally, find out more details on the new disk.

Press the Use It link to discover details about the iSCSI target, such as the appliance's IP address (also available from the vSphere Client) and the target name.

Step 8: Locate the ESXi configuration page for the relevant host.

On the vSpehere Client, go into Hosts and Clusters, select the particular ESXi host and Configuration.

Step 9: Find the iSCSI Storage Adapter.

Under Storage Adapters, you should see an iSCSI Software Adapter. Select it.

Step 10: Add the Porticor appliance as an iSCSI target.

Right click the Adapter and select Properties, then the Dynamic Discovery tab, and enter the appliance's IP as a Send Target Server.

Step 11: Rescan targets so that ESXi sees the new disk.

You will get a warning that a rescan is needed. Press Yes.

Step 12: The new iSCSI target is available.

The new iSCSI targets (a controller and a disk) appear at the bottom of the page.

Step 13: Start creating a new data store from the iSCSI target.

Go to Hardware/Storage, and Add Storage…, select Disk/LUN.

Step 14: Select the newly added storage.

Step 15: The datastore is now ready to use.

When done, you will see a new datastore created out of the encrypted storage.

Step 16: Use the secure datastore.

You can use the encrypted datastore when creating a disk for any VM. Just select Specify a Datastore.

Or you can use the Datastore Browser to examine the datastore's contents.

VM

A virtual machine (VM) is a software implementation of a computing environment in which an operating system (OS) or program can be installed and run.

The virtual machine typically emulates a physical computing environment, but requests for CPU, memory, hard disk, network and other hardware resources are managed by a virtualization layer which translates these requests to the underlying physical hardware.

VMs are created within a virtualization layer, such as a hypervisor or a virtualization platform that runs on top of a client or server operating system. This operating system is known as the host OS. The virtualization layer can be used to create many individual, isolated VM environments.

Typically, guest operating systems and programs are not aware that they are running on a virtual platform and, as long as the VM's virtual platform is supported, this software can be installed in the same way it would be deployed to physical server hardware. For example, the guest OS might appear to have a physical hard disk attached to it, but actual I/O requests are translated by the virtualization layer so they actually occur against a file that is accessible by the host OS.

Virtual machines can provide numerous advantages over the installation of OS's and software directly on physical hardware. Isolation ensures that applications and services that run within a VM cannot interfere with the host OS or other VMs. VMs can also be easily moved, copied, and reassigned between host servers to optimize hardware resource utilization. Administrators can also take advantage of virtual environments to simply backups, disaster recovery, new deployments and basic system administration tasks. The use of virtual machines also comes with several important management considerations, many of which can be addressed through general systems administration best practices and tools that are designed to managed VMs.

What is VMware View?

Virtualizing servers in the data center has been a trend for years, but virtual desktops have been slow to catch on. VMware View is VMware's entry in the virtual desktop space which competes with the other major players, namely Citrix XenDesktop and Microsoft Remote Desktop.

Virtual desktops provide several advantages over traditional full workstations including easier management and simpler provisioning. Desktop virtualization takes a user's desktop workstation and stores it on a central server as a virtual machine. The user can then access it from anywhere using a small remote client application, which is referred to as a thin client. Thin clients can be either low-cost dedicated hardware devices that are basically just a monitor, keyboard and mouse, or an application installed on any type of PC. Because the desktop is hosted on a powerful server that handles all the processing for the desktop, the thin client has very small resource requirements and does not need to be that powerful. The only data that is sent back and forth between the thin client and the hosted server are video, keyboard/mouse inputs and peripheral connections (USB drives/printers).

VMware View leverages vSphere as the virtual desktop host platform; in other words, user desktops are virtual machines running on ESX/ESXi hosts. They can take full advantage of all the features built into vSphere like VMotion, snapshots, Distributed Resource Scheduler (DRS) and more.

Export Hyper-V Virtual Machines

There are a number of Hyper-V backup utilities on the market -- some of them are even free -- but you might be able to get by with simply exporting a virtual machine.

When you export a virtual machine, you get the configuration file, a copy of the VHD, and any snapshots. What is attractive about this feature is that you can move the virtual machine anywhere else or even reimport it in the event of data loss or if you rebuild a system. Before you can export a virtual machine, however, it must be shut down.
Using Hyper-V Manager to Export a Virtual Machine

There are two ways to export a virtual machine. In the Hyper-V Manager, you can select a virtual machine, then right-click and choose Export from the context menu

 

Next, you will be prompted for a folder path as in Figure 2.

Click Export to begin. However, there's one major "gotcha" -- you can't have a previously exported version in the same location. If you do, you will get an error like in Figure 3.

You can delete or move the existing files and repeat. Be aware that this export will need as much space as the existing VHDs and snapshots, and it might take a while to finish. Another option is to specify another path. If the folder doesn't exist, it will be created. This would let you create date-named folders as seen below in Figure 4.

However you choose to do it, the virtual machine will be a top-level folder as you can see in Figure 5.

It is also possible to select a number of virtual machines in Hyper-V Manager and export to the same top-level directory. Remember, the virtual machine must be turned off. Each virtual machine will get its own folder structure under the specified path.

Using PowerShell to Export a Virtual Machine

Another approach is to use PowerShell to export the virtual machine (assuming you are running Windows 8 or Windows Server 2012 and have Hyper-V installed). In the Hyper-V module, you can use the Export-VM cmdlet. You can export a VM by its name.

PS C:\> export-vm "test rig" -Path E:\Exports  Or as a virtual machine.  PS C:\> get-vm "test rig" | export-vm -Path E:\Exports

The same rules apply: You can't have an existing export with the same name in the target path. This makes it easy to get a number of virtual machines and export them all at once.

PS C:\> get-vm "test*" | export-vm -path E:\Exports\2012_10_04

The cmdlet won't write anything to the pipeline unless you use –Passthru. Also be aware that Export-VM does NOT support –Whatif or –Confirm, although you could wrap this up in a function and add your own –Whatif as well as better error handling for things like existing files.

Because the export can take a long time, you can use the cmdlet's –AsJob parameter.

PS C:\> get-vm jdh* | export-vm -Path E:\Exports\2012_10_04 -AsJob
Id Name PSJobTypeName State HasMoreData Location Command
2 Job2 NotSt... True get-vm jdh* | ...
3 Job3 NotSt... True get-vm jdh* | ...

You get a job for every virtual machine, and you can let them run in the background while you keep working. Overall, using PowerShell is great because it means you can set up a PowerShell scheduled job or a task to perform periodic exports.

The Export feature in Hyper-V is a handy way to perform relatively fast and easy backups, especially if you export to removable drives. Yes, there are dedicated Hyper-V backup utilities, but in some situations, exporting may be all that you really need.

Microsoft System Center

Investigating the Microsoft System Center product suite for the first time can be an overwhelming experience, an endeavor not easily taken by the faint of heart. The number of products bearing the System Center logo has steadily increased over the years, but not without some casualties along the way (and with a few name changes to keep things interesting). Keeping abreast of this constantly evolving suite is almost becoming a full-time job. In order for us to successfully navigate our way to delivering some truly impressive System Center-based IT solutions, a little trip back in time will help us understand where we might be going.

What Is Microsoft System Center and Where Did It Come From?

We begin our adventure a long time ago around the year 1994, in a far away place called "One Microsoft Way", where a wise old man realized that with the growing number of computers being deployed in offices and companies around the world, there had do be a better way to manage hundreds (and even thousands) of PCs at once. Clearly a utility was required to simplify the process of installing software, gathering inventories, and ensuring the basic health of these devices, and so it was that Systems Management Server (SMS) 1.0 was born. Over the next few years SMS evolved, and version 2.0 was presented  in 1999, which also happened to be the year when Microsoft revealed Active Directory.

A short few months later, a new management product called Microsoft Operations Manager was introduced that focused on monitoring the health, availability and security of services. In the course of the following 6 years the umbrella name "System Center" was introduced for these system management tools, but unlike many other Microsoft products -- like Microsoft Office and the individual Office suite products -- these disparate System Center components continued to be developed and released on independent cycles.

By 2007/8 the list of products had greatly evolved, and the product family now consisted of:

    * Operations Manager, now maturing as the go to tool for monitoring all Microsoft hosted services, using a sophisticated Management Pack product knowledge system.
    * Configuration Manager (formally SMS), now extended with the ability to deploy Operating Systems to bare metal computers.
    * Data Protection Manager, a disk based backup solution leveraging windows volume shadow copy technologies
    * Capacity Planner, focused on assisting the IT Pro with managing and sizing their ever more complex IT infrastructure's
    * Reporting Manager, a reporting solution designed to consolidate the data from all the above products to create comprehensive reports

Just a few months later, and with the introduction of Windows Server 2008, Microsoft added yet more products to the System Center family:

    * Service Manager, a new Help desk product based on the ITIL standards
    * Virtual Machine Manager, designed from the ground up to manage the growing sprawl of Virtual Machines, while adding both a standards approach and a Self- Service experience.

Microsoft System Center 2012

Now, in the dawn of the cloud computing era, even more changes abound. Microsoft has internally reorganized its teams and processes, focusing Windows and System Center products to be the foundation pillars for delivering, managing and operating cloud services, both on and off premise. Utilizing a scenario based approach, in favor of the old product centric task based methods, we now focus on delivering  tightly integrated solutions, comprised of technology components which when utilized together enable the Cloud OS and deliver business ready solutions.



Supporting this initiative the Microsoft System Center product family has become a single suite (not unlike Microsoft Office), with its components being on the same development and release cycle. System Center now also includes some service offerings hosted on Azure.

• Orchestrator, a new automation engine, using a "Visio" style designer canvas to draw "runbooks" for automating IT activities.
• App Controller, a new self service portal extending on the features of Virtual Machine Manager, while also integrating with Auzre VM Services.
• Advisor, also cloud based; offering an Operations Manager style monitoring experience, using real-time knowledge from the MS Customer Support teams, can be used with without Operations Manager deployed.
• Global Services Monitor, an extension to Operations Manager, leveraging the global infrastructure of Azure to enable monitoring of your public services from anywhere on the globe

VMware Horizon Suite Licensing Explained

Earlier this year VMware formally announced the release of the VMware Horizon Suite as its End User Computing (EUC) offering. Horizon is a mix of new and existing products, along with some licensing changes that impact how some of the products can be used and licensed. I'll break down the options for licensing Horizon Suite and cover the recent changes.

VMware Horizon Suite Licensing: What's Involved

Horizon Suite is made up of the following products: Horizon View for virtual desktops, Horizon Mirage for physical desktop management, and Horizon Workspace that now includes application management and a data service similar to Dropbox. In the near future Horizon Workspace will be expanded with the release of Horizon Mobile that will bring mobile device management to the suite.

Currently there are two licensing options for Horizon Suite: Named user licensing and concurrent user licensing. The individual products have various methods of licensing, so I'll break down the options for the suite first then the individual products.

Named User Licensing

The named user license was the only available option for purchasing Horizon Suite at the launch. This meant that a license for anyone accessing the solution would need to be purchased. This was not an issue for all customers but for ones that run shifts of people (such as hospitals or call centers) were not excited about the limited licensing options. The named user license had a retail cost of $300 per user and would result in additional expense to designs that did not mesh with this method.
Concurrent User Licensing

The concurrent user license model was just added as an option for Horizon Suite. It was not immediately available when the suite was released, there was some grumbling by customers that caused VMware to update its offering. In the past customers where used to consuming VMware View on a concurrent user model. In VMware licensing terms a concurrent user count is considered to be the maximum number of active connections to the solution at any given point. This change offers greater flexibility to customers that have workers that run in shifts that might use the same endpoints but their usage is spread over multiple shifts during a day. So while the maximum number might be the same it results in a lower amount of licenses required. The retail published pricing for Horizon Suite concurrent licenses is $500 per concurrent connection.

Individual Product Licensing

If you purchase any of the three products (View, Mirage or Workspace) separately the licensing options are listed below.

    Horizon View - Only one version is now available and it runs $250 per concurrent user
    Horizon Mirage - $150 per named user
    Horizon Workspace - $150 per named user

How to Store Hyper-V Virtual Machines on SMB 3.0 Storage

How to use and store Hyper-V virtual machines on SMB 3.0 storage. People expect this process to be extremely complex, but it's not. If you can create a shared folder and set the permissions on the share and folder, then you already know how to use SMB 3.0 shares for Hyper-V.

Hyper-V Virtual Machines on SMB 3.0: Configure Default Storage Locations

Hyper-V has a default location for storing the files of new virtual machines and another default location for new virtual hard disks:

    Virtual hard disks: C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks
    Virtual machines: C:\ProgramData\Microsoft\Windows\Hyper-V

These are pretty dumb locations to use no matter what kind of storage you use. We would recommend that you always change both of these locations to the following.

    D:\Virtual Machines or similar: If you are using direct attached storage (DAS) to store virtual machines
    C:\ClusterStorage\Volume1 or similar: In the situation where you are creating a Hyper-V cluster with a traditional SAN and Cluster Shared Volumes (CSVs)
    \\FileServer\ShareName or similar: When you want to use SMB 3.0 storage whether the hosts will be clustered or not

Below you can see that the UNC path to a file share on a Scale-Out File Server (SOFS) was used to define both default locations in the Hyper-V Settings of a host in Hyper-V Manager. This means that any process of creating a new virtual hard disk or virtual machine in Hyper-V will use this file share. You can override the choice of location. Tip: Verify that the hosts and Hyper-V administrators have Full Control access to the share and folder.

Specifying default storage locations in Hyper-V settings.

Creating Virtual Machines

Most people seem to expect some additional complexity when creating a virtual machine on a shared folder. It's no different to use local storage or CSV; you just specify a UNC path that the host (or hosts in the case of a cluster) and administrators have access to, as you can see below.

Specifying the path of a new virtual machine.

If you do not check the Store The Virtual Machine In A Different Location box, then the files of the virtual machine will be created in the root of the folder. This is the unfortunate default action, and it leads to a messy collection of files names after the GUIDs of the associated virtual machines.

Check the box, and you'll store the files of the new virtual machine in a sub-folder named after the virtual machine – a much tidier solution. Note that System Center – Virtual Machine Manager uses this default folder process by default.

During the New Virtual Machine Wizard, the default option is to create a Dynamic VHDX file as the boot virtual hard disk of the virtual machine. You can see that this file is being stored nicely in a sub-folder called Virtual Hard Disks in the virtual machine's own sub-folder.

Default VHDX location for the new virtual machine.

Finally the virtual machine is created with all of the virtual machine's files stored on the shared folder.

The new virtual machine's files on the SMB 3.0 share

The process is the same no matter what tool you use, be it Hyper-V Manager, PowerShell, Failover Cluster Manager, or Virtual Machine Manager (VMM).

• Set the permissions of the share to include the host(s) and Hyper-V administrators (with the required reboots/logins if users/servers are added to a security group).
• Specify the UNC path of the share instead of a local path.

Note that VMM simplifies this process as follows.

• You can add the shared folder as a storage location to host/cluster properties in the VMM console.
• VMM will set permissions using a Run As account that has administrative rights on the SOFS or file server when you assign the share.

Additional Benefit of SMB 3.0 Storage

There is an additional benefit of using shared folders to store virtual machines beyond simplification, cost reduction, and the performance of SMB 3.0. Unlike a CSV where a cluster member is the coordinator (owner) of that volume, no Hyper-V cluster member owns the SMB 3.0 share.  The same applies to a non-clustered host; virtual machines aren't stored on single owner DAS. A folder can be shared with more than one non-clustered host, multiple Hyper-V clusters, or a mix of Hyper-V clusters and non-clustered hosts.

With Live Migration you can easily move virtual machines across your entire Windows Server 2012 Hyper-V and/or Hyper-V Server 2012 estate… assuming that your host/VM licensing is adequate, of course. Files never move; they reside on the shared folder and the virtual machine's running state is copied and synchronized between the source and destination host. Note that in the case of cross-cluster migration (Live Migration to/from one cluster to another, or to/from a non-clustered host):

• Disable high availability of the VM on a source clustered host (remove it from the cluster) before Live Migration to a non-clustered host or another cluster.
• Enable high availability  of the VM on a destination clustered (add it to the cluster) after Live Migration from a non-clustered host or another cluster.

Doing the above has no downtime for the VM. You do not need to do the above when live migrating a VM between hosts in the same cluster (things are simple there).

An additional benefit of using SMB 3.0 storage is that it will simplify "upgrades" using Cross-Version Live Migration, a new feature in WS2012 R2 Hyper-V and Hyper-V Server 2012 R2. Simply build the new hosts/clusters, grant them rights to the new file share, and live migrate (one-way only) from 2012 to 2012 R2. There is no need for any down time or duplication of storage.