Here, I take a deeper dive into failover clustering, clustered shared volumes and storage. Enjoy!

Failover Clustering
In order to get all of the benefits of High Availability and similar features that require the use of shared storage between your Hyper-V hosts in a “cluster,” you must install the Failover Clustering role on your Hyper-V hosts. This is, as the name indicates, what allows you the ability to “cluster” the hosts together.

Installing this role is just as easy as installing the Hyper-V role – simply check the box under the Features in the add new roles/features wizard, and it will run through the install. It’s worth noting that the server on which you are installing the role must be a member of the domain at the time of installation, or it won’t go through with the install.

Once the feature is installed and the server is rebooted, you must run through the Pre-Cluster Validation report, which will check out the hardware, drivers, etc. and alert you to anything that would prevent your cluster from working and/or being supported by Microsoft. See Part I for the importance of having HCL-listed hardware.

From here, you create a new cluster, give it a name, an IP address, etc. and add your single node into it. Rinse and repeat to add additional hosts.

Any network interfaces that have an IP address assigned to them (as is usually the case for interfaces or NIC teams that are used for management, cluster heartbeats, or iSCSI storage access) will show up as Networks in the Failover Clustering management interface. You can rename them to be more readable, and as long as the subnets stay the same across hosts, all hosts can share those networks without having to do anything special to keep the names consistent.

Jumping ahead to the future state of a common Hyper-V 2012 deployment without System Center Virtual Machine Manager (SCVMM, which we’ll mention in more detail later), the Failover Clustering management utility is where you will be able to migrate your virtual machines across nodes in your cluster.

Clustered Shared Volumes
To briefly define a “Clustered Shared Volume” to someone familiar with ESXi, consider it the equivalent of a VMFS datastore. It’s essentially a unit of storage that is able to be accessed by multiple hosts at the same time, just like the VMware File System (VMFS) allows. It’s similar to a clustered file system given the nature of its functionality, but it still runs Microsoft’s well known NTFS as the underlying file system.

In order to add a CSV to a cluster, you present the storage as appropriate for your configuration and vendor’s best practices, and it becomes available to the “Add Disk” wizard, as available and cluster-capable storage. Once it has been added, you can then right click it and select “Add to Clustered Shared Volume.”

Storage
One of the bigger advantages VMware/ESXi still has over Hyper-V is its built-in, native multipathing capability. For those unfamiliar, NMP allows the use, failover, failback, and in some cases, load balancing/load distribution of all the paths to your shared storage array.

The only equivalent utility natively available in Hyper-V 2012 is the MPIO driver, which combines its use with the built-in iSCSI initiator. Microsoft has its own “generic device specific module,” and you should check with your storage manufacturer to verify that using the Microsoft DSM is supported for access to the storage (EMC VNX IS supported).

For those who are familiar with and have used the VMware NMP beyond “install and let it run,” you know how incredibly valuable and efficient it is in nearly all deployment use cases (aside from NFS, which is a different beast entirely).

It’s worth noting that storage vendors such as EMC provide their own multipathing plugins or software that you can use to provide highly enhanced, optimized path management, load balancing, and failover. In EMC’s case, this software is their PowerPath V/E, or Virtual Edition, and it makes a great add-on to any Hyper-V 2012 + EMC Storage deployment.

Stay tuned this week for Part III which will take a look at performance and management features with my final conclusion wrap up.

The post A Look at Hyper-V 2012 – Part II appeared first on eGroup.

Installation 

For those who aren’t aware, Hyper-V 2012 can be installed as a Server Role on top of Server 2012, and the installation process (once the OS is already loaded) is just about as easy as it gets. You check the box for the Hyper-V role in the add new role wizard, and in a few minutes, it’s installed and live on your server. There is also a standalone, Core-only (command line only) version called Hyper-V 2012 Server, that you can install onto the server hardware directly. The difference here is that the Role added on Server 2012 includes licensing for Server OS virtual machines that will run on top of the host, whereas the Hyper-V 2012 Server installation does not. In addition, Hyper-V Server is command line only, as it runs the “core” installation of Windows Server.

I won’t spend much time on the licensing details other than to say unless you are running a small number of virtual machines, going the Datacenter edition is probably going to be the best bang for the buck, as it covers an unlimited amount of Windows Server OS VMs that run on the licensed host. To state it another way, once you pay for the Datacenter Edition license, install it on a server, and enable the Hyper-V role, all other server VMs that you subsequently run on that physical server, require no additional Server OS license.

It’s important to note that at this point, you have the equivalent of a standalone hypervisor server– a “standlone ESXi host” is a good point of comparison. You do not have the benefits of high availability, live migrations for either the virtual workload or its underlying storage, and no dynamic workload balancing.

Hardware Considerations

Throughout our time installing, upgrading, and managing Hyper-V hosts, we’ve found that Microsoft is very picky about the underlying hardware used, and reference their hardware compatibility list in several documents and interfaces (especially in the Failover Clustering interface, which we’ll get to later). While an HCL exists from the other hypervisor vendors, it’s almost a background consideration in a lot of cases, as compared to Microsoft’s position of putting the HCL “front and center.”

Given this fact, we’d strongly suggest to anyone deploying Hyper-V 2012, and especially those who are upgrading from previous versions, that you very carefully validate that your hardware is certified for Server 2012 before going into production.

Networking

One of the major improvements in Server 2012, which has an upward and positive impact to Hyper-V, is the addition of NIC Teaming through the Server 2012 OS itself, as opposed to only being available through the use of vendor specific teaming utilities.

The result here is a very similar capability to what I’ve been accustomed to having from VMware for some time now. NIC Teaming provides the ability to load balance NICs from different vendors, NICs that are on the motherboard with NICs that are add-ons through a PCIe slot, as well as load balancing of traffic through the NICs (in an “active/active” manner) without any configuration on the upstream switches.

Additionally, you can load balance your NICs in an active/standby configuration, or the commonplace active/active with “switch awareness” (a port channel in the Cisco world– which can be “static”– channel-group mode on in Cisco terms, or using LACP, channel-group mode active in Cisco terms).

Assuming a standard 6 or 8 NIC server design, the only real “difference” in the networking configuration for a Hyper-V server as opposed to an ESXi host is that there is generally a NIC (or two) dedicated for “outside of Hyper-V” server OS communication. This can be done with a team, and is something that should be discussed as part of your design and hardware purchase (to ensure you have the correct amount of NIC ports).

Hyper-V Virtual Switches

This topic took me a little while to understand how it actually applied, especially since I was trying to relate it to what I was used to working with from VMware.

Imagine that you have 2 NICs in an active/active, switch independent team, that you’d like to use for the “normal” virtual machine network/LAN traffic. First, you must create this team using the NIC Teaming interface through the Server Manager in Server 2012 (this is done OUTSIDE of Hyper-V, as it’s an OS feature, and not a Hyper-V specific feature).

Once configured, note the non-editable name that Windows assigns to the logical team interface, as this is what you will be creating your virtual switch to use as its communication link. This is a minor annoyance. Being able to change the name to something more usable, or having Hyper-V use the team name as opposed to the OS assigned name, would be a simple and a more user-friendly implementation. Maybe in a patch or future update.

Staying off of the Hyper-V configuration and speaking specifically to the Server 2012 OS use of the network team interface, you have the ability to specify a VLAN, and can also create additional LOGICAL sub-interfaces off of the NIC team for specific VLANs. If you set no VLAN, the interface will listen for traffic on all VLANs that the upstream, physical switch is passing down to it.

If you specify one on the team interface itself, that’s the only VLAN it will be listening for traffic on.

If you create a sub-interface and assign it a VLAN ID, that interface will only listen for that specific VLAN’s traffic, but the logical TEAM interface will continue to listen on all others.

The recommendation for Hyper-V is to NOT create sub-interfaces on the network team interface, and to NOT assign any VLANs to the team interface, but leave the VLAN tagging to the vNICs for the virtual machines (this is a bit different than ESXi’s vSwitching, which we’ll outline further below).

Now, back to Hyper-V. From Hyper-V Manager , you’ll find the Hyper-V Virtual Switch Manager in the top right corner, and once you open it, you’ll have the ability to add a new network. There are three network types, but the most common and the one you’ll want to create to allow virtual machines to talk to your physical LAN is the “External Network” type.

If you create a network called “Server Network,” you’ll notice that you can ONLY assign it a VLAN if you share it with the management OS. What this means is that if you want to tag it with a VLAN at this level, you won’t be keeping it as a dedicated network for Hyper-V, but rather will be sharing it with the Server 2012 OS you installed Hyper-V onto as well. I suggest you NOT check this option, and that you do not assign it a VLAN.

As part of the creation of the new network, you’ll have the ability to select the network interface you want to use for it as well via a drop down menu. Once you select an interface for a new virtual switch, it cannot be used again for another one. This is important to take note of for your configuration.

So at this point, consider the diagram below, taken as a screenshot from ESXi. You have created a virtual switch, and assigned it physical interfaces on which to connect– the center piece, and the pieces to the right.

What you have NOT done, which is what confused us for a while, is create the “VM Port Groups” on the left hand side (See “ExNet” in the diagram).

In a typical VMware deployment, you would create a VM Port Group for each VLAN you wanted to have available to your virtual machines, and in that port group, you would set a VLAN ID. The upstream communication would be on trunking (or tagging) interfaces, and thus providing you with access to the VLANs you need– and this part is the same in Hyper-V. What’s different, however, is that Hyper-V 2012 does not have the concept of a VM Port Group. Instead, you assign a VLAN ID and “virtual port” on the vNIC of the virtual machines themselves.

So let’s say that Server Network has access to VLANs 10-20, and you want to be on the “DMZ” VLAN, which we’ll say is VLAN 15 in our example. On the VM you are putting in the DMZ, you would go to Edit Settings, find its NIC, and check the box to “Enable VLAN Tagging”, and specific VLAN 15. Then you’d press OK, and the VM would be able to communicate out on the network.

I know this can be a bit confusing, so if you have any questions, please do not hesitate to post in the comments or drop us an email– we’re happy to help clarify!

The post A Look at Hyper-V 2012 – Part I appeared first on eGroup.

After (now almost 40 days), I’m proud to say that I have succeeded, and it wasn’t nearly as hard as I was originally expecting it to be.

To start with, Linux Mint is based off of Ubuntu, which I’ve used on and off for a few years now. It’s kind of the new “hot and trendy” Linux distro for its ease of use, wide device support, and the options it provides for its desktop environment.

The Website is Linux Mint (just don’t judge the distribution by the appearance of the website).

While some strongly dislike the Unity interface on Ubuntu, I have no issues with it. Some complain that it’s too slow, or too “Windowsy,” and maybe it’s because I’m that accustomed to Windows that I don’t notice, but I’ve never had issues with its performance (and that includes running it on a 5 year old Shuttle PC I have at home). The interface itself, while a little more “bold,” has a kind of polished elegance about it.

Moving to Mint and away from Unity, I will say the Cinnamon desktop environment experience on Linux Mint 14 was much more enjoyable – from the smoothness of the “Start menu” to the hot corners which I now find myself addicted to.

To avoid impact on my ability to do my job, I used the Citrix Receiver to hit our internal Citrix XenApp deployment for all Office application needs, including and especially Outlook, as well as some of our other Windows-native applications. And, while it comes with LibreOffice, the free, compatible, and open source Office-like product, I still needed Outlook. This was a no brainer for me, since I use the Citrix Receiver every day on the Mac– as do millions of others. But if you don’t, the Wine software is the way to go. 

I’ve used my own device for work for almost 2 years now (I really live the BYOD dream), and having applications and desktops delivered to my preference of device is very liberating. Without that ability, I couldn’t have run this challenge.

On the client side, offline and accessible locally, I found that almost every one of the “really nice to have” applications were available for debian-based Linux distributions (of which Ubuntu and Mint are), including Skype and Spotify. For anything else, the use of the free “Wine” Windows app emulation layer did the trick.

While onsite with customers, simply connecting to their servers via RDP provided me access to any systems that did not have tools available for Linux clients.

Most of those I told about this little challenge asked me why I would even bother. Well, and the answer is simple: I believe it will become a valuable skill set to have for technologists ranging from the home user, to the veteran sysadmin. I believe, and have shared this belief with my teammates, that Linux, in all of its distributions, will continue to grow in popularity, riding on the back of cloud computing. And with the “bleh” response to Windows 8, and Canonical’s push of Ubuntu into more and more client devices (including smartphones), growth will come on the end user front as well. Do you agree? Am I nuts (yes)?

Do you think you could survive 30 days using Linux exclusively on your personal or work computer? Give it try and let us know!

The post Linux Mint 30 Day Challenge: I survived…think you can too? appeared first on eGroup.

First, there are several reasons why I think this technology is a great step forward. It allows the virtual desktop to be much more “user-friendly” in that the user can customize it, install their own applications, and make it the way THEY want it– versus being “constrained” by the way the IT department wants their desktop to be. This increases user buy-in and morale, and can help push a proof of concept over the last hurdle.

It minimizes the amount of management required for “dedicated” desktops, as you still have a single image to patch, install standard apps on to, etc. It’s also a technology from a 3rd party that used to charge per user, but is now included at no additional cost into the XD offering.

It took almost no time at all to configure and set up, and has worked flawlessly since– it doesn’t require re-learning an entire solution. These are all great and important things.

However, where I see this falling short today is that it requires a user-to-desktop assignment in a 1:1 manner, the same way dedicated desktops do. To recap quickly, what this means is when a user logs in for the first time, they are assigned a specific desktop (let’s say XD15), and every time they log in moving forward, they will receive the SAME desktop (XD15).

So for every user you need a virtual desktop.

There are a few reasons for this, and they’re all good reasons.

The PVD is “assigned” to a desktop for the user, and it stays put on that desktop. It HAS TO stay on that desktop because the “PVD layering” does not get loaded at login. It gets loaded at boot time to allow it to access drivers, system services, and low-system level components some applications require. If this “disk layering” was handled at login, you’d lose that.

It’s also good to note that this is the same situation with Unidesk– a technology very similar to the RingCube PVD technology.

You might be thinking “well that’s not a big deal, I’ll have a desktop for each user (which you may already be doing) and they’ll be able to do everything they need. This still sounds great!”, and I couldn’t blame you for it. But this 1:1 mapping of user to desktop creates what’s known as the “Concurrency problem”.

Let’s say you have a total of 1000 users that connect to your virtual desktop environment each day. They’re broken out into separate shifts of 250 users each, so at any given time, 250 connections and virtual desktop are in use. You’d still need 1,000 desktops provisioned (1 for each user), even though 750 of them wouldn’t be used at any given time in the day.

It’s because of this that a lot of (specifically) VDI solutions combine different desktop pool types, with some as non-dedicated, and now likely some without the PVD feature. The PVD pools could be used for “power users” or executives, and the non-persistent “floating” desktops could be used for task workers. It adds a little bit of management overhead, but not much considering the power of the solution. And it’s likely this is how things will remain for the near term– it’s an acceptable solution/design.

To me, and also to Gunnar (we had a good discussion around this a few times now), the ideal solution for Personal vDisk / Persistent Disk / Unidesk would be to have the PVD, whatever the name is, float with the user and require no desktop assignment. You could create a pool of only the # of desktops needed at any given time and regardless of which desktop the user was connected to, their PVD would “snap-in” and they’d have access to their data, profiles, and self-installed applications. That’s the sweet spot.

Until then, keep the concurrency problem in mind when doing your designs, and be sure to give yourself plenty of disk space in your PVD– you’ll find yourself installing more apps than you originally planned for (I know I did).

The post Citrix XenDesktop 5.6 PERSONAL VDISK – PART III appeared first on eGroup.

On the golden Windows 7 image I created I installed the virtual desktop agent and was presented with this new screen prompting me to enable the PVD on the desktop side.

To take it a little further, I assigned a SECOND USER to the second desktop (username Average Joe) and logged in with that account.

 

To my surprise, the WINRAR application was still available– which leads me to believe the “Personal” vDisk isn’t so much “personal” as much as it was “desktopanal”, which is a new word. What I mean by this is that the PVD stays with the desktop it connects to first, even if a different user is then assigned and logs in (which is what I did).

 

 

As Average Joe I installed Firefox, logged off, then logged back in as the original user and Winrar and Firefox were both available– again, proving that the PVD is tied to a desktop, and not just the original user assigned to it, but any user who then logs in to that desktop.

The post Citrix XenDesktop 5.6 PERSONAL VDISK – PART II appeared first on eGroup.

Here’s a quick overview on the Personal vDisk feature.

The PVD attaches as a separate “disk” to a virtual desktop and “intercepts” IO requests from the user logged in. It then takes these requests and writes them to the PVD instead of the base image disk. Because of this, users can store their profiles, download files, and even install applications with 100%  ”personalization persistence” maintained across base image updates.

PVD Desktops use a “pooled” model instead of the Dedicated model, which retains the simplicity of managing a single base image for updates, patches, standard business applications, etc. and greatly reduces the cost of storage that would be required for the Dedicated desktop model.

Important: However, it’s important to note that while the desktops are pooled, the users are still assigned to a desktop in a 1:1 fashion, and receive the same desktop every time they log in, the assignment is handled automatically on first login.

While admittedly a bit weak in this area, my understanding of the “pre-PVD” pain points were as follows:

• If the user needed to make changes or install apps to their virtual desktop, you used Dedicated desktops.
• Dedicated desktops lose the storage benefits of using a single “master” image, as each desktop can occupy the same space of the original “golden desktop”. If you had a 30GB base image, each virtual desktop could occupy  30GB . Scale that to 1,000 users? Ouch!
• Dedicated desktops also lose the management benefits of having a single image, a single place to install apps, patches, hot fixes and Service Packs, as they’re managed individually like you would in the physical desktop world.

You can see from the list above that while there’s a need and a use case for Dedicated desktops, it’s certainly not the best solution, and it’s here that the PVD can be very useful. In fact, Citrix tweeted that the PVD technology was intended to replace the need and use case for persistent desktops entirely. Check their twitter feed if you don’t believe me. http://www.twitter.com/xendesktop

The post Citrix XenDesktop 5.6 PERSONAL VDISK – PART I appeared first on eGroup.

And for me specifically I’d be moving from my 3G Mifi to the 4G speeds now available in this area.

I’m going to confirm this with Verizon (Apple chat confirmed this was the case, but I’d like to validate it once more before pulling the trigger), and will likely follow up with a post on how I’m replacing my workstation/laptop with an iPad to work

The post iPad – 3rd GENERATION – MIFI! appeared first on eGroup.

After doing some checking and verifying what I had set in the GPO was being “applied” configuration-wise to the server, I stumbled across Ctrix article which outlined our scenario, with the solution.

It turns out that when you install VMware tools, it includes a “Shared Folder” option, which remains locked on user logout and does not allow for the profile to be properly deleted. When this happens, the next time the user logs in to that server, it creates a new profile for them along the lines of “user.domain”, and increments that each time after, as in user.domain.001, user.domain.002, and so on.

The fix is simple– go through and Modify the installation of the VMware Tools, and remove the “Shared Folder” feature from the installation. It does require a reboot, so make sure you plan accordingly, but once that was gone, the profiles operated as desired. What I found to be a little strange is that this issue did not have any impact on profiles managed through VMware’s View Persona Management, which offers very similar features/configuration, but for View environments. Perhaps just a better VMware integration?

http://support.citrix.com/article/CTX122501

The post Citrix User Profile Management – NOT DELETING LOCAL PROFILES appeared first on eGroup.

The next question that came up is an important one to consider in your implementations of NFS on vSphere– and it was the question of “which vmkernel will be used to communicate to the NFS export?”. It’s important to keep in mind that once the connection to an NFS mount is made, it will continue over the same vmkernel AND NIC that was used to establish the connection, so if you get it wrong the first time, it’ll stay that way until you break the connection and re-establish it (which in our case, we tested by unmounting the export, making our changes, and then remounting).

What I had learned a ways back that I believed to still be true was that the the IP of the NFS server would determine which vmkernel would be used by using the vmkernel’s route table, and if no specific route (or same subnet vmkernel interface), the default route/gateway would be used.

What we tested first was simply mounting the NFS export with a relatively “out of the box” ESXi host networking configuration. To the experienced vSphere administrator or architect this is obviously not something you’d do yourselves, but you’d be surprised at how far people take the “NFS is so easy” thought to their implementations, and if they can simply mount it without doing “anything special”, a lot of the time they do.

In our configuration, the NFS server was on a different subnet, and so nothing in the route table matched the desired destination network, and the default gateway was used. This was also the vmkernel that was being used for Management traffic, and made for a non-optimal flow of traffic, especially for storage. To confirm our suspicions, we created a new vmkernel interface on the same subnet as the NFS server, and unmounted the NFS export. Then we mounted it again, and as expected, it used the new vmkernel on the same subnet (via a lookup to the route table) for the communication, and operated as desired.

A lot of reference architectures are being made around the use of NFS, and making sure your network is designed properly is critical to the success of whatever you stack on that file system!

The post NFS on vSphere – NETWORK DESIGN CONSIDERATIONS appeared first on eGroup.

First, we had to shut down the server and assign it an address for use with CIMC so we could hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.

When using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you’re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface– love this interface by the way.

When trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an “HTTP ERROR” status. When we switched over and used the TFTP server option, it worked without issues, and got our CIMC to the 1.2.x code desired. Finally.

From here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the “Inventory” menu on the main Server tab (left hand side).

On the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.

Here’s the fun part– creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. Simply clone an existing vNIC/vHBA or add a new one, set the properties as desired, and fire up the server.

One additional note that’s semi related– other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time– which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).

The post Cisco UCS C Series – P81E VIC & ADDING VIRTUAL INTERFACES appeared first on eGroup.