10.06.09
SRM 4 Finally Released
Yes, much to my surprise today SRM 4 is now available from the VMware download site.
I was at a customers site this morning when an email from VMware come through on my BlackBerry announcing SRM 4 had been released, After racing home at the end of the day I logged in and started to download the new SRM 4 package and Celerra Storage Replication Adapter. Look at that pitiful download speed, it was like watching paint dry.
I havent had a chance to read over the release notes properly yet, but here’s whats new. Keep posted as ill be posting more about SRM 4 over the next few days.
Also if your interested in the documentation, here are the links to the Admin Guide and Compatibility Guide
New in This Release
- Full compatibility with vCenter 4.
- Full support for NFS-based arrays.
- Support for shared recovery sites.
Enables many-to-one pairings of protected sites with a recovery site. For more information, see the technical note Installing, Configuring, and Using Shared Recovery Site Support, which is available at http://www.vmware.com/support/pubs/srm_pubs.html. - Resilience in the face of vCenter unavailability during a test recovery.
Placeholder virtual machines can be quickly repaired after the protected site vCenter becomes available again. - New repair-mode installation features.
You can run the SRM installer in repair mode if you need to change configuration parameters such as vCenter credentials, database connection information or credentials, and certificate details. - Graphical interface to advanced settings.
Eliminates most requirements to edit the XML configuration file - Support for DB2 as an SRM database server.
- New licensing options.
- Improved scalability.
A single protection group can now include up to 1000 virtual machines. - Full Compatibility With DPM (Distributed Power Management)
SRM recovery plans can now power-on or power-off a host that is in standby mode. - New Option to dr-ip-customizer Utility
The dr-ip-customizer utility now logs less verbose diagnostic output by default. To force dr-ip-customizer to log the same level of diagnostic output that it produced in earlier releases, use the -verbose option. - Change in Certificate Validation
When you select certificate authentication, the SRM installation validates the certificate you supply before continuing. Certificates signed with an MD5 key are no longer allowed. - Support for Protecting Fault-Tolerant Virtual Machines.
SRM can now protect virtual machines that have been configured for fault-tolerant operation. When recovered, these virtual machines lose their fault tolerance, and must be manually reconfigured after recovery to restore fault tolerance. - Improved context-sensitive Help.
- PDF documents available on release media
Current versions of the PDF documents for this release are available in the docsfolder at the root of the SRM 4.0 CD. Updated versions of these documents may be available at http://www.vmware.com/support/pubs/srm_pubs.html.
09.26.09
EMC Replication Manager With vSphere 4 and LVM.EnableResignature
Ive had Replication Manager 5.2 integrated with VMware VI3, hanging off an EMC Celerra using iSCSI for some time now, and ever since vSphere was released Ive been meaning to test the functionality to make sure everything works and to see if there are any changes.
Now having set this up with 3.5 update 4 hosts I remembered one of the key steps is changing the advanced LVM.EnableResignature option to 1 which allows a snapshot of an existing lun with a matching header to automatically re signature and be presented back to the host. If you want to read more about how this works then Chad Sakac has a really good post about this here.
Here is a screenshot showing this on a ESX 3.5 host.
The next step was to build my self a vSphere 4 host and integrate it into my existing lab setup, after building the host and searching through the advanced options I realised the LVM.EnableResignature option was not available and after a quick google it didnt take long to find this post by Duncan at Yellow-Bricks.
After configuring the host in Replication Manager I performed a Mount of an existing snapshot to my vSphere1 host, the task completed successfully but I was unable to see the lun on the host.
The image below shows the snapshot has been succesfully mounted to the host.
You can see only the default datastore on local disk and the original Celerra Lun is shown.
Next I went to Configuration >> Storage >> Add Storage >> Disk/Lun and there it was.
After selecting the lun and clicking next, I was now presented with three options as shown in the screenshot below.
As Duncan pointed out in his post, yes this can be done through the GUI but its more fun from the command line, im also a firm believer of learning to do tasks from both the command line and the GUI.
So with that said im now going to use vicfg-volume to resignature the lun.
First lets check the existing header ID using vicfg-volume.pl – -server vsphere1 -l
Now lets resignature the lun using vicfg-volume.pl – -server -r <existing_header>
Next I check to see if the lun is now visible, and there it is.
Just as a last note to this post I just wanted to mention Ive not yet found anything in the release notes to confirm vSphere is supported with Replication Manager 5.2.2, so at the moment this is nothing more than an informational post. Ill make sure to update this as soon as Ive confirmed this is in fact supported.
Oh and just incase you’re wondering why this change has come about…. With VI3 and LVM.EnableResignature it was an all or nothing setting, now with vSphere 4 you can change this on a per Lun basis, actually a good thing once you know about it.
If you’re a VMware shop you have to check out some of the demos online, Replication Manager is a Brilliant product !
09.21.09
Celerra iSCSI Targets visible to all Initiators
Something I noticed last week while working on a customers site was multiple iSCSI initiators logged into iSCSI targets which I had not granted access.
I’ll fire up my lab to demonstrate what I saw and how to change the behavior.
Here on my Celerra simulator I have three iSCSI Targets configured for VMware, Exchange and SQL. Each Target uses a different interface with its own IP address.
Im going to use my Exchange Virtual Machine to demonstrate, but before I flick to the VM, I want to show the mask for the VMware and SQL iSCSI targets.
VMware -Only the vSphere initiator masked here.
SQL - Only the SQL initiator masked here.
Now lets flick to the properties of the Microsoft iSCSI initiator in my Exchange VM. You can see Ive only configured the IP address assigned to the Exchange iSCSI target.
Now lets take a look to see what targets are visible.
And here you can see the iSCSI initiator is able to see all three targets. The reason for this is because by default the Celerra returns information on all targets to all initiators regardless of the lun mask.
Although the systems can only access the luns the mask permits, it’s still quite messy when you have 5, 10, 15 targets on the Celerra which are visible to all Microsoft initiators. So luckily the guys who write the code have a parameter for us to change which alters the default behavior.
First lets confirm the current setting.
[nasadmin@csprod ~]$ server_param server_2 -f iscsi -i SendTargetsMode
server_2 :
name = SendTargetsMode
facility_name = iscsi
default_value = 0
current_value = 0
configured_value =
user_action = none
change_effective = immediate
range = (0,1)
description = Enables return of information about inaccessible targets
Now lets change the current value to 1
[nasadmin@csprod ~]$ server_param server_2 -facility pre=”-facility “>iscsi -modify SendTargetsMode -value 1
server_2 : done
And now confirm the current vaule = 1
[nasadmin@csprod ~]$server_param server_2 -f iscsi -i SendTargetsMode
server_2 :
name = SendTargetsMode
facility_name = iscsi
default_value = 0
current_value = 1
configured_value = 1
user_action = none
change_effective = immediate
range = (0,1)
description = Enables return of information about inaccessible targets
So what Ive done here is configured the Celerra to only return information on iSCSI targets when luns have been masked to the client initiator.
Restarting the iSCSI service on the Celerra causes the initiators to drop the targets to which it has no luns maksed (Actually do this with caution as it causes all iSCSI connections to drop)
Lets take a look at my Exchange VM after this has been done.
Much Better ! If you dont use the Microsoft iSCSI initiator than this is not really going to bother you, VMware’s software initiator only shows targets when connected to luns.
In my honest opinion this should be the default setting.
08.12.09
Getting EMC NetWorker VCB exports to stay on disk
If you’ve been using EMC NetWorker to perfrom VCB exports then you’ll know that after the VCB export has been backed up from the holding tank to Disk or Tape, it is then removed from the VCB holding tank.
I had a request from a customer this week “We want to be able to use NetWorker to perform VCB exports but configure it to leave the export on disk so we can then replicate to our DR site”
No problem I said, Ill go and configure that in the config.js file…. <looks>……<looks more>……. hmmm well I have options to remove existing snapshots from snapshot manager, I have an option to delete the mount point if it already exists, and I have an option to leave the snapshot in snapshot manager after the backup but oh no, no option to leave the export in the holding tank.
After thinking about this for a while I figured that the deletion of the export was actually done by the Networker VCB interoperability module.
After reading down through the code, right at the end I found the clean up section as shown in the screenshot below.
The next thing I did was comment out all the lines after “Clean things up” but making sure to leave “return result” and then saved the file.
I started the VCB group, the virtual machine exported out to the holding tank, NetWorker saved the export to the Disk Device, the group completed successfully and the export was left in the holding tank as I wanted.
I’m still in the process of testing this to make sure it does not have any adverse effects, but from what I can see at the moment its all good. If you change this you will need to make sure you change the option in the config.js file to delete existing mount points other wise you will have failures.
Also if you upgrade the NetWorker interoperability module, its likley you will need to apply this change again.
Hope this helps.
08.11.09
How to enable sparseTWS Snapshots for Celerra
My last post hopefully shed a little light on file system requirements for iSCSI luns on the EMC Celerra when replication or snapshots will be used. If you missed this and you think it might be of interest you can read it here.
First lets verify what the current value for sparseTWS is set to
[nasadmin@EMCNAS ~]$ server_param server_2 -f nbs -i sparseTws
server_2 :
name = sparseTws
facility_name = nbs
default_value = 0
current_value = 0
configured_value =
user_action = none
change_effective = immediate
range = (0,1)
description = Enables sparse TWS support
[nasadmin@EMCNAS~]$ server_param server_2 -f nbs -m sparseTws -v 1
server_2 : done
You can see the default and current value are both set to zero which means this feature is currently not in use.
Now lets enable support for spareTWS
[nasadmin@EMCNAS~]$ server_param server_2 -f nbs -i sparseTws
server_2 :
name = sparseTws
facility_name = nbs
default_value = 0
current_value = 1
configured_value = 1
user_action = none
change_effective = immediate
range = (0,1)
description = Enables sparse TWS support
[nasadmin@EMCNAS ~]$
Also to verify this has been enabled correctly you can also browse using Celerra Manager to the Data Mover parameters tab, if correctly enabled you should see an entry called sparseTWS with a vaule of 1.
What uses Tempoary Writable Snapshots ?
SRM is a good example, every time you hit that “TEST” button SRM via the SRA (Storage Replication Adapter) is creating a Temporary Writable Snapshot of the replicated lun and presenting it to the ESX host configured at the recovery site.
Replication Manager is another good example of an application that takes advantage of the Celerra Temporary writable snapshots. Ive configured our Replication Manager server to snapshot our production VMware iSCSI luns which I then present to another ESX host which we refer to as the mount host. Once Ive done testing or backing up the data I cant then un mount and remove the TWS.
By configuring the sparseTWS option with fully provisioned luns, we reduce the file system needed by the size of the published lun.
Celerra iSCSI Luns and File System Sizing
Ive deployed a number of Celerra’s into customer sites over the last year and although the feature packed Celerra can present storage using CIFS and NFS, the majority of systems have been deployed using iSCSI for VMware environments.
Now if your not planning to replicate or snapshot your iSCSI luns, then these considerations do not apply, the additional file system space needed is only a fraction of the lun size to store meta data.
If your familiar with the Celerra then you’ll know that each iSCSI lun sits inside a Celerra file system, While it is possible to have multiple iSCSI luns inside a single file system, its not a good idea especially if you plan to snapshot your iSCSI luns. So with that said, the actual sizing considerations are actually around the size of the Celerra file system which will be used to store A. The Lun B. The Snapshots and C.The temporary writable snapshots.
The size of the file system needed to host each iSCSI lun really depends on how you choose to deploy your iSCSI luns, lets look at each of these options and begin by defining a general equation.
File System minimum = Size of Lun + Snapshots + Size of TWS (Temporary Writable Snapshot)
Here is a table showing the variables we will use later on during the sizing examples.
Fully Provisioned iSCSI Lun with Fully Provisioned TWS
Celerra allocates enough space for a 100 percent data change (A) during the initial snapshot as a precaution. When the next snapshot is created, additional space is allocated equivalent to the amount of changed data since the first snapshot.
The host then writes and additional 2GB of data which now brings the total to 12GB.
The Snapshot is then promoted and presented to another host, the host writes an additional 2GB of data in the space allocated for the TWS. Once the host is finished with the snapshot the TWS is then unmounted and removed. As shown in the image the total file system space needed was 22GB.
The following equation can be used here;
FS min =L + [A + ((N-1)*C] + [M*L]
Fully provisioned lun with virtually provisioned TWS
Now this configuration gives us the protection of a fully provisioned lun with a virtually provisioned TWS.
Once again, Celerra allocates enough space for a 100 percent data change (A) during the initial snapshot as a precaution. When the next snapshot is created, additional space is allocated equivalent to the amount of changed data since the first snapshot.
Because the TWS is virtually provisioned we reduce the total file system needed to just 14GB
The following equation can b used here;
FS min = L +[A + ((N-1)*C] + [M*T]
Virtually provisioned lun with virtually provisioned TWS
Here Celerra takes full advantage of virtual provisioning and no longer is requires (L) published lun size and only requires (A) actual data.
The snapshot space does not require any initial allocation of (A) and the mounted snapshots require only the space for the changed data. The file system space needed to support this, just 6GB.
Here the following equation can be used;
FS min =A + [N*C] + [M*T]
If your wondering how to enable the sparseTWS support on the Celerra, check out my next post which covers this.
Also thanks to EMC’s Chris Stacey for hooking me up with the images used in this post.
Also if you have a EMC Powerlink account you can grab the sizing document from here.
07.26.09
EMC Navisphere now VMware aware
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.
07.17.09
vSphere 4.0 with Software iSCSI and 2 Paths
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.
Step 2.
Next I goto Add Networking and choose to add VMKernel and then add vmnic1 and vmnic2 to the new vSwitch.
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.
Step4.
So now Im going to go and change this for iSCSI_VMkernel2. Note this time its vmnic1 that is set to unused.
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
Step6.
Now I want to confirm that everything worked as expected.
esxcli swiscsi nic list -d vmhba33
Yep thats all looking good.
Step7.
Now lets connect my vSphere server to the iSCSI Target.
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.
07.16.09
vSphere Datastore naming
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
And here an example of the datastore name after renaming during install or aterwards in VC
07.12.09
VMware vCenter Mobile Access Up and Running
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.
The next image shows the options available once logged in.
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.
