Operating system provisioning

[steverichards27]

I'm trying to understand NetApps operating system provisioning direction for VDI.  I understand where vmware are going with their cloning approach and where Citrix are going with provisioning server.  NetApp seems to have an approach that could potentially work for all VDI platforms and for all user types:

Assigned - persistent

Pooled - persistent

Pooled - non persistent

But I'm unsure about the use of netapp in the last case.  Ie is it possible with netapp to re-provision the operating systems from the master frequently, for example every week or even every night.  I'm assuming this would require the new clones to not have to go through the sysprep, add to domain etc process every time they boot.  Citrix does this by inserting the machine SID into the stream at runtime,  I guess it would be possible to insert a machine SID from a database at clone time with Netapp.

Anyway interested to understand where you are going with this and what the options are

Steve

[angelage]

Hi Steve,

NetApp cloning technology can be used on every desktop type you listed.  On 4/2, we will be releasing a new product "Rapid Cloning Utility (RCU) 2.0" that can automate the creation of all virtual desktops, including pooled non-persistent.  RCU 2.0 is a vCenter plug-in that automates the creation of NetApp FlexClones (both file-level and volume-level) and guest VM customization.  You also have the option to turn on the virtual machines when they are done.  Because cloning is offloaded to the NetApp filer, it is very quick (hundreds of clones in minutes) and the VMs created are naturally "thin" (only consumes the storage space of 1 VM).  Once created, the clones are ready to be imported and managed by a connection broker.  You can also use the tool to destroy your VMs.

This tool works for all the desktop types.  For pooled non-persistent, you simply destroy all the VMs and re-clone from the golden image.  You can do it every night or every week, or whenever you need to patch the OS.

Keith did a great blog on RCU which also includes a demo. Take a look for more details  http://blogs.netapp.com/virtualization/2009/03/sneak-peek-netapp-rcu-20.html

If you want more details on the various desktop types, checkout Abhinav's 7-part series on his blog  http://blogs.netapp.com/virtualization/2009/03/netapp-and-vmwa.html

Does this answer your question?

[steverichards27]

Thanks for the info,  I've watched the Video but not managed to get through the 7 blog posts yet 🙂

[abhinavj]

To add on what Angela highlighted...

Considering the VMware View Manager options for non-persistent desktops, there are four ways in which non-persistent desktops can be served:

1. Individual Desktops in non-persistent access mode

2. Manual Desktop Pool in non-persistent access mode

3. Automated desktop pool, leveraging VMware full clones in non-persistent access mode

4. Automated desktop pool, leveraging linked clones in non-persistent access mode

For details, visit the blog post that Angela highlighted.

Out of these four options, only the option #4 has the way to re-provision the VMs from the master image and provide a fresh desktop copy with a 'clean' C drive.

The NetApp RCU approach is applicable to #1, and #2 above.

Lets look at different scenarios for non-persistent access mode and how NetApp can help.

Scenario1: If your requirements are that the desktops be in non-persistent mode and the user gets a clean desktop image when they login, you could use RCU capabilities and have the golden VM disk be in independent, non-persistent mode. This way all the cloned VMs will have disks in independent, non-persistent mode. Leverage the policies in View Manager to have VMs powered off when not in use. That way when the VM gets assigned next time to a different user, it is a clean image.

Scenario 2: If your requirements are that you want to update the VM baseline and are ok loosing the changed made to the VMs, re-provision the entire pool from a new baseline. You could destroy the pool and use RCU to re-provision from the new baseline and import in View Manager. This will involve guest customization for the VMs and adding them back in View Manager.

Customers will have a mix of user profiles that require different policies for different user types. Our close partnership with both VMware and Citrix provides customers the flexibility to have the best of the breed solution for all desktop types.

I hope this helps.

Regards,

Abhinav

[steverichards27]

Hi Abhinav,

Thanks for that answer it gets me closer to understanding things and I also realise that my terminology might have confuded things a little.

Pooled - users get assigned an arbitary PC each time they login

Assigned - users get assigned the same PC each time they login

Persistent - the PC is provisioned and then continues to be used for many days, and hence needs to be managed (patch, anti-malware etc)

Non-persistent - the PC is provisioned fresh each day, only the master image needs to be managed

In your answers you were assuming a slightly different meaning to non-persistent, ie the ability to delete the user specific write disk when a user logs off, so that the next user uses a clean cloned image.

I need to sort out my terminology!

Anyway I'm most interested in how we achieve a solution with an un-managed provisioned PC, ie one where we only need to manage the gold image and re-provision whenever it get updated.  You've explained that this is technically possible using your new cloning utility, however I still have a few questions:

If I provision a 1000 PCs today and delete them and re-provision them again tomorrow:

1. Can I set it up so that these new machines have the same names, mac addresses, SIDs and hence AD machine objects as they had yesterday
2. If not does Active Directory cope ok with thousands of machine objects being created and deleted a day
3. If AD copes ok, I worry that other systems that keep track of machines in use eg licence management tools, might get confused

However the benefit seems to be that if NetApp can support this pooled/non-persistent mode then we could use one technology for OS provisioning no matter what the solution.

One final question, do you have anything in your roadmap that would allow a physical device to boot from one of your disk clones, using for example iSCSI?

Thanks

Steve

[keitha]

Andrew,

Interesting problem. You want to reprovision each day just to be sure no end user data or changes remain? I haven't tried this but I would be tempted to leverage out snapshot capability rather then reprovision each day. Once you push out your image take a backup using SMVI then schedule a volume restore each day. This would return the VMs to a prisine state each day. If you had to change your base image you would have to re provision though. I know RCU 2.0 will do a nice clean up from the VMware and Storage front (unregister VMs and delete volumes) but when you reprovisioned they will be new VMs and so would reregister themselves in AD. I'll need think a little on this one.

Keith

[steverichards27]

Hi keith,

Youv'e misunderstood my requirement.  I'm not looking to re-provision as a way to destroy user data.  I'm looking to re-provision because I don't want to manage the provisioned clones, I only want to manage (update apps, installpatches and anti-malware updates) the gold image.

Steve

[abhinavj]

With re-provisioning, you can get the same machine names as they were before. But not sure about the MAC address, and SIDs. This would require extra coding.

In our NetApp solutions data center, we provision, destroy, re-provision 1000s of VMs every day to test different aspects of VDI scalability. AD seems to cope up very well.

"If AD copes ok, I worry that other systems that keep track of machines in use eg licence management tools, might get confused."

Need to think about this one. What are you doing currently?

"One final question, do you have anything in your roadmap that would allow a physical device to boot from one of your disk clones, using for example iSCSI?"

This can be done today. Infact, the NetApp Kilo Client lab in RTP with 1000s of physical servers, boot diskless from iSCSI and FC SAN. Several customers are using this as a Reference Architecture for their data centers across the globe.

Check out this article: http://partners.netapp.com/go/techontap/tot-march2006/0306tot_kilo.html"

Regards,

Abhinav

[steverichards27]

Hi Abhinav,

This is getting close to covering all my questions.  The one remaining issue is whether when I destroy my existing 1000 desktops and re-provision them from my updated gold image they can look to the rest of the system as if they are the same machines.  To achieve this with any confidence I think they would require the same MAC address, machine name and Machine SID as they had before.  Other configuration we can probably push into the image post boot.  At this point we haven't verified which applications and infrastructure might need these things to stay the same, but we know they are likely to exist and with an application portfolio in the tens of thousands of apps and with lots of other management systems its better to be safe than sorry.  Citrix provisioning server does keep these parameters the same, so thats a useful reference.

Steve

[steverichards27]

The iSCSI boot scenario you talked about is very interesting.  This section of the web page you linked to:

NetApp FlexClone technology is used to nearly instantaneously create space-efficient copies of those golden images, which are then "personalized" (individual server information such as IP address, hostname, etc.)

Is the kind of personalisation that I was referring to in the VDI re-provisioning question.  I don't know how this "personalisation" is being achieved, whether it's custom scripting, or some built in capability of your solution?

Steve

[zhu]

In Kilo Client case, there are thousands of blades. We use dhcpd.conf to keep the IP and hostname same during reboot or image change.

Linux OS is easy. For Windows, we have a name change script to reserse look up the IP and hostname in DNS and change name for the host.

For provisioining, either iSCSI or FCP, we have pre-configured igroup in the filer.

We use the golden image LUN snapshot to create new LUNs and map to the igroup.

We can re-image thousand of blades in less than an hour.

Here are some lines of the script:

@lines = $t->cmd("igroup create -i $blade $iqn");
        $newlun = "/vol/vol1/redhat/" . $blade . ".lun";
print("lun = $newlun \n");
@lines = $t->cmd("lun create -b /vol/vol1/.snapshot/rhbase/redhat/rh.lun $newlun");
@lines = $t->cmd("lun map $newlun $blade");

Rachel