Mike Laskowski's Blog

What is the best P2V PRODUCT?

mlaskowski11 — Tue, 03 Nov 2009 16:04:19 +0000

Over the years, I have used many different P2V tools including VMware Convertor, Plate Spin Migrate, VizionCore convertor, Ultimate-P2V, BartPE, etc… However, what if you have to P2V 5000+ servers, what if getting down time is very limited etc…. All these products are good and each has something different to offer. But I think there is one product that I think is the best “Double Take”.

DT is not a P2V tool but a DR tool, they offer a solution called VRA (virtual recovery assistant) The idea here is that you replicate a physical server to a VM as a DR strategy. The way it works it does a full server replication once it is fully replicated, it send byte level changes. You can wait a week or a month until you are ready to failover to the VM replica. The servers are always in full sync and the down time is 2-3 reboots.

It is also not cheap but if you have a lot of P2Vs to do and do not want to spend your nights and weekends waiting for servers to convert this is the way to go. Licensing is per protected server. Protected server meaning “DR” if you are going to use it for P2Vs as soonest you convert a server you free up a license and you can re use it again and again so the price can easily be justified if you have many servers to P2V. In addition, once you are done you can use those licenses to create an awesome DR strategy with many different options.

The product I am talking about is there core solution Double Take for Windows / Double Take Availability, which comes with 4-5 different option to do DR so this is just one option you can use for P2Vs. Another option for P2Vs is Full Server Recovery, which is part of the same suite.

Double take recently released a new product called Double Take Move, which is made for P2Vs. It’s basically the same thing as VRA with a different licensing model, per conversion. Depending on how many P2Vs you have and money to spend DT Move may be a better option, but the core product gives you more flexibility and more options, Plus a DR solution at the end.

THX, Mike Laskowski

My P2V notes / cheat sheet

mlaskowski11 — Tue, 03 Nov 2009 15:17:34 +0000

My P2V notes / cheat sheet

You can find tons of tips on doing P2Vs online. Below I just pasted a note with the commands I use when performing a P2V clean up.

Delete hidden Devices:

SET DEVMGR_SHOW_NONPRESENT_DEVICES=1

devmgmt.msc

IP Info export/Import:

Export: netsh -c interface dump > C:\interfaces.txt

Import: netsh -f C:\interfaces.txt

Screen Saver OFF

HKEY_USERS\.DEFAULT\Control Panel\Desktop\ScreenSaveActive

Change the ScreenSaveActive to 0

Double Take LIC Key location:

HKEY_lOCAL_MACHINE\Software\NSI Software\Double-Take\CurrentVesrion

THX, Mike Laskowski

Block sizes, VMFS, and Thin-provisioning

mlaskowski11 — Tue, 03 Nov 2009 15:04:32 +0000

I never really put much thought about the block sizes when creating new datastores in VMware. I usually went with 2MB 512GB size as my standard. The only reason I went with a bigger block size is if I knew a VM needed more than 512GB VMDK and or if my LUN size was 2TB. There is lots of info on the web about choosing the right size, I recently read an interesting blog about block sizes if using thin-provisioned disk. With ESX 4.0 and this option added to the gui thin disks are getting a lot of attention. I still feel that thin provisioning can get you into a lot of trouble and it you choose to use then it will eventually come back and bite you in the ass. I also think that they are a good idea and will become very popular among many companies. Just make sure you have a good system to manage / keep track, before you start over allocating disk and using thin provisioning. So back to the black sizes, according to what I read there is NO performance decrease if using thin disks. However, going with bigger block size is the smarter way to go.

From “Yellow Bricks”

“If you create a thin provisioned disk on a datastore with a 1MB blocksize the thin provisioned disk will grow with increments of 1MB. Hopefully you can see where I’m going. A thin provisioned disk on a datastore with an 8MB blocksize will grow in 8MB increments. Each time the thin-provisioned disk grows a SCSI reservation takes place because of meta data changes. As you can imagine an 8MB blocksize will decrease the amount of meta data changes needed, which means less SCSI reservations. Less SCSI reservations equals better performance”

Just something to think about… I’m slowly moving towards thin-provisioning and will probably start formatting my datastores using 8MB blocks.

THX, Mike Laskowski

Changing the default path policy to round robin

mlaskowski11 — Tue, 03 Nov 2009 14:05:23 +0000

I have over 150+ LUN’s in my environment. Round Robin is officially supported on ESX4. In the past we had a script that would manually load balance the LUN’s across FAs. ESX4 has a different way to balance the LUN’s to round robin. What you can do is build the ESX server and then in the CLI do:

esxcli nmp satp setdefaultpsp –psp VMW_PSP_RR –satp VMW_SATP_SYMM

Note: You should do this before presenting LUN’s and adding datastore. If you already have LUN’s presented and datastore added, then you do that command and then you’ll have to reboot the ESX server to take effect. This will make Round Robin the default on all LUN’s. It would take forever if you had to manually change each LUN.

Please note that this example is specifically for the “SYMM” SATP. SATP stands for Storage Array Type Plugin and Symm stands for EMC DMX Symmetrix. In case you are using a different array find out what the SATP is you are using and change it accordingly.

To find out the storage array type: Click on Configuration / Storage / select one of the datastores right click choose properties / Click on Manage Paths.. And on top you should see Storage Array Type:

THX, Mike Laskowski

ESX servers rescan HBAs when adding new Datastore

mlaskowski11 — Tue, 03 Nov 2009 02:07:39 +0000

Got this tip from Duncan from Yellow Bricks. If you make any changes to a datastore add/delete/extend all the ESX servers will automatically do a HBA/VMFS rescan. You can imagine that it is pointless to rescan your HBA 25 times in a row when you are adding more than 1 new datastore. Open up the vSphere Client

1. Go to Administration -> vCenter Server
2. Go to Settings -> Advanced Settings
3. If the key “config.vpxd.filter.hostRescanFilter” is not available add it and set it to false

Make sure to set it to “true” as soon as you are done!!!!
To change it back to true you will have to edit the vpxd.cfg file unless VMware fixed the bug to change the Value to true.

C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter

true

THX, Mike Laskowski