What is the Private Cloud?

What is this “Private Cloud” thing anyway?

The simple term is that it is a pool of compute resources that runs on hardware that you own (it is in your datacenter). 

But, that just means that I am running virtual machines, right?

Not exactly.  It means that there is some type of automation framework in front of the hypervisors and the virtual machines that is providing some type of orchestration.  This could be XenServer + VMLogix or Hyper-V + SCVMM.

At the same time, virtual machines are not required – but it is easier with virtual machines.

HPC from Microsoft, the old fashioned mainframe, the Cray – these are examples of private clouds that have been around, performing massive calculations, they are orchestrated; they meet the definition.  But they require custom written applications so they work well in very specific situations.

The recent “Private Cloud” term tossed out by Microsoft I think can be summarized in this way:

• Private Cloud is owned by you.
• Private Cloud is dynamic (in some way)
• Private Cloud is at least Hyper-V (but it can be more as you need it to be).
• Private Cloud has OEM reference hardware designs (these are tested and known to work, but they are not the only option)
• Private Cloud is NOT all boxed up and sitting on a shelf somewhere. (it is not a SKU that you purchase)
• Private Cloud is not defined by a specific set of prescribed technologies.
• Private Cloud must be pieced together by you (the architect, the enterprise, the planner – you must know what your requirements are).
• Private Cloud is NOT Microsoft only technologies.

Private Cloud is your enterprise datacenter.  Enabled to be nimble and adaptive through technologies that make it dynamic.  Some of these technologies are:  Hyper-V, SCVMM, SSP, Operations Manager, Configuration Manager (basically any of the System Center group added on top of your infrastructure that happens to be running as virtual machines).

In the Citrix world I could describe the same, or I could have a mash-up of Citrix products with Systems Center products.  The end result would be the same – a Private Cloud.

This is where the big disconnect is happening and all of the confusion is currently happening.  Private Cloud is a term, a term that summarizes a conglomeration of technologies that are working together to make an IT shop more efficient, more nimble, more self-service.

Cloudy in the Private Public and Hosted worlds

Today there was a thread in the forums that brought up the new buzz word: “Private Cloud”

There is currently a lot of hype, questions, and confusion about this term – it is not a new term by the way – since it was used at TechEd 2010 in Berlin.

The original poster appears just as confused as the majority of folks as to what this term might mean.  And in the industry so far this seems to be the current state of things.  The question:  “What is a cloud?” 

My take on “cloud” is that it is a pool of compute resources that works in some way and it is in some place.  That seems to be the cross vendor understanding of cloud.

Today there are a few “cloudy” terms floating around.  Private, public, and hosted.

Private Cloud is a cloud that your (as an enterprise) own and run.  It is your traditional datacenter.  But set-up and managed in a way where it does not matter where the application runs as long as the application runs.

Public Cloud is a cloud that is “out there” and runs at a facility owned by someone other than you.  And the key is that you purchase compute resources on that cloud.  Azure is a really good example of this.  Amazon EC2 as well.

Hosted Cloud is a cloud that is “out there” and runs at a facility owned by someone other than you as well.  They key here is that it is provisioned and billed more like a co-location facility.  You have “machines” that you purchase – not highly generic capacity.  This is more like the Rackspace or upcoming Azure VM Role models.

 

The most interesting part of the entire thread that caused me to begin this post in the first place is that HPC was mentioned by the original poster.  You know, you could think of HPC as a private cloud.  Just as a good ‘ole mainframe could be a private cloud.

Here is how I responded to the thread – simply to broaden the thinking beyond a simple hypervisor:

I wanted to jump in to this thread as there are two distinctly different technologies being discussed. And since the OP is coming from the education industry both or neither could apply.

The term "Private Cloud" is simply a set of processing resources that you own and therefore control. It is not remote. That is all that we really know today. Beyond that, it is not clear if this is a combination of technologies, a SKU bundle, a pre-installed hardware package, etc.

HPC, Azure Appliance, and Hyper-V + SCVMM are all options that would give you something that you could refer to as a private cloud.

HPC is a platform designed for distributed processing - many individual nodes that provide CPU and contribute back to the primary job. This can be thought of as very mainframe-ish. I over-simply the concept and think of it as the SETI@Home or Folding@Home model - as it is a large compute. This requires custom written applications.

Azure is a platform - that is making breaks in the education realm right now - but it is not private. It is a pool of processing resources that can be scaled out and back on demand. It is HPC-like in concept, but Hyper-V-like in large scale implementation. MSFT owns and manages the hardware, you own the application - you purchase capacity during a slice of time on the Azure platform. This requires custom written applications.

Azure Appliance - this is the cloud version of Azure, but you own it, it is your datacenter, you house the physical hardware - all the other Azure rules apply. You simply don't pay MSFT for time as you own the hardware.

Hyper-V + SCVMM - this is the current model of using virtual machines to run enterprise applications. This allows you to run off-the-shelf applications installed on to operating systems - just as you would with physical hardware. Hyper-V is the hypervisor, SCVMM is the management stack for the virtual machines. Adding the VMM SSP 2.0 in front of SCVMM provides additional functionality.

Each one of these fits in different places and for different reasons. And they could all be referred to as "cloud" in some way or another. As it is very unclear what "cloud" really means beyond being a pool of compute resources.

In the end, it really comes down to what you require. Large complex calculations would gravitate to HPC or Azure. More traditional workloads would gravitate toward Hyper-V + SCVMM.

Migrating a XenDesktop environment from VMware to Hyper-V

I have had a recent need to migrate a working XenDesktop environment from VMware over to Hyper-V. One thing that is important to this process is SCVMM.

Following are some guidelines that can be used by most anyone who is in this situation.

The (fully) Virtual Environment:

• XenDesktop 4 Desktop Delivery Controller (Windows 2003 R2, x64, 2vCPU, 4GB RAM, 1 NIC)
• Licensing Server (Windows 2008, x86, 1 vCPU, 2GB RAM, 1 NIC)
• Web Interface server (Windows 2008 R2, 2 vCPU, 4GB RAM, 1 NIC)
• Provisioning Server (Windows 2008, x64, 4 vCPU, 16GB RAM, 1 NIC)
• Master VM (the VM where the desktop image is installed, Windows 1, 1 vCPU, 1GB RAM, 1 NIC)
• PvS Template (the VM template that is cloned to create new Desktop virtual machines)
• Desktop VM (the actual virtual machines that the Provisioning Server image is streamed to and runs the users applications)

Manage vCenter from SCVMM:

1. Use the “Add VMware VirtualCenter server” option in SCVMM to place the vCenter environment under the management of SCVMM
1. Don’t fear, this does not take full control of the environment, by default it will just enumerate everything.
2. Update the Security Settings of each ESX host.
1. Right click each ESX host and add the security settings for the “root” account.
2. If these are new installation of ESXi the root password is blank by default, SCVMM does not accept blank, so a password must be set.
3. Wait a bit for “bake time” to happen
1. This is a bit of time for all of the elements in the environment to be enumerated and fully recorded properly.

Store each VM in the SCVMM Library:

1. Store a VM in the Library
1. Power Off a VM
2. Right Click and Select “Store in Library”
1. This will delete your VMs from the VMware ESX servers.
2. Set the MAC address of the VM
1. From the Library View select “VMs and Templates”
2. Right click the VM and select Properties
3. Select the Hardware Configuration tab and select the Network Adapter
4. Change the MAC address assignment to static (note that the Current address is set) and select OK
5. If the VMs are diskless and boot from a Provisioning Server be sure that the network adapter type is “Emulated”.

Deploy each VM to a Hyper-V hypervisor:

1. Convert each VM to deploy it on Hyper-V
1. From the Library View select “VMs and Templates”
2. Right Click the VM and select Convert Virtual Machine
3. Complete the wizard with one of your Hyper-V servers or clusters.
2. Repeat as necessary.
1. The conversions will have a job status of “Completed w/ Info” because these VMs do not contain boot volumes, so the conversion process does not find one.

Application Configuration Update:

1. Double check DNS and IP address settings
1. The conversion process will install the Integration Components into the VM and thus the OS in the VM will detect a new NIC. If the IP addresses are manually set, then they will need to be set again. If the IP addresses are assigned by DHCP the same IP address should be granted because you carried the MAC address forward (step 5).
2. The XenDesktop installation uses Fully Qualified Domain Names and therefore relies on DNS, so make sure that all of the machine names are resolving properly.
2. Double check all Provisioning Server Settings
1. If the IP address of the Provisioning Server VM has changed be sure to make that configuration change in the Server configuration of your Site.
2. Don’t forget that your VM images will need an “Emulated” network adapter for the network adapter that Provisioning Server will use to stream to the VM.

Update the Desktops and Desktop Groups

1. Update the vDisk Image from the Master VM
1. Be sure to set the vDisk to read / write mode in its settings in Provisioning Server.
2. A gotcha to be aware of: the PVS driver binds to the NIC driver of the machine when it is installed. Converting the VM to Hyper-V installed the Integration Components and removed the VMware tools; causing the NIC and / or driver in the VM to be changed and therefore breaks the PVS Image driver. To resolve this uninstall and re-install the PVS “Target Device” software on the Master VM.
3. Run XenConvert to update the vDisk with the latest working Master VM image.
4. Set the vDisk back to Standard Image mode.
2. Create new Desktop Groups
1. New Desktop Groups need to be created using the XenDesktop management console.
2. Or the old Desktop Groups need to be deleted and created again using the new Hosting Infrastructure.
3. Verify your Desktop Group is working
1. Now that all settings are in place; wait for the DDC to refresh the desktop groups and to spin up virtual machines for the idle desktop pool.
2. Check the console of a few VMs to see that the PVS image is streaming properly and connect to a desktop.

The summary

With one practice run I would feel confident in understanding the process to do this with a production environment – I would probably handle it in stages – but I would know enough to be able to properly plan.

The key to this process is that the VMs undergo a two-step process. First storing to the SCVMM Library and then converting to a Hyper-V hypervisor. The bonus is that the MAC address can be carried forward from the VMware environment. This makes no changes in the setup of Provisioning Server groups.

In Summary:

1. Manage vCenter from SCVMM.
2. Store the VM(s) in the Library
3. Set the MAC address of the VMs to static (to not change settings in Provisioning Server)
4. Convert the VM(s) to a Hyper-V hypervisor
5. Update the vDisk Image
1. Uninstall and re-install the PVS client due to the virtual NIC driver changing.
6. Re-create / create new desktop pools

Hyper-V Dynamic Memory as a tool for understanding your Applications

In case you missed it, MSFT is making a bit of noise about the new Dynamic Memory feature that is coming in the SP1 release for Server 2008 R2 / Hyper-V Server R2.

My angle on this is a bit different than most.

The way that Dynamic Memory has been implemented by the MSFT folks is rather interesting.  It is memory ballooning under the hood – but it is hooked into the operating system of the VM in a way that only Microsoft could (as it owns the OS in this case).

What I find most interesting is the way that the Dynamic Memory feature responds to the needs of the application that is running in the virtual machine.

If the application begins needing additional RAM, then Dynamic Memory attempts to give it some, once the application frees up the RAM, then Dynamic Memory takes it back away.

This has the net effect that your machine is always running in an optimal ‘sweet spot’ as far as RAM is concerned.

The most interesting part is that you can perform actions against your VM and you can see how Dynamic Memory responds and in turn understand how your application demands additional RAM.  You can load it to a certain level and get a really good baseline.

Considering that managing a virtual environment is still a bit of a black art this is highly useful in really understanding the demands of your workload in a way that means something.  This directly correlates to a resource – RAM of all things – a very finite resource in most cases.

The end result is that you get a really good indicator of the range of RAM that your workload really needs.

I have said for years that most folks give their servers too much RAM (especially VMs) – and this is a great tool to prove it and to give a really excellent indication of the true RAM utilization of your workload.

Yes, you have to observe the numbers (in the UI or through polling WMI) but I think the return that you get for your time spent doing that is well worth it.

Migrating a XenDesktop environment from VMware to XenServer

I have had a recent need to migrate a working XenDesktop environment from VMware over to XenServer.

Following are some guidelines that can be used by most anyone who is in this situation.

The (fully) Virtual Environment:

• XenDesktop 4 Desktop Delivery Controller (Windows 2003 R2, x64, 2vCPU, 4GB RAM, 1 NIC)
• Licensing Server (Windows 2008, x86, 1 vCPU, 2GB RAM, 1 NIC)
• Web Interface server (Windows 2008 R2, 2 vCPU, 4GB RAM, 1 NIC)
• Provisioning Server (Windows 2008, x64, 4 vCPU, 16GB RAM, 1 NIC)
• Master VM (the VM where the desktop image is installed, Windows 1, 1 vCPU, 1GB RAM, 1 NIC)
• PvS Template (the VM template that is cloned to create new Desktop virtual machines)
• Desktop VM (the actual virtual machines that the Provisioning Server image is streamed to and runs the users applications)

The Export:

1. Use vApp containers to export OVF packages as groups of machines
1. Organize the XenDesktop application tier machines into a vApp container named “Infrastructure”. This is so they can be exported as a group of machines in a single OVF package.
2. Power off the Infrastructure vApp (this can also be done individually by virtual machine).
3. Export the Infrastructure to an OVF package
1. Be sure to select the Infrastructure container and choose File, Export, Export OVF Template. Leave the option to export to an OVF (a folder of files) – this speeds up the process since there is no requirement for creating a single OVA file (which takes longer to export and import).
4. Export the Master VM
1. To keep the Master VM as uncluttered and clean as possible it is recommended to uninstall the VMware Tools prior to export.
5. Export the PvS VM Template
1. If for no reason other than documentation purposes because the OVF contains all of the settings of the original template. With XenServer it is recommended to use an included base template for optimal configuration.
6. Export the virtual desktops - an additional export consideration
1. Before exporting the currently deployed virtual desktops there are two options to think about. Do you export your existing virtual desktops (this is highly useful if they have local cache disks on the hypervisor) or do you not export your existing virtual desktops. In both cases you need to create new desktop groups on the Desktop Delivery Controller.
2. If your Desktop VM images were derived from a template (for example: using the XenDesktop Setup Wizard) the deployed desktop virtual machines probably have dynamic MAC addresses assigned to the VMs.
1. The VMware OVF does not record the currently assigned MAC address if it is set to dynamic. This means that when imported these machines will be assigned new MAC addresses.
3. If Provisioning Server is used; the “auto add” feature can be implemented, to automatically add the Imported desktop VMs to Provisioning Server or the MAC addresses of each VM can be updated in the XXX configuration of Provisioning Server.
4. If you choose to not export the existing Desktop virtual machines you can create new Desktop groups using the PvS Template with the XenDesktop Setup Wizard on the XenServer environment.

In this example I elected not to export the virtual desktops. Primarily because they are pooled and there is little benefit in doing so.

The Import

1. Import the OVF packages into XenServer using the fix-up option
1. From XenCenter select a target XenServer, Resource Pool, or folder and launch the Appliance Import Wizard from the File menu.
2. Browse to the Infrastructure OVF package and begin the import. Be sure to use the “fix-up” option because these machines were built on ESX server.
2. Install XenTools into each VM in the environment
1. Before powering on each VM be sure to check that the original VM is powered off (or disconnected from the network). Otherwise there will be two of the same machine on the network at the same time.
2. Log into each VM and install the XenServer tools, reboot, and proceed to manually fix any network settings. Don’t forget the Master VM.

Application Configuration Update

1. Make any setting changes to the XenDesktop and Provisioning Server applications
1. If you didn’t already do so login to the XenDesktop console and disable the Desktop Groups specific to the VMware environment
2. The XenDesktop installation uses Fully Qualified Domain Names and therefore relies on DNS, so make sure that all of the machine names are resolving properly.
2. Double check all Provisioning Server Settings
1. If the IP address of the Provisioning Server VM has changed be sure to make that configuration change in the Server configuration of your Site.

Update the Desktops and Desktop Groups

1. Update the vDisk Image from the Master VM
1. Be sure to set the vDisk to read / write mode in its settings in Provisioning Server. Also, modify the machine configuration in Provisioning Server with the new MAC address of the Master VM.
2. A gotcha to be aware of: the PVS driver binds to the NIC driver of the machine when it is installed. Migrating the VM to XenServer and installing XenTools and uninstalling VMware tools all cause the NIC and / or driver in the VM to be changed and therefore breaks the PVS Image driver. To resolve this uninstall and re-install the PVS “Target Device” software on the Master VM.
3. Run XenConvert to update the vDisk with the latest working Master VM image.
4. Set the vDisk back to Standard Image mode.
2. Use the XenDesktop Setup Wizard to create new Desktop Groups
1. Create a new VM in your XenServer environment (using a XenServer template)
2. Convert this to a Template
3. Run the XenDesktop Setup Wizard to build out a new set of replacement desktop images.
3. Verify it is working
1. Now that all settings are in place; wait for the DDC to refresh the new desktop groups and to spin up virtual machines for the idle desktop pool.
2. Check the console of a few VMs to see that the PVS image is streaming properly and connect to a desktop.

The summary

With one practice run I would feel confident in understanding the process to do this with a production environment – I would probably handle it in stages – but I would know enough to be able to properly plan.

In Summary:

1. Use vApp containers to export OVF packages that contain groups of machines.
2. Import the OVF packages into XenServer and use the fix-up option.
3. Install XenTools into each VM in the environment.
4. Double check network settings (including DNS) of each infrastructure VM.
5. Make any modifications I needed in Provisioning Server settings for new VM MAC addresses and Server IP address changes.
6. Update the vDisk Image
1. Uninstall and re-install the PVS client due to the virtual NIC driver changing.
7. Re-create the desktop pools

The Video Companion

For the impatient among us I have outlined the basic steps and gotchas in the following video:  http://www.citrix.com/tv/#videos/2748