Punching Clouds

I’ve been asked by a few customers about the location of the VMware ESX\ESXi LUN masking feature and how the LUN masking is done at the VMware ESX\ESXi level in version 4.
In VMware ESX 3.0/3.5 the settings for LUN masking were available in the UI via the Advance Software settings under Disk -> Disk.MaskLUNs as shown in screenshot below.

VMware ESX\ESXi 3.x Disk.MaxLUNs Settings

Well, here is the reason why you can’t find the Disk.MaskLUNs in the UI of ESX\ESXi 4. The component is no longer accessible under the ESX\ESXi’s 4 UI. The chance is implemented as a result of the re-architecture of the storage stack. The VMware Pluggable Storage Architecture (PSA)  is completely new. Old code and features were left behind in order to provide better, faster, and more reliable options and features. The Disk.MaskLUNs access via the UI was one of those left behind.

I agree with the point of taking the LUN masking feature out of the UI. Most vSphere administrators shouldn’t be manipulating those settings, unless they also happen to be in charge of the SAN environment, which hopefully means that there is a good amount of experience with storage technologies. The masking of LUN’s is something that should should be handled by the SAN team and executed on the hardware side.  For configurations such as the presentation and removal of LUN’s and Volumes, it’s best to simply contact the SAN team and ask for a certain LUN or certain range of LUN’s not to be presented to the servers. LUN masking is less error-prone at the storage array than at the hosts.

One reason as to why someone would want to configure software LUN masking (ESX\ESXi) is to protect against screw-up’s by SAN administrators. In boot from SAN scenarios this would be beneficial in order to keep the ESX Servers from seeing each others booting LUN and corrupting them.  With that said, as you can’t configure LUN masking from the UI in ESX\ESXi 4, you’ll have to do it from the Service Console, vCLI or vMA appliance. The new procedures on how to achieve LUN masking in ESX\ESXi 4 are listed below.

vCLI LUN Masking Procedure:

You can prevent the ESX/ESXi host from accessing storage devices or LUNs or from using individual paths to a LUN. Use the vSphere CLI commands to mask the paths. When you mask paths, you create claim rules that assign the MASK_PATH plug-in to the specified paths.

Configuration Steps

1- Check what the next available rule ID is. The claim rules that you use to mask paths should have rule IDs in the range of 101 – 200. If this command shows that rule 101 and 102  already exist, you can specify 103 for the rule to add.

esxcli corestorage claimrule list

2- Assign the MASK_PATH plug-in to a path by creating a new claim rule for the plug-in.

esxcli corestorage claimrule add -r <claimrule_ID> -t <type> <required_option> -P <MASK_PATH>

3- Load the MASK_PATH claim rule into your system.

esxcli corestorage claimrule load

4- Verify that the MASK_PATH claim rule was added correctly.

esxcli corestorage claimrule list

5- If a claim rule for the masked path exists, remove the rule.

esxcli corestorage claiming unclaim <type> <required_option>

6- Run the path claiming rules.

esxcli corestorage claimrule run

After you assign the MASK_PATH plug-in to a path, the path state becomes irrelevant and is no longer maintained by the host. As a result, commands that display the masked path’s information might show the path state as dead.

Implementation Example:

This example masks the LUN 20 on targets T1 and T2 accessed through storage adapters vmhba2 and vmhba3.

#esxcli corestorage claimrule list
#esxcli corestorage claimrule add -P MASK_PATH -r 109 -t location -A vmhba2 -C 0 -T 1 -L 20
#esxcli corestorage claimrule add -P MASK_PATH -r 110 -t location -A vmhba3 -C 0 -T 1 -L 20
#esxcli corestorage claimrule add -P MASK_PATH -r 111 -t location -A vmhba2 -C 0 -T 2 -L 20
#esxcli corestorage claimrule add -P MASK_PATH -r 112 -t location -A vmhba3 -C 0 -T 2 -L 20
#esxcli corestorage claimrule load
#esxcli corestorage claimrule list
#esxcli corestorage claiming unclaim -t location -A vmhba2
#esxcli corestorage claiming unclaim -t location -A vmhba3
#esxcli corestorage claimrule run

For more on Storage masking, check out Duncan Epping’s post on Storage Masking best practice at Yellow-Brick.com. Enjoy!

Alright folks, here is another class from VMware Education. vSphere Manage for Performance. The much anticipated, and needed class that will teach attendees how to manage, and monitor performance in the vSphere environments. This class is categorized as an advanced class as there is a certain level of knowledge, and expertise expected  from all attendees. The completion, and or equal knowledge of the topic covered in the courses listed below are require as well as a fair amount of administration experience of ESX/ESXi and vCenter Servers.

• VMware vSphere 4: Install, Configure, Manage
• VMware vSphere: Fast Track
• VMware vSphere 4: What’s New

There will be a great deal of time spend in the Service Console, and Console like utilities in this class, so if you’re command line junky, this is right for you. The targeted audience are system administrators, systems engineers, and consultants that are responsible to monitoring performance of vSphere installations.

Course Objectives

• Explain the performance impact of using different monitor modes
• Use vSphere tools to monitor the performance of ESX/ESXi hosts
• Diagnose performance problems relating to CPU, memory, network,and storage on an ESX/ESXi host
• Discuss how to achieve an optimal virtual machine configuration Discuss guide lines for monitoring application performance

For more information about this class, and schedule go to the VMware Education site.

For this post, a good friend and colleague of mine, Linus Bourque, is making a guest appearance on Punching Clouds. Here’s what my boy has to say about VMware View:

- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -

I had to chuckle the other day. A friend came up to me and commented how much he hates VMware. I was a bit puzzled. Since he knew I worked for them and I espouse many of the wonderful features I couldn’t quite understand the reasoning behind hating us.

“Uh.. why”, I asked.

“Because I had to put a heater into my datacenter, it’s that good!”, he bellowed with a grin.

It’s true. Virtualization has resulted in the datacenter becoming small again because of server consolidation. But it’s not just servers that can be consolidated. For the longest time, IT departments have been attempting to find ways to regain control over desktops in an effort to reduce the invasion of various malware, the compromise of intellectual property (IP) and resource wasting. Virtualization the desktop can definitely address these issues, particularly when you use a product like VMware View. This can be used from the smallest environment to the largest. Although the official supported preference is that you have one vCenter and one ESXi server (to take advantage of vCenter provisioning and Composer), you don’t have to have that.  Let’s first talk about what the user can experience when logging on. You can use a “thick client” which would mean installing a Windows application. This particular client gives you all the possible bells-and-whistles. You can access USB (if allowed and without RDP redirection), easily access your local printer through the use of ThinPrint engine, ensure single-sign on (SSO) through the use of VMware’s GINA and, with the Offline option, download a virtual machine onto your local system to run there (this feature is experimental at this time). If you have a thin client with Windows XP Embedded (WinXPe) you may be able to install the client on it.

Alternatively you can use a browser to access the View Portal. For Linux and Mac users, at this point, this is the main supported option. For Windows XP, Vista or 2000 Pro clients you would use Internet Explorer. For Linux Firefox with JRE 1.5+ and for Mac, Safari with JRE 1.5+ and RDC 2.0 (free download from Microsoft). We have partnered with some thin client manufacturers to have a Linux client. You can, however, try the open source Linux client. While this is in beta, it can allow you to take older systems, slap on a lighter Linux or perhaps create a Linux ISO and install the rpm or debian install files.

VMware View Linux Client

But the main client platform of choice remains thin clients. The reasons are varied but some include less physical desk footprint, better control (most thin clients do not have CDs, extra USB ports, etc.) and, the main reason, is less power usage. Check out Wyse’s video demonstration below of a comparison between a physical desktop and a Wyse terminal as far as power usage is concerned.

Wyse Thin Client vs PC

One company I spoke to said they’d save about 65% in power savings each month! In a day and age where saving money and looking green are important, these can help the bottom line. As the demo shows thin clients use about a tenth of the power and since desktops are where the majority of power is being consumed this is a major win for a company. You can also add ease of support to this. If a physical component fails, given the pricing of the thin clients, it’s easier to have a closet or small room with extra monitors, connectors, etc. available for users to grab.

I guess this will mean my friend will have to get heaters for all the employees.

Author Bio: Linus Bourque is a Technical Trainer with VMware and specifically specializes in educating customers on how to use VMware View. He previously was a professor at Seneca College in Toronto, Canada and taught students how to “audit” corporate environments security by “compromising” their security.

Yesterday afternoon I was out with few friends enjoying a nice sunny day away from my computers. After having a few beers at a great pub, my mind was far away from work and I began to live in real life again.  My eyes began to readjust and their veiny red lines began to recede.  The carpel tunnel of my hands began to wear off. A fresh blush of color began to bleed into my cheeks.  In short,  I no longer looked like I was a vampire waiting to strike.  All was well… that was, until THEY walked in to the pub looking for a fight.

The four douche bags sat next to us and they began saying things that really got to me.  No, they weren’t talking smack about my Yankees.  No, they weren’t bantering under their breath about my hot girlfriend.  They were talking about security Hyper-V and VMware… and they wore their lack of knowledge on their sleeves (which, I might add led up to some seriously popped collars).

At first I thought my friend was trying to punk me. I looked around for cameras or Ashton – No sign of either. So, these dudes started talking about deploying some solution and how they have to provide the highest level of security and all this nonsense. I remained quiet and managed to mind my own business as they had their chat until the topic hit VMware. My blood began to boil when one of them (the Security Know-It-All Dude – or just The Dude, as I like to call him) started to talk about VMware security flaws. The Dude even mentioned something about a vulnerability with VMotion and how it’s not very secure and all that crap. As the Dude (the main douche bag) mentioned this, I could see myself teaching my next class with a missing tooth, bloodied lip, and black eye a-la Fight Club.  Believe me, the Dude would look much worse.  I fought my instincts not to get into their discussion (or jump out of my barstool), but I was two Guinness down and incapable of staying quiet about what was going on. So, I jumped in on the conversation in order to school these douche bags about VMware and true security. No fisticuffs. I would just run good old fashion geek circles around the Dude and his pals.  What I told him was the truth:

VMware has made a great deal of changes in the architecture of their platform in a load of different areas. Those advancements have been happening since the Virtual Infrastructure 3 and even more so with vSphere 4. I want to take this moment and inform everyone that follows Punching Clouds about a few major security changes that I informed the douche bags about in regards to the re-architecture of the new ESX/ESXi 4.0:

• The Service Console is now based on the 64-bit version of the Linux 2.6 kernel.
• The VMkernel now runs and owns the device drivers
• The Service Console (what Microsoft calls Parent Partition or Management Operating System for Hyper-V in the Windows Server 2008 version) is enhanced with Address Space Layout Randomization (ASLR), a method which is used to load software in memory in a way that attackers can’t really predict where the software is going to be store in memory when they try to hijack it with attacks.
• Support for Trusted Platform Module (TPM) chips as another way to control the authenticity of drivers signatures. and to make it even better, they’ve removed
• All development environments and libraries like GCC, and anything that can be used to compile code and run it against it has been removed.

The Security Super Douche tried to counter with something about about footprint size and all, and I asked him if he’d been living under a rock because he seemed to have missed the news about ESXi. To address his tirade on VMotion and its security vulnerability, I pointed out that any security issues were resolved and in any case, the VMotion network should always be isolated whenever possible as VMware recommends.  I combined that left punch with a quick right, when I told him about how you can now encrypt the VMotion traffic for added security (The actual configuration is shown in the screenshot below. vCenter Server 4.0 provides the interface where you can configure that)

Then I knocked his ass out by firing out some info about vShield Zones, VMsafe and all the good stuff that quelled their security concerns real quick.  So, they bowed down to me. Fatality. They turned tail and quickly realized the superior nature of VMware security.  Ok, ok – it didn’t turn out quite like that.  But I did get two rounds of beers out of those dudes, which to me was a sign that they had started to believe that VMware security was no joke… or at least they had started to see that if they messed with its players, they were messing with the wrong team.

I returned to my barstool. The beer tasted a little sweeter.  The sun felt a little warmer.  Life was good.

To all you nonbelievers and naysayers, as my boy The notorious B.I.G said: So if you don’t know, now you know!

Now that VMware vSphere 4 has been officially announced, it’s time to start talking about the new solutions that it will bring to the table.  One solution that integrates with vSphere 4 is a handy little gem called VMware Data Recovery.  The solution is designed for small to medium businesses, and can be used to backup virtual machines that are managed via ESX Servers or vCenter Servers. It’s compatible with vSphere 4 virtualization features like HA, DRS, VMotion, Storage VMotion, so regardless of where the virtual machines are migrated to, VMware Data Recovery will be able to locate them and back them up.

The Data Recovery solution comes in the form of a VMware Virtual Appliance (.OVF format). The appliance is securely managed with a vSphere Client plug-in that provides the interface to configure the backup and restore jobs. The solution allows for the creation of the following job properties:

• Virtual Machines to Backup
• Backup Destinations
• Backup Job Window
• Retention Policies

The VMware Data Recovery is an Agent-less disk based backup and recovery solution that can perform virtual machine or file level restores of Windows or Linux guess OS’s. It performs incremental backups plus data de-duplication and compression to save disk space. Data Recovery supports any disks that are accessible by the Data Recovery appliance. The disks could be in a VMFS volume or on shared disks such as NFS, DAS, iSCSI, Fiber, SMB\CIFS Shares.

All of this makes the solution very appealing for small to medium businesses, since they can now use cheaper storage solutions for the backup of virtual machines. Affordable NAS devices like, DroboPro, Thecus 7700N, etc, can be used for reliable backup devices. This product is not compatible with ESX/ESXi 3.x or vCenter 2.5 and older.

Unlike VMware Consolidated Backup, which was a CLI  or modular driven solution, this new solution is completely wizard driven, which makes it very easy to manage. Take a look at the demonstration below, and see how elegantly this solution works. You can also visit VMware’s Data Recovery page for more detailed information on this new solution.

This is just one of the many gifts that vSphere 4 undoubtedly has to offer.  It looks like Santa has come early – over the next few months we’re going to have a lot of unwrapping to do.

VMware Data Recovery