Archive for July, 2009

I’m sure anyone who ends up at my tiny little blog, will already be familliar with the brilliant virtualgeek virtualization blog by Chad Sakac.

Even though you may have already seen this I thought it was still worth a mention, this kind of integration with VMware is a perfect example of why I think EMC arrays are used more than any other vendor in the market.

 

One thing about the ISCSI initiator in 3.x was even with 2x adapters bound to the vSwitch, the iSCSI adapter would only ever show a single path to the lun, and the only time it would use the secondary adapter is if the primary one failed.

Now something I noticed in the new vSphere iSCSI SAN configuration guide was now we are able to bind 2 network adapters via a single vSwitch with two port groups, or bind 2 x vSwitches with a single adapter and port group each to the built in software iSCSI initiator.

I started up my vSphere lab system and took some screenshots and thought id share a few of the key steps. Ill be honest I’m not great at sitting down and following documents step by step so of course I got an error which ill also explain and show what  was doing wrong.

Step 1.

So here you ll see Ive started off with only vSwitch0 with the service console attached.

single VMKern

Step 2.

Next I goto Add Networking and choose to add VMKernel and then add vmnic1 and vmnic2 to the new vSwitch.

two VMKern

 

Step3.

Now that I have both adapters bound to vSwitch1 I need to go and make a small change and set the secondry adapter for each port group as “unused”. If you dont do this then later on in the section where we add both port groups to the iSCSI Initiator you ll get the following error “Add Nic Failed in IMA”

The next step is for me to select the first port group which I called iSCSI_VMKernel1 and then select the NIC TEAMING tab. Then Select the override option and move the secondary adapter to unused, note for the next port group it will be the other way around.

overide_1

 

Step4.

So now Im going to go and change this for iSCSI_VMkernel2. Note this time its vmnic1 that is set to unused.

overide2

 

Step.5

So that’s the configuration of the vSwitch and port groups done. Now lets bind both vmk0 and vmk1 to the iSCSI Initiator using esxcli.

esxcli swiscsi nic add -n vmk0 -d vmhba33

esxcli swiscsi nic add -n vmk1 -d vmhba33

esxcli_add

 

 Step6.

Now I want to confirm that everything worked as expected.

esxcli swiscsi nic list -d vmhba33

esxcli_list

Yep thats all looking good.

Step7.

Now lets connect my vSphere server to the iSCSI Target.

iscsi_add

 

Step8.

Now  lets take a look after selecting YES to a rescan.

Great now we have two paths to the lun.

Now how much better is that then ESX 3.x, Oh and dont forget to go and change the path policy to “Round Robin” which makes both path active.

2paths

vSphere Datastore naming

Posted: July 16, 2009 in Tips and Tricks, VMware

Something Ive noticed each time Ive installed vSphere now is the naming convention for the local VMFS partition created at the time of install has gone back to just storage1 apposed to <servername>:storage1

I remember back in 3.0.x days it was like this and I believe the change come around 3.5 where the server name was used as a prefix.  When you’ve got multiple Putty sessions or browsing all the datastors with the VC client, it makes life much easier when the local VMFS storage can be easily identified by server name.

I need to go through the admin guide to see if I can find a reference to shy this was changed, but until then I recommend changing the local VMFS datastore name during install.

Here is an example of the datastore name from the default install

datastore_default

 

 

 

 

 

 

 

 

And here an example of the datastore name after renaming during install or aterwards in VC

datastore_after

I blogged a short time ago about VMware’s virtual appliance “vCenter Mobile Access”, below are some of the points explaining what it lets you do from the comfort of your very own phone.

  • Search for virtual machines in your data center
  • Migrate virtual machines from one host to another using vMotion
  • Execute recovery plans using VMware Site Recovery Manager
  • Access Scheduled Tasks, Alarms and Events
  • And much more…

I recently got a Blackberry storm which was reason enough for me to spend an hour getting the new virtual appliance up and running.

I thought id post a couple of screen shots showing it in action.

You can see here the main page requests the name of the Virtual Center server, Username and Password.

vcma

The next image shows the options available once logged in.

vcma2

Ive played around doing searches and vMotions of virtual machines from my phone and I must say its very cool.

For security reasons I would probably not recommend making the virtual appliance web page available externally, but with BES (Blackberry Enterprise Server) you don’t need to bother. The key here is that VCMA is web based, so almost any portable device/phone could be used.

Storage from the old days

Posted: July 11, 2009 in Uncategorized

I was going through an old box of computer parts I had laying around the other day and come across this BEAST.

seagate2

A closer look I hear you say ?

seagate

Yip that’s right 1275 MB’s of storage. Now the funny thing was I pulled this out of a PC before I sold it because I couldn’t afford to buy another HDD of this capacity. Actually thinking back on it, this HDD was in my DX4 100 which had 24MB of memory (and that was considered extreme in those days). The drive I had before this one was 500MB, all my friends I remember asking at the time “Why did you buy such a massive drive”.

Actually im tempted to plug it in and see if i cant get it working, it would be really interesting to see what data I actually had on here.

How times have changed, As I write this post on my laptop which has 300 x more capacity on the HDD and roughly 160 x more memory.

If you look a couple of posts back you ll see that Ive been doing some hardening of the ESX service console, this week I thought id post about some of the changes Ive made to A. To my production virtual machines already built, and B. To the templates to ensure any machines deployed from these templates will automatically have the hardened options applied.

Personally I think its disappointing VMware tools is configured like this by default, I would much prefer every option be disabled out of the box and if customers want to use one of the features, then let them enable it.

Just before I get into it, I thought it would be worth mentioning you can apply these directives by pasting directly into the Virtual Machines .VMX file or by configuring the advanced options for each virtual machine  using the VC client. In both cases the virtual machine needs to be powered completely off and back on again for changes to apply.

Now If you log onto a Virtual Machine with VMware tools installed as a standard user you ll notice that you have the ability to perform any of the various functions built into VMware tools. Below I’m going to go over a few things Ive done and give a brief description of why its a good idea.

Disable Copy and Paste operations

By default VMware tools allows  copy and paste operation between the virtual machine operating system and the computer the virtual center client is running. The following changes are to prevent sensitive data from being accidentally left in the clipboard and a non privileged user from being able to paste this information from another vc session.

isolation.tools.copy.disable = “true”
isolation.tools.paste.disable = “true”

Disable Disk Shrink

Ok, now this one in the hardening guide is listed as “Avoid Denial of Service caused by Virtual Disk Operations”, so its probably one I would class as fairly important, denial of service is never a good thing.

isolation.tools.diskWiper.disable = “true”
isolation.tools.diskShrink.disable = “true

I did want to mention here though that while most people I suspect will never miss this feature, I do actually use this every now and then on our file servers and here’s why. If you have a Virtual Machine with a 20GB disk and the operating system is only using 3GB of the 20GB, during a VCB export of the Virtual Machine, only 3GB is exported which of course is great. Now if you were to copy 10 GB of data to the same Virtual Machine and then delete that data, then perform another VCB backup… you would find your VCB export of the same machine would now be roughly 13 GB. The reason for this is that operating systems (Both Windows and Linux for that matter) delete the pointer to the data, but the actual data remains on the disk.

Now the disk shrink option here in VMware tools goes and cleans up and after completing, any subsiquant VCB exports will now only export 3GB. Disabling isnt a biggy as its not even something you can schedule so I would then look at using one of the open source scripts out there which acheives the same result.

Disable Options to Connect/Disconnect Devices

Once again, by default any user logged onto the system has the ability to connect and disconnect the following devices. CD ROM, Floppy, NIC

isolation.device.connectable.disable = “true”
isolation.device.edit.disable = “true”

This one is really important if you have virtualized terminal services  servers in your Virtual Infrastructure, the last thing you want is any old Tom, Dick, or Harry disconnecting the Virtual Machine from the network. The fact that you can do this without being an administrator of the system is ah…. scary.

Limit Data Flow from the Virtual Machine to the Datastore

As noted in the hardening guide “Virtual  Machines can write troubleshooting information to a log file (vmware.log) stored on the VMFS file system. Now there are various ways to cause all kinds of information to flood the log file and potentially start to fill the VMFS file system, but I wont go into that here but I will show the option to disable.

log.rotateSize = “100000”
log.keepOld = “10”

The options above limit the log size to 100000 bytes and limit the number of log files to 10.

 Litmit SETINFO Messages

Now if you read through the hardening guide, you’ll come cross a section that covers informational messages, otherwise known as SETINFO messages.

Now my understanding is that currently there is no limitation on the amount of data that can be sent from VMware tools to the host, so you can imagine it wouldn’t be hard to write some code to continuously send huge amounts of data. So lets looks at how to limit this to something more acceptable as per the hardening guide.

tools.setInfo.sizeLimit = “1048576”

Now you can actually totally disable this using the following

isolation.tools.setInfo.disable = “true”

But this stops the Virtual Center client from displaying any information about the Virtual Machine, e.g. IP Address, DNS information. So for a production environment I would recommend setting a limit rather then totally disabling.

There are a few more tricks ill update this post with over the next couple of days, but until then if this is something you’ve found use full then I would recommend taking a look at the VMware hardening guide here.