Archive for the ‘ESX’ Category

OK. I admit it the ONLY reason for this blogpost title is get you to pay attention. I don’t really mean that at all. But now I’ve suckered you into reading this thing let me explain. I’ve written an article for TechTarget which is all about my take on VMware’s recent alliance with Novell. In case you don’t know – the top-level on this is that VMware has decide to standardize (now there’s a good idea) all its virtual appliances on Novel’s SUSE Linux. I think this a good step, as any standardization is a good thing in my book. It does raise the thorny question of where this leaves us with the whole JEOS concept – and that’s one of themes of my missive.

Read on McDuff

Inspired by an exchange between two bloggers – Scott Lowe (EMC) & Steve Chambers (Cisco) – I’ve stepped in to weigh in the balance – the desire for greater consolidation ratios against the dangers of putting too many eggs in one basket. Every generation seems to demand a new panacea – virtualization; the cloud – while the same old problems caused by what I call “stupid IT” persist.

The article is in two parts on the techtarget website:

How to simplify your IT and stop being stupid

Virtualisation is not a panacea and neither is the cloud

I’ve wrote this wee like article for TechTarget about the vMA – the VMware Management Assistant. Now, I’m a big fan of PowerCLI and PowerShell generally. But when it comes letting going of the Service Console and the ye olde esxcfg-commands its a bit of leap. That’s where I think the vMA will come into its own – you can carry on using those very same ESXCFG command you know (and love?) but just carry out them remotely. In the article I document how you setup the “Fast Pass” configuration which reduces the authentication required to get focus on the ESX host – to the point that you can run commands on a ESXi host as if it was ESX “Classic”. I challenge you to spot the difference! RIP COS…

http://searchvmware.techtarget.com/tip/0,289483,sid179_gci1510368,00.html

Editors Note: This is part two of a two-part series on VMware Site Recovery Manager (SRM). If you’re just joining us, please take a minute to read part one, which goes over the basics of VMware Site Recovery Manager and what resignaturing is.

In normal day-to-day operations an ESX host in the protected site should not get to see both the original LUN and replicated LUN/snapshot at the same time. If it did, ESX would suppress the second LUN/volume. If an ESX host was allowed to see both LUNs/volumes at the same time, ESX would be very confused and not at all happy. It wouldn’t know which LUN/volume to send its reads and writes to. In ESX 3.5, the host would print a hard console error message, suggesting you may need to do a resignature of the VMFS volume.

Read on…

Many people think the key to the virtual data centre is about getting as many virtual machines (VMs) on a physical server as possible. It is still the case, however, that prohibitive memory costs are a roadblock to high consolidation ratios, and virtualisation availability tools still lag behind business need. They have not yet cancelled out the “eggs-in-one-basket” scenario that virtualisation endemically brings with it.

Read more…

In this article, we eschew the normal blue-sky 2010 technology predictions for something a bit more everyday that will affect your daily virtual life.

Scale up, up, up and away
Firstly, it’s no surprise that by mid-year there is likely to be a major rerelease of vSphere4 with a strong emphasis on increased scalability. Building on top of vSphere4′s current scalability I wouldn’t be surprised to see the number of vCPUs a single ESX host can support go beyond the 128 core range. I think it’s likely that by the end of 2010 or the beginning of 2011 we will be looking at more than 8 vCPUs to a VM – with VMware pushing the amount of RAM per-VM into the 512 GB to 1 TB range and the ESX host supporting 1 TB or 2 TB of physical RAM.

Read on…

In case you don’t know Scott is a VMware employee – he focuses on performance and scalability – and taking on Citrix/Microsoft at the how-got-the-best-product game…

Anyway, Scott’s a good resource for information (in fact some of it quite technical, but written in an accessible way) on performance.

Performance of Thin Provisioned Disks

This article debunks the popularly held myth that thin provisioning = poor performance. It doesn’t, so long as the underlying storage and VMFS is configured correctly. Actually, the performance is comparable to the old thick format. Don’t about you – but I’d rather be thin, than thick any day.

Additionally, my pal and fellow blogger – Steve Beaver has some interesting (and some would say more guarded) thoughts on thin-provisioning.

http://www.thevirtualblackhole.com/vwire/some-thoughts-on-thin-provisioning

esxtop Analysis With esxplot

This one allows you to download a graphing tool that take the raw date from an esxtop -b output – and doesn’t suffer from the column and row limitations of conventional systems – such as Microsoft Excel

Following from my popular (according to me!) blog post theme – of “what I learned this week…” a irregular round-up of stuff that seems really obivious – but actually has escaped me.

vCenter DB Retention Policy:

A couple of weeks ago I made a point about how the vCenter DB grows in size day-by-day and week-by-week – and that wasn’t away to control it size or FIFO its data. I turned out I was wrong. If you look in the vCenter Server Settings. In vCenter 4.0 there is actually something called the retention policy.

What I was hoping for was the ability to FIFO the performance data. As far as I know the only way to clear performance data is with SQL Transact commands to delete the redundant data.

VMware Tools won’t upgrade:

I’ve a couple of VMs who’s VMware Tools won’t upgrade. I think it maybe because the uninstall data was deleted – erm, by me. Opps. Anyway, I think I might have found a work around in this KB article.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001354

ESXi lacks RPMs for VMware Tools for Redhat Linux 64-bit:

This is little bit of an obscure one – and it was drawn to my attention by one of my students. If you create a Red Hat Linux 64-bit (RHEL5) on an ESX ‘Classic’ host you will find you have both the ability to install VMware Tools with either an .RPM or extract it from a .TGZ file. NOW, if you try the SAME thing on ESXi host you will find the RPM version isn’t there. Presumably this is done by VMware to reduce the footprint of ESXi.

Find out if your virtual disks are the right type for VMware Fault Tolerance:

This one came thru twitter. Specifically from William Lam. Thanks William this is great find. William has a great resource of scripts on his website:

http://www.engr.ucsb.edu/~duonglt/vmware/

My previous method of finding this out was pretty lame. It involved using vmkfstools and vmkernel log files – and looking at very obscure values therein. This is MUCH easier; MUCH clearer, and MUCH simpler.

Why is this important. Well, let say your VM has the ordinary thick type of disk (technical term is zeroedthick) or you have used the thin type – AND these disks are quite large (let say 2TB). To convert these disks the Fault Tolerance format (eagerzeroedthick format) requires a power off of the VM, and it can take a long time. That’s got to be factored into your maintenance window.

Of course none of this matter if the vSphere Client/vCenter actually showed the correct format. Unfortunately, both the zeroedthick and eagerzeroedthick format are both referred to as “thick” in the GUI.

Here’s how you do it.

Just cat & grep the last vmware.log file of the VM which you can see in the directory where the VM is located. So here’s a VM with three types of disk. Thin (scsi0:0), EagerZeroedthick (scsi0:1) and Thick (scsi0:2). In the screen grab you can see scsi(0:0) is thin

If you then PuTTy to a ESX host, and the type the following command:

[root@esx1 mail03]# cat vmware-1.log  | grep  ‘FT enable’

This will produce the output of:

Dec 02 00:38:08.505: vmx| VM has thin disk scsi0:0; FT enable will be disallowed
Dec 02 00:38:08.507: vmx| VM has zeroedthick disk scsi0:2; FT enable will be disallowed

Alternatively, if you use

[root@esx1 mail03]# cat vmware-1.log  | grep  ‘scsi0:0′

[root@esx1 mail03]# cat vmware-1.log  | grep  ‘scsi0:1′

[root@esx1 mail03]# cat vmware-1.log  | grep  ‘scsi0:2′

This will print out much detailed information. The difference between each output is the “allocation type” field. These are are as follows:

allocation type: 0 – EagerZeroedthick Virtual Disk

allocation type: 1 – Zeroedthick Disk (Default)

allocation type: 2 – Thin Virtual Disk

I was actually in the process of writing an article about my upgrade. Fortunately, I caught wind of this upgrade bug before hand. I’ve decided its too important to wait for the completion of the article. The people in the US are lucky they are on holiday – and so might be with their families rather than in datacenter doing upgrades – that said holiday times are ideal for upgrades…

http://kb.vmware.com/kb/1016070

This week I was asked in an email the following question:

[By the way I hate WordPress - even when I put paragraph returns in this post it ****ing well removes them!]

Hope you been doing well. I have been busy, busy, busy.

Got a question for you. Preparing to start a new vSphere farm and trying to decide do I use stand switches or start with the DVS. Especially when I see this: http://www.ntpro.nl/blog/archives/1283-vSphere-DvSwitch-caveats-and-best-practices!.html So the main question is do we think this is mature enough to go forward with yet? Can I use Host profiles with DVS safely?

Just appreciate your thoughts.

Apologises for my tardiness in getting back to you. Snowed under. You get the picture. So I’ve written you this lovely long email to make up for that. Gee, this could be blog post! [How ironic - it did become a blogpost!]

A couple of things come to mind. Firstly, Eric’s blog post – I do respect Eric’s blog (and others). Things have gotten so big in VMware – that it would impossible to know of all the known/unknown issues – after all no man is an island, and no-one ever see’s all the possible configurations and screw-ups….

BUT. (you could tell that was coming). Untimely, ripping an ESX host out of vCenter (right-click disconnect/right-click remove). Isn’t the recognised procedure. Yes, I know tardy/slapdash admins might have done this in vCenter1/2 but isn’t something that’s recommended or recognised as the right way. It should always be regarded as the LAST resort.

So if people first removed ESX from the DVS, before removing the ESX host this problem would NOT happen. Basically, what Eric is saying is if you don’t step A followed by Step B followed by Step C then problems can occur. But problems will always occur if you not aware of relationships.

So Eric post would not put me off using DVS for Service Console/Management Network traffic or vmkernel traffic for that matter. I think there’s tendency when people read blog post about new technology that we focus on the bad news, rather than the good. Also people forget (rather conveniently) about what was awful about the previous technology (in this case Standard vSwitches) which they moaned and complained about before the advent of the new. So there’s tendency to re-write the past as some golden period before all this new stuff came about….

I’ve used host profiles with DvS without a problem. For me the bigger question is not whether they can be “depended on” or “safely” used in production- but the reality of what they are like to use on daily basis…. Do they make your admin/configuration any easier. Whilst I love DvSwitches, I’m not at all armoured of Host Profiles. Neither are helped by being shackled to the most expensive SKU of vSphere you can buy!

I like DvS… I especially like them for virtual machine networking. But I see them as being less useful for Management and Vmkernel Ports (not bad, just less useful) because you still have to configure the IP configuration of the ESX host.

Of course, VMware’s answer to that would be to use host profiles. For me – I look at the different ways I might get that IP configuration on to the ESX host. I know the more I manually have to do stuff, the more errors I’m likely to make thru fat-finger-syndrome. Also, If I have to hand the build process to someone less experienced I want to automate as much possible to prevent accidental errors…. This is also tempered by what type of ESX the customer is using. If they using ESXi it rules out kickstart %post scripting and using my UDA appliance…

So lets say I’m doing bulk admin. Building 100′s of ESX hosts, do I really want to sit there apply the host profile to each and every host. As I applied the host profile to N host, it would stall as it asked for my management, VMotion, iSCSI, FT logging, HA Address IP addresses. If you think about the number of IP’s you need for an ESX box (if you follow to the recommendations to letter you end up with quite a lot). Five IP addresses (and their associated subnet masks!)

So when I think of bulk admin & host profiles –  I don’t think they add up. Have I ever created an IP conflict by applying the host profile to many ESX hosts? Yes, an I only have 4 bloody ESX hosts!

I have PowerCLI scripts which automates EVERYTHING I would want to do (and more) than Host Profiles are current capable off. It did take some time to learn PowerCLI and test my scripts. But time is something I have plenty of when I’m not teaching. I wouldn’t say I was the most gifted of scripters – but I don’t care as long as it works, and works reliably.

My PowerCLI script will add a host into vCenter and completely configure it – include things that host profiles cannot do… such as iSCSI and DPM settings. The other thing I don’t like about host profiles – is the fact the host has to be maintenance mode to apply them.   So they can’t really be used as a reconfiguration tool – because who wants to move 20-30 VMs just to add a port group – when something like PowerCLI could do that infinitely quicker with just a couple of lines of script. That more or less relegates the host profiles to being a “consistency” check too – like ConfigControl without the licensing (another product that should be included in the core vSphere4 product!!!).

What’s irritating about host profiles – is that I think if you did have 100′s of ESX hosts you would want something that was more automated than host profiles. The smaller/medium shops won’t buy enterprise+ so they won’t benefit. When I teach VMware, it’s at this moment that I mime to my students – taking a gun from the wall – loading it up – and then firing it at my own foot. It always makes my students laugh.

Can you see what I’m doing here? I’m not arguing against DvS/Host Profiles per se. I’m looking at the technologies and what I might trying to achieve with them – and seeing if they help or hinder. Like anything it depends on the environment and the skills of the person involved. So here’s what I’m recommending in the book:

• New to Product/Admin with no time/aptitude for Scripting
  ESXi+vCenter4+DvS+Host Profiles. Essentially, drag-and-drop management strategy….
• Admin with plenty of time/aptitude for scripting/100′s of Servers
  ESXi or ESX “Classic”+vCenter+DvS+PowerCLI. I know this guy would not be disappointed with PowerCLI. They are adding another 60 cmdlet in time for vSphere4.1….
• ESX 2/3 Admin who has an existing kickstart scripted environment” –
  Don’t re-invent the wheel. Use ESX Classic+KickStart (UDA)- with a view to moving over to PowerCLI, ready for the demise of the COS in vSphere5 (circa 1012?).

  R.I.P. COS

I don’t know what category you fall into. You see host profiles could benefit everyone – the more ESX hosts – the more benefits they are. But then you have to buy this damn + product to get them. It’s just madness.

As for DvS. You could take a hybrid attitude on that. This appears to be the consensus view at the moment. That you use Standard vSwitches for management & vmkernel – and leave DvS just for VMs. This seems to be because Standard vSwitches are more of a “known quantity” than DvSwitches. I had hoped that host profiles would see of end of scripting and scripted installation, but nothing seems offer the same flexibility of things like the EDA/UDA and PowerCLI…. If you really mad about scripting then PowerCLI is the way to go. Hence my recent move away from “Classic” to ESX4i, and using PowerCLI.

And Finally…. I’ve been using DvSwitches for everything since the beta. I’m firm believer in using new technology in lab environments like my own – the more exposure you get to technology the more comfortable/confident you become with it. Plus it gives you the edge on folks who might be more production/conservatively minded. I’ve had no problems until I make an admin error. Like the day I removed vmnic0 from DvSwitch0. But hey, I could have done that with Standard vSwitches as well.

I now know how to fix both it they get broken, and that does impress my students.