Subscribe

Feature request: RCU change

Currently, the option to select the source of the clone when performing a rapid clone, only allows you to select an existing VMware based snapshot. This is almost no use as it is bad practice to keep VMware snapshots for any length of time. So maintaining an evolving series of templates as a server develops is impossible without performance issues.

As filer snapshots taken through VSC or OnCommand have the ability to take a VMware snapshot as part of the process, it should surely be a simple addition to allow a filer snapshot to be used as the source for the original clone rather than a VM snapshot.

Re: Feature request: RCU change

One can use any VM or template as the source for the cloning with VSC installed. You can right click a template ->got to NetApp Context->Provisioning&Cloining->Create Rapid Clones. I don't recall where it forces you to use a VMware Snap. Depending on the number of clones, Ontap version and other environment variables, it will use FlexClone for Files, FlexClone for Volume, standard VAAI offload, just a Copy or a combination of all for cloning.

Re: Feature request: RCU change

The process of creating the clones is fairly straight forward but the second section in it "Clone Source" only lists VM snapshots. If there are none, this step is skipped and you can only clone the VM as it is right there.

Suppose I wanted to keep a history of changes to a gold server image, so that I could roll back at any time to an earlier version. The only way I could do this is to either keep VM snapshots which is bad practice, or restore the earlier NetApp snapshot before creating the clones. This then has the problem of being unable to roll forward again.

If using ontap directly to create flex clones or LUN clones, you can specify the snapshot you clone... I'm just confused as to why RCU would not allow you to do the same

Re: Feature request: RCU change

With no response or acknowledgement from anyone at NetApp... is this the right place to be raising feature requests and do these posts get looked at by the devs, or should I be raising it somewhere else?

Re: Feature request: RCU change

Thanks for the feedback.  Sorry for the delay.

You are correct with regard to the impact of keeping vm snapshots.  This is not a best practice, as such we're considering removing that particular feature from VSC.

With regard to leveraging copies/clones on the controller, the issue we have is getting these objects represented in vCenter (so you can right click on them).  We've considered registering these copies in vCenter, but that quickly pollutes the inventory.  Something else we've considered is registering copies, placing them in a specific vm folder and marking them as templates.  This seems to address some of the user interface clutter, but increases the number of objects vCenter has to manage.

How would you use this type of feature.  ie: are you looking to keep templates outside of vCenter management?

Thanks

Re: Feature request: RCU change

Thanks for your response

I am currently using FCP and VMFS datastores so have no idea if this is different for NFS (although we are looking at moving to NFS in the near future).

Currently we use physical servers for our citrix environment and I am looking at getting them virualised. In managing the current servers, we use altiris to create an image of a test server, and from there we can deploy that image to the live servers. That allows us to roll forward or back through those images without affecting any other systems. What I was trying to do was recreate this process using snapshots.

I have a small datastore created which only holds the gold server. This image is subjected to updates, revisions, and (un)installs over time, with a backup being created in VSC at each point. The server can then be cloned to a couple of test servers, and if accepted, can be cloned 20 times as live. This is all fine as long as there is never a need to roll back (and if we were using NFS, I could just use the redeploy option to update them all). However, consider if I have an updated image on test, as yet unaccepted, and find myself in a position of needing to replace or add to the live servers (currently cloned from an older version). I would not be able to deploy more clones without destroying the test servers and restoring the earlier snapshot on the template datastore.

The way VSC currently works is great, but the only thing missing is the ability to create your clones based on a netapp snapshot not a VM snapshot. When creating the clones, I would want to be able to pick from a list of backup date/times to use as the base for that clone. I don't want to be maintaining any templates outside vCenter or do anything more complicated than would be allowed if I were to keep the VMWare snapshots instead of sticking to the better practice of using NA backups

Hope all that made sense

Re: Feature request: RCU change

Thank you for the detailed use case.  Yes, this makes sense.  I'll make sure our product management team gets this. 

In the mean time (once you get to NFS based datastores), you could substitute "Rapid Clone" for "backup copy".  Granted it wont be as clean as having a backup in the catalog, but it would provide a quick and space efficient copy of the VM at a point in time.  If you wanted to automate this, there is an API and even a set of powershell cmdlets for VSC.

Re: Feature request: RCU change

Thanks Eric, I will give them a look. It is likely we will be replacing/updating our filer at the end of the year so will be looking NFS as part of the replacement, whatever that may be. Can't hurt to get familiar sooner than that though.

And thanks for referring it on. I really do like the tool and hope it can be as useful for us in the future.