When you try to migrate a guest, that is using one or more RDM disks, you might see this message.
The reason this is most probably because the LUN IDs are different on the source and the destination ESX server.
One solution is:
- stop the guest
- write down the Physical LUN ID
- remove the RDM disk(s)
- vMotion the guest
- add the RDM disk(s) to the guest based on the Physical LUN ID
- start the guest
But why do this the hard (manual) way when we have PowerCLI ?
Read more…
On the Yellow Bricks blog there was today a very interesting entry called Performance : Thin Provisioning. Besides the link to the excellent VMware document called Performance Study of VMware vStorage Thin Provisioning, Duncan also included some tips and tricks.
Since I’m in favour of automating as much as possible in my vSphere environment, I decided to have a look how all this could be scripted.
One of the interesting new features in vSPhere is vStorage Thin Provisioning. I’m not going to explain what Thin Provisioning is all about. For that you can consult several knowledgeable blogs (for example this entry on Virtual Geek) and/or books (for example Scott Lowe’s excellent Mastering VMware vSphere 4.0).
The problem I have with Thin Provisioning, is that there are a lot of existing guests and templates out there that were created with Thick VMDKs in the past. The only documented way I could find to convert these Thick VMDKs to Thin VMDKs was to use svMotion from the vSphere client.
Now that is not a solution I want to (or can) use in an automated environment. Read more…