This video shows you how install the Rapid Clone Utility, and use it to create virtual desktops very quickly – and also how to turn on deduplication and grow a NetApp volume.
Some thoughts on the RCU from making the video... Firstly, I can spot to very small tweaks that could made with the RCU. It doesn’t allow me to control where the VMs are created from a folder or resource pool perspective. All the new virtual desktops are created in the same folder as the source template – and there’s no ability to place the rapid cloned VMs into a resource pool – and this can lead to big long flat list of VMs – which ain’t pretty. Especially, in a VDI environment where there could be hundreds of virtual desktops. You might think this is a minor issue, after all you can drag & drop the VMs after the cloning process to the right VM folder/resource pool. Erm, well not quite. During the deploy process you can ask the RCU to register the new virtual desktops with VMware View/XenDesktop brokers. I don't know about XenDesktop but currently View is very happy about you moving vCenter objects around. If you don’t know what I mean check out this recent KB article that Chris Wolf brought to my attention:
If you watch the video you will see the RCU automatically create a NFS volume/mount point for me, and present it to my ESX host (it feels a lot like the way SRM automatically presents replicated LUNs during a test of DR plan). The way it does this by modifying the permissions on a newly create volume/mount point – adding the ESX hosts in by IP address. What IP address? Well, every single VMKernel port on the ESX host – so what you see – is not just IP address used to speak to the filer (18.104.22.168 in my case) but also VMotion ports (10.0.0.0 in my case) and if you using ESX4i, the management ports also get listed (192.168.3.0 in my case) because they are “vmkernel ports” too. I’m perhaps griping a little here. Because firstly, its much faster/automated to use the RCU to create/permission up the volume/mount point – and secondly I don’t think the vNetwork/vStorage allow for the storage vendors like NetApp and EMC to work out – that this little pig goes to VMotion, and that this little pig goes to management, and this little piggy goes wee-wee all the way to NetApp FSA or EMC Celerra… Anyway, it wasn’t too much of chore to highlight the IP address that shouldn’t be there, and remove them – compared to the core having to do all the work manually (including mounting the NAS/NFS mount point to each and every ESX host!!!)
The RCU cloning process is pretty good, but it reliant on the “Guest Customization” settings and Sysprep process. If you know (and loathe) sysprep well, you will know its not especially quick – and also it takes some work with sysprep.inf files to make sure the computer account objects of the virtual desktops are dropped in the right OU. That’s important if your unlucky enough to have to use MS GPOs to control the desktop environment. In contrast VMware’s View Server now ships with a linked-clone feature and something called “QuickPrep”. QuickPrep creates computer account objects for the virtual desktops – and ALSO puts them into the right OU for your GPOs. What I would love is a combo of both – RCU with Linked-Clones would be quiet cool…
Another interesting thing about the RCU is the “destroy” feature – powers of all the VMs, unregisters/deletes the VMs, and then goes off and destroys the volume/mount point. Clearly, despite all the warnings anyone using the RCU will have “click: Engage Brain” before they use this. Currently, what the destroy option DOES NOT do, is delist the virtual desktop pool from the View Broker. I guess that’s OK, after sometimes you will want to keep that metadata, and other times you won’t. The only trouble is you will have to remember to un-entitle (is that word?) the virtual desktop pool because until you did it would be listed and viewable by end-users – with no virtual desktop behind them. That would make you popular “yeah, we know you can see it on the list… but we destroyed them all this morning… sorry, about that… have nice day… bye…”
All of this is all well and good. But there’s a feature of RCU that makes me smile – and it’s kind of tucked away. That’s the ability to just right click a NAS/NFS volume and make it bigger. You just right click and type in the new size, and jobs done. Neat…
Anyway, there’s been a lot of traction on the blogs this week, along the lines of “which storage vendors has the best integration tools”. I’m keeping well out of the debate because I don’t want to be caught between two vendors who I have enormous respect for (EMC and NetApp). But my plan is to do a session with NetApp on their integration tools – and do videos of them. AND do the exact same with EMC. I will blog about both not to do some lame compare/contrast – but just to showcase how both vendors are working hard to integrate their array functionality into the new vSphere vStorage APIs. There’s a lot marketing guff around the new APIs and wonderous they are (and they are) but they really don’t come alive until you see them on screen and know how what their advantages and disadvantages are.