Blog Archives

vSphere 5 – Storage pt.2 vCloud and Vsphere Migrations

The point..

So on my last post I covered some things to think on when looking at the new VMFS-5 partitions. Obviously the point in moving to the new VMFS would be to gain all the benefits as explained in that previous post. One thing you will see in this post are just the types of migrations. I also want to highlight that I shared some resources on the bottom for those of you who may want to review some deeper highlights. Obviously there isn’t a ton of documentation out there highlighting this nor the special *features* for vSphere 5 (sVmotion issues??) that you may run into. So let hope I do this yet further justice. On to the blog!

Adding VMFS-5 to the vCloud

  1. Log in to vSphere and ensure you have a new LUN provisioned (covered above in how to:)
  2. Log into vCloud Director Web Interface and you must be an administrator.
  3. Click “System” tab and click on Provider VDC. Right click a PVDC and select “Open”
  4. After opening the PVDC select the Datastores Tab and then click the +/- button to add/remove datastores

  1. Browse through the datastores by clicking the > button or by searching in the top right. When you have located your datastore highlight it and then click the button then click “OK”. Disregard the warning.

(Note: the yellow highlights are ways you can search and browse through datastores. This is very handy when there are many to look through)

(Note: Highlight in yellow shows the datastore added successfully. This is a 20TB Datastore)

You will now see the datastore in the datastore summary tab for that PVDC

Migrating Virtual Machines for vCloud Director to the “new” VMFS-5 LUN.

  1. Make sure the vApp is NOT a linked clone. If it is a linked clone defer to the references below.
  2. Ensure the Datastore you want to Storage Motion the Virtual Machine to is also provisioned to the Org VDC. Do this by opening the Org vDC and selecting the “Datastores” Tab.

    Note: you can see both datastores are attached to this VDC with the organization known as App1

  3. You could then log-in to vSphere client with the following noted vCenter and perform a storage vMotion. Another way of doing a Storage vMotion could be by using William Lam’s script he wrote as well. (see references below)
  4. If you need to perform the sVmotion defer to the following method below.

NOTE: I would highly recommend that you roll out update 1 to all vCloud components. This addresses a few major fixes that will allow for operations to run more smoothly. More importantly, the only way to sVmotion vCloud VMs is to turn them off. This is a pretty common issue with vanilla vsphere 5/vcloud 1.5 roll outs. I also experienced this problem. For more information please see references at the bottom.

Migrate a Virtual Machine with Storage VMotion in vSphere

Use migration with Storage VMotion to relocate a virtual machine’s configuration file and virtual disks while the virtual machine is powered on. You cannot change the virtual machine’s execution host during a migration with Storage VMotion. (Note: that if VM is managed by vCloud and not at 1.5 update 1 you will need to possibly power off the virtual machine to perform the svmotion. If the virtual machine is a fast provisioned vm (linked clone) then you will need to perform the sVmotion through an API.


  • Ensure you are not moving vCloud vApp if you are please follow the above process first.
  • Display the virtual machine you want to migrate in the inventory.
  • Right-click on the virtual machine, and select Migrate from the pop-up menu.
  • Select Change datastore and click Next.
  • Select a resource pool (the same) and click Next.
  • Select the destination datastore:
    To move the virtual machine configuration files and virtual disks to a single destination, select the datastore and click Next.
    To select individual destinations for the configuration file and each virtual disk, click Advanced. In the Datastore column, select a destination for the configuration file and each virtual disk, and click Next.
  • Select a disk format and click Next:
  • Option Description
    Same as Source Use the format of the original virtual disk.
    If you select this option for an RDM disk in either physical or virtual
    compatibility mode, only the mapping file is migrated.
    Thin provisioned Use the thin format to save storage space. The thin virtual disk uses just as
    much storage space as it needs for its initial operations. When the virtual disk
    requires more space, it can grow in size up to its maximum allocated capacity.
    This option is not available for RDMs in physical compatibility mode. If you
    select this option for a virtual compatibility mode RDM, the RDM is
    converted to a virtual disk. RDMs converted to virtual disks cannot be
    converted back to RDMs.

    Thick Allocate a fixed amount of hard disk space to the virtual disk. The virtual
    disk in the thick format does not change its size and from the beginning
    occupies the entire datastore space provisioned to it.
    This option is not available for RDMs in physical compatibility mode. If you
    select this option for a virtual compatibility mode RDM, the RDM is
    converted to a virtual disk. RDMs converted to virtual disks cannot be
    converted back to RDMs.

    NOTE: Disks are converted from thin to thick format or thick to thin format only when they are copied from one
    datastore to another. If you choose to leave a disk in its original location, the disk format is not converted, regardless of the selection made here.

  • Review the page and click Finish.
  • A task is created that begins the virtual machine migration process.


Linked Clones:

Storage Motion Issue:

How To’s sVmotion CLI/VCO style:

Storage Considerations for vCloud:


Raw Device Mapping – RDM in vSphere 4 and 5 Resources and Experiences

RDM (Raw Device Mapping) has changed a little between VI and vSphere. They have continued to improve over time as well. Now there are a lot of resources out there for RDMs in general but I just wanted to do my own research and learn about the particulars. I also wanted to note some of the blogs I used and the difference between vSphere 4 and vSphere 5. I don’t think things have changed a whole lot for RDM’s other then the size of pRDM (Physical or Pass-thru) have been increased almost to 64TB.

Now RDM is more of a topic of “use case” than anything. Other things like “Performance” can be debated on all kinds of levels and usually there are always workarounds to avoiding using RDM’s. Now the real limitation to RDMs in my opinion is pretty much not being able to back it up with the vStorage API. That is my only real personal gripe. The size of an RDM can sometimes be more accommodating for large Databases and large file servers in some cases. Again this is “use case”. For the most part when I see RDMs implemented in our environment it was done based off of bad logic… meaning some people don’t understand the risk associated with what they are doing or wasn’t necessarily the best “use case” they intended it for. Mostly when I see that a pRDM is used a vRDM would’ve worked better.

A misconception: “RDM’s are more secure because you cannot snapshot”

I am not sure where I can start this discussion. This was what a colleague of mine told me around the first time I started learning vSphere 4 and I kind of believed him at first but he too was relatively new and I know being in a virtual environment there is a way around anything..almost.

This was a hot topic because we were virtualizing AD servers and they were arguing with the AD team about how they should implement AD on vSphere. The security team didn’t want anything to do with it and they didn’t want to go along with it at all. So the engineer(s) decided to throw out the RDM as a way to keep people from being able to snapshot AD so they could keep AD from blowing up (Misconception as well) and securing the data because you couldn’t just copy it off. What they were thinking was that if they cannot actually see the VMDK file then no one can steal or retrieve the data. What a misconception that is… there are many ways to convert any RDM into a VMDK file as long as it’s not over a particular size that is – 2TB – 512mb.

You can use a variety of tools from VMKFSTools, Cold Migrations, sVmotion (vRDM) and cloning. Of course there are limitations like snapshots and such which can prevent this from happening. What you need to note is that if you are using a RDM for a particular case make sure you DON’T accidently convert it to a VMDK file.

The following reference is from a KB located here:

Cold Migration

With file relocation:

  • Any non-RDM virtual disks are physically moved to the destination.
  • The virtual machine configuration files are physically moved to the destination.
  • Raw LUNs themselves cannot be moved, as they are raw disks presented from the SAN. However the pointer files (RDMs) can be relocated if required.
  • When performing a cold migration of a virtual machine with RDMs attached to it, the contents of the raw LUN mapped by the RDM are copied into a new .vmdk file at the destination, effectively converting or cloning a raw LUN into a virtual disk. This also applies when the virtual machine is not moving between ESX hosts. In this process, your original raw LUN is left intact. However, the virtual machine no longer reads or writes to it. Instead, the newly-created virtual disk is used.
  • If you wish to cold migrate a virtual machine without cloning or converting its RDMs, remove them from the configuration of the virtual machine before migrating. You can delete the RDM from the disk when removing it (the raw LUN contents are not changed). Re-add them to the configuration when completed.

Again other references can be noted in the KB. Also if you wanted to convert your RDM from Physical to virtual mode just follow this KB here. Also Scott Lowe did a great job writing about this similar subject in regards to svMotion here.

In short, I just wanted to know a particular reference and the misconception of RDM’s being secure because you can easily convert an RDM to a VMDK and VMDK to RDM.

I would like to thank VMware and all the VMware Bloggers if you know of any other good resources let me know and I’ll update it.

Resources vSphere 4.1: (pg.28) (Lots of references to RDM) (Lots of Good stuff) (RDM performance Blog) (Great resource for learning RDMs and Conversions) (RDM Performance Article) (Scott Lowe’s Blog on sVmotion RDM)

Resources vSphere 5: (pg. 39) (pg. 140)

***Disclaimer: The thoughts and views expressed on  and Chad King in no way reflect the views or thoughts of his employer or any other views of a company. These are his personal opinions which are formed on his own. Also, products improve over time and some things maybe out of date. Please feel free to contact us and request an update and we will be happy to assist. Thanks!~

%d bloggers like this: