Hi all,
for the first time I've experimented the RCU tool that now is inside the VSC 2.0.1 for VMware. But during the tests I've noted something that left me doubtful.
I've always thought (and this is the NetApp message to folk :)) that the "rapid" clone utility used some way the flex_clone or the lun_clone techniques to quickly create vmdk images starting from something on active file system volumes... I mean: vmdk on a lun/volume -> Data Ontap snapshot of this -> flex_clone -> rewritable image of the originating data and, of course, all this for dozens of VM performed very quick because there's nothing to transfer!!!
Instead when I ran those test I've choosen a running VM, selected the NetApp menu item -> provisioning and cloning -> rapid clone and, looking both at the putty on my filer and on the status bar of vCenter I've seen no activities on the NetApp at all (no snapshots, no clone and so on...) while the vCenter reported: creating snapshot (a VMware one!!!) -> copying ....copying??? In short the same time and technique I could script or manually execute.
So, why the rapid clone tool asked me for a flex_clone license??? And why if I would use it on FC or iSCSI LUN? I could understand for VMware datastore on NFS...And, last, why a flex_clone if there's NO cloning (data ontap) at all?
Have I missed something?
Regards,
Hi Milazzo,
In short, you are correct, when "rapid cloning" from a vmfs datastore to a vmfs datastore, there is no speed increase or capacity savings. The vmfs filesystem/volume manager obscures the vmdk file block ranges from RCU. The biggest benefit of the "Rapid Clone" wizard in that case, is that you can create multiple virtual machine clones in a single execution. The time to deploy will decrease and the capacity savings increase as you upgrade to ESX and DataOnTap versions that support VAAI (storage array offload). You are also correct that NFS is a different story, there the RCU provides the benefits of copy/clone offload today (because the files are not obscured).
The flex_clone license is required because the RCU allows you to deploy X number of VMs on Y number of new datastores (luns). It is in this case that RCU can dramatically decrease the time to deploy as well as the capacity required even when using vmfs based datastores. For example, if you needed 200 new VMs on vmfs datastores, you could create 10 vms on 20 new datastores. In this case, RCU will create a new vmfs datastore, copy 10 VMs into it, then clone it 19 times, and attach the lun clones as datastores. The reason the flex_clone license required is because RCU uses the flexclone lun feature rather than the (older) lun clone. The flexclone lun feature is used because it creates clones of a lun that are not backed by a snapshot. These are effectively "pre-deduplicated" luns instead of luns that can "busy" a snapshot.
There are a few documents here that will help. Most of the RCU 3.0 FAQ applies to the VSC 2.0.x cloning and provisioning functionality. http://communities.netapp.com/community/products_and_solutions/virtualizatio...
I hope this helps clear things up.
Cheers, -Eric ---- Eric Forgette NetApp forgette@netapp.com | eric4jet@gmail.com
On Dec 22, 2010, at 9:47 AM, Milazzo Giacomo wrote:
Hi all,
for the first time I’ve experimented the RCU tool that now is inside the VSC 2.0.1 for VMware. But during the tests I’ve noted something that left me doubtful.
I’ve always thought (and this is the NetApp message to folk J) that the “rapid” clone utility used some way the flex_clone or the lun_clone techniques to quickly create vmdk images starting from something on active file system volumes… I mean: vmdk on a lun/volume -> Data Ontap snapshot of this -> flex_clone -> rewritable image of the originating data and, of course, all this for dozens of VM performed very quick because there’s nothing to transfer!!!
Instead when I ran those test I’ve choosen a running VM, selected the NetApp menu item -> provisioning and cloning -> rapid clone and, looking both at the putty on my filer and on the status bar of vCenter I’ve seen no activities on the NetApp at all (no snapshots, no clone and so on…) while the vCenter reported: creating snapshot (a VMware one!!!) -> copying ….copying??? In short the same time and technique I could script or manually execute.
So, why the rapid clone tool asked me for a flex_clone license??? And why if I would use it on FC or iSCSI LUN? I could understand for VMware datastore on NFS…And, last, why a flex_clone if there’s NO cloning (data ontap) at all?
Have I missed something?
Regards,
Hi Eric,
thanks. It's almost clear but not completely. So, VSC cloning (formerly RCU) has NOTHING to do with this emphatized since a couple of years (NetApp tube)? http://www.youtube.com/watch?v=E4vs8UFfqqA The other concept not clear is about what you said about "pre-deduplicated" LUNs. What if I don't want to apply dedup on volumes? I mean, what If I only want to have a lot of VM "pointing" to an originating image locked by a snap and duplicated r/w by flex_clone? Maybe with a PAM in front of all that...
Regards
-----Messaggio originale----- Da: Eric Forgette [mailto:eric4jet@gmail.com] Inviato: mercoledì 22 dicembre 2010 18:05 A: Milazzo Giacomo Cc: toasters@mathworks.com Oggetto: Re: Virtual storage console RCU mistery...
Hi Milazzo,
In short, you are correct, when "rapid cloning" from a vmfs datastore to a vmfs datastore, there is no speed increase or capacity savings. The vmfs filesystem/volume manager obscures the vmdk file block ranges from RCU. The biggest benefit of the "Rapid Clone" wizard in that case, is that you can create multiple virtual machine clones in a single execution. The time to deploy will decrease and the capacity savings increase as you upgrade to ESX and DataOnTap versions that support VAAI (storage array offload). You are also correct that NFS is a different story, there the RCU provides the benefits of copy/clone offload today (because the files are not obscured).
The flex_clone license is required because the RCU allows you to deploy X number of VMs on Y number of new datastores (luns). It is in this case that RCU can dramatically decrease the time to deploy as well as the capacity required even when using vmfs based datastores. For example, if you needed 200 new VMs on vmfs datastores, you could create 10 vms on 20 new datastores. In this case, RCU will create a new vmfs datastore, copy 10 VMs into it, then clone it 19 times, and attach the lun clones as datastores. The reason the flex_clone license required is because RCU uses the flexclone lun feature rather than the (older) lun clone. The flexclone lun feature is used because it creates clones of a lun that are not backed by a snapshot. These are effectively "pre-deduplicated" luns instead of luns that can "busy" a snapshot.
There are a few documents here that will help. Most of the RCU 3.0 FAQ applies to the VSC 2.0.x cloning and provisioning functionality. http://communities.netapp.com/community/products_and_solutions/virtualizatio...
I hope this helps clear things up.
Cheers, -Eric ---- Eric Forgette NetApp forgette@netapp.com | eric4jet@gmail.com
On Dec 22, 2010, at 9:47 AM, Milazzo Giacomo wrote:
Hi all,
for the first time I've experimented the RCU tool that now is inside the VSC 2.0.1 for VMware. But during the tests I've noted something that left me doubtful.
I've always thought (and this is the NetApp message to folk J) that the "rapid" clone utility used some way the flex_clone or the lun_clone techniques to quickly create vmdk images starting from something on active file system volumes. I mean: vmdk on a lun/volume -> Data Ontap snapshot of this -> flex_clone -> rewritable image of the originating data and, of course, all this for dozens of VM performed very quick because there's nothing to transfer!!!
Instead when I ran those test I've choosen a running VM, selected the NetApp menu item -> provisioning and cloning -> rapid clone and, looking both at the putty on my filer and on the status bar of vCenter I've seen no activities on the NetApp at all (no snapshots, no clone and so on.) while the vCenter reported: creating snapshot (a VMware one!!!) -> copying ..copying??? In short the same time and technique I could script or manually execute.
So, why the rapid clone tool asked me for a flex_clone license??? And why if I would use it on FC or iSCSI LUN? I could understand for VMware datastore on NFS.And, last, why a flex_clone if there's NO cloning (data ontap) at all?
Have I missed something?
Regards,
So, VSC cloning (formerly RCU) has NOTHING to do with this emphatized since a couple of years (NetApp tube)? http://www.youtube.com/watch?v=E4vs8UFfqqA
Actually, that video shows a prototype of the RCU which is now the VSC cloning feature. That video shows NFS based datastores though, not VMFS. The behavior you've experienced (the copying of vmdk files) is due to VMFS obscuring the contents of the LUN.
The other concept not clear is about what you said about "pre-deduplicated" LUNs. What if I don't want to apply dedup on volumes? I mean, what If I only want to have a lot of VM "pointing" to an originating image locked by a snap and duplicated r/w by flex_clone?
I think I chose a poor analogy. There is no requirement to apply dedup to the volume. You can enable dedup you want though, the two technologies complement each other very well. The use of the flexclone lun/file command (clone on the command line) does exactly what you describe as far as VMs pointing to an original image. The main difference, is that the image is no longer required to be locked in a snapshot. The WAFL engineers were able to make this all happen in the active file system, so compared to the "old days" - you get to have your cake and eat it too.
Maybe with a PAM in front of all that...
Your PAM idea is interesting in this context. Both the main system cache and the PAM cards are dedup aware.
Cheers, -Eric
On Dec 22, 2010, at 12:23 PM, Milazzo Giacomo wrote:
Hi Eric,
thanks. It's almost clear but not completely. So, VSC cloning (formerly RCU) has NOTHING to do with this emphatized since a couple of years (NetApp tube)? http://www.youtube.com/watch?v=E4vs8UFfqqA The other concept not clear is about what you said about "pre-deduplicated" LUNs. What if I don't want to apply dedup on volumes? I mean, what If I only want to have a lot of VM "pointing" to an originating image locked by a snap and duplicated r/w by flex_clone? Maybe with a PAM in front of all that...
Regards
-----Messaggio originale----- Da: Eric Forgette [mailto:eric4jet@gmail.com] Inviato: mercoledì 22 dicembre 2010 18:05 A: Milazzo Giacomo Cc: toasters@mathworks.com Oggetto: Re: Virtual storage console RCU mistery...
Hi Milazzo,
In short, you are correct, when "rapid cloning" from a vmfs datastore to a vmfs datastore, there is no speed increase or capacity savings. The vmfs filesystem/volume manager obscures the vmdk file block ranges from RCU. The biggest benefit of the "Rapid Clone" wizard in that case, is that you can create multiple virtual machine clones in a single execution. The time to deploy will decrease and the capacity savings increase as you upgrade to ESX and DataOnTap versions that support VAAI (storage array offload). You are also correct that NFS is a different story, there the RCU provides the benefits of copy/clone offload today (because the files are not obscured).
The flex_clone license is required because the RCU allows you to deploy X number of VMs on Y number of new datastores (luns). It is in this case that RCU can dramatically decrease the time to deploy as well as the capacity required even when using vmfs based datastores. For example, if you needed 200 new VMs on vmfs datastores, you could create 10 vms on 20 new datastores. In this case, RCU will create a new vmfs datastore, copy 10 VMs into it, then clone it 19 times, and attach the lun clones as datastores. The reason the flex_clone license required is because RCU uses the flexclone lun feature rather than the (older) lun clone. The flexclone lun feature is used because it creates clones of a lun that are not backed by a snapshot. These are effectively "pre-deduplicated" luns instead of luns that can "busy" a snapshot.
There are a few documents here that will help. Most of the RCU 3.0 FAQ applies to the VSC 2.0.x cloning and provisioning functionality. http://communities.netapp.com/community/products_and_solutions/virtualizatio...
I hope this helps clear things up.
Cheers,
-Eric
Eric Forgette NetApp forgette@netapp.com | eric4jet@gmail.com
On Dec 22, 2010, at 9:47 AM, Milazzo Giacomo wrote:
Hi all,
for the first time I've experimented the RCU tool that now is inside the VSC 2.0.1 for VMware. But during the tests I've noted something that left me doubtful.
I've always thought (and this is the NetApp message to folk J) that the "rapid" clone utility used some way the flex_clone or the lun_clone techniques to quickly create vmdk images starting from something on active file system volumes. I mean: vmdk on a lun/volume -> Data Ontap snapshot of this -> flex_clone -> rewritable image of the originating data and, of course, all this for dozens of VM performed very quick because there's nothing to transfer!!!
Instead when I ran those test I've choosen a running VM, selected the NetApp menu item -> provisioning and cloning -> rapid clone and, looking both at the putty on my filer and on the status bar of vCenter I've seen no activities on the NetApp at all (no snapshots, no clone and so on.) while the vCenter reported: creating snapshot (a VMware one!!!) -> copying ..copying??? In short the same time and technique I could script or manually execute.
So, why the rapid clone tool asked me for a flex_clone license??? And why if I would use it on FC or iSCSI LUN? I could understand for VMware datastore on NFS.And, last, why a flex_clone if there's NO cloning (data ontap) at all?
Have I missed something?
Regards,
Interesting discussion :-) For one of my customer we've already installed the PAM on a 3160C system that will also be used for VMware VIEW on NFS datastore: the PAM will permit to "read" from there the already read from disk images.
I've ran other tests and it seems that rapid cloning on NFS works creating new vmdk without consuming space. Using VMFS datastore instead the operation is quite 'rapid' but actually new files (and related spaces) are created using the VMware copy features.
Thank you very much,
-----Messaggio originale----- Da: Eric Forgette [mailto:eric4jet@gmail.com] Inviato: mercoledì 22 dicembre 2010 21:26 A: Milazzo Giacomo Cc: toasters@mathworks.com Oggetto: Re: R: Virtual storage console RCU mistery...
So, VSC cloning (formerly RCU) has NOTHING to do with this emphatized since a couple of years (NetApp tube)? http://www.youtube.com/watch?v=E4vs8UFfqqA
Actually, that video shows a prototype of the RCU which is now the VSC cloning feature. That video shows NFS based datastores though, not VMFS. The behavior you've experienced (the copying of vmdk files) is due to VMFS obscuring the contents of the LUN.
The other concept not clear is about what you said about "pre-deduplicated" LUNs. What if I don't want to apply dedup on volumes? I mean, what If I only want to have a lot of VM "pointing" to an originating image locked by a snap and duplicated r/w by flex_clone?
I think I chose a poor analogy. There is no requirement to apply dedup to the volume. You can enable dedup you want though, the two technologies complement each other very well. The use of the flexclone lun/file command (clone on the command line) does exactly what you describe as far as VMs pointing to an original image. The main difference, is that the image is no longer required to be locked in a snapshot. The WAFL engineers were able to make this all happen in the active file system, so compared to the "old days" - you get to have your cake and eat it too.
Maybe with a PAM in front of all that...
Your PAM idea is interesting in this context. Both the main system cache and the PAM cards are dedup aware.
Cheers, -Eric
On Dec 22, 2010, at 12:23 PM, Milazzo Giacomo wrote:
Hi Eric,
thanks. It's almost clear but not completely. So, VSC cloning (formerly RCU) has NOTHING to do with this emphatized since a couple of years (NetApp tube)? http://www.youtube.com/watch?v=E4vs8UFfqqA The other concept not clear is about what you said about "pre-deduplicated" LUNs. What if I don't want to apply dedup on volumes? I mean, what If I only want to have a lot of VM "pointing" to an originating image locked by a snap and duplicated r/w by flex_clone? Maybe with a PAM in front of all that...
Regards
-----Messaggio originale----- Da: Eric Forgette [mailto:eric4jet@gmail.com] Inviato: mercoledì 22 dicembre 2010 18:05 A: Milazzo Giacomo Cc: toasters@mathworks.com Oggetto: Re: Virtual storage console RCU mistery...
Hi Milazzo,
In short, you are correct, when "rapid cloning" from a vmfs datastore to a vmfs datastore, there is no speed increase or capacity savings. The vmfs filesystem/volume manager obscures the vmdk file block ranges from RCU. The biggest benefit of the "Rapid Clone" wizard in that case, is that you can create multiple virtual machine clones in a single execution. The time to deploy will decrease and the capacity savings increase as you upgrade to ESX and DataOnTap versions that support VAAI (storage array offload). You are also correct that NFS is a different story, there the RCU provides the benefits of copy/clone offload today (because the files are not obscured).
The flex_clone license is required because the RCU allows you to deploy X number of VMs on Y number of new datastores (luns). It is in this case that RCU can dramatically decrease the time to deploy as well as the capacity required even when using vmfs based datastores. For example, if you needed 200 new VMs on vmfs datastores, you could create 10 vms on 20 new datastores. In this case, RCU will create a new vmfs datastore, copy 10 VMs into it, then clone it 19 times, and attach the lun clones as datastores. The reason the flex_clone license required is because RCU uses the flexclone lun feature rather than the (older) lun clone. The flexclone lun feature is used because it creates clones of a lun that are not backed by a snapshot. These are effectively "pre-deduplicated" luns instead of luns that can "busy" a snapshot.
There are a few documents here that will help. Most of the RCU 3.0 FAQ applies to the VSC 2.0.x cloning and provisioning functionality. http://communities.netapp.com/community/products_and_solutions/virtualizatio...
I hope this helps clear things up.
Cheers,
-Eric
Eric Forgette NetApp forgette@netapp.com | eric4jet@gmail.com
On Dec 22, 2010, at 9:47 AM, Milazzo Giacomo wrote:
Hi all,
for the first time I've experimented the RCU tool that now is inside the VSC 2.0.1 for VMware. But during the tests I've noted something that left me doubtful.
I've always thought (and this is the NetApp message to folk J) that the "rapid" clone utility used some way the flex_clone or the lun_clone techniques to quickly create vmdk images starting from something on active file system volumes. I mean: vmdk on a lun/volume -> Data Ontap snapshot of this -> flex_clone -> rewritable image of the originating data and, of course, all this for dozens of VM performed very quick because there's nothing to transfer!!!
Instead when I ran those test I've choosen a running VM, selected the NetApp menu item -> provisioning and cloning -> rapid clone and, looking both at the putty on my filer and on the status bar of vCenter I've seen no activities on the NetApp at all (no snapshots, no clone and so on.) while the vCenter reported: creating snapshot (a VMware one!!!) -> copying ..copying??? In short the same time and technique I could script or manually execute.
So, why the rapid clone tool asked me for a flex_clone license??? And why if I would use it on FC or iSCSI LUN? I could understand for VMware datastore on NFS.And, last, why a flex_clone if there's NO cloning (data ontap) at all?
Have I missed something?
Regards,
-
Eric Forgette -
Milazzo Giacomo