Modifique NetApp 7-Mode a C-Mode

Recientemente me encontré con una nueva instalación de NetApp contribuyentes y descubrí que hayan sido enviados en 7-Mode en lugar de la C-Mode solicitada. El problema era que la mayor parte de la documentación que encontré estaba apuntando a las viejas versiones de ONTAP. Desde nuevos contribuyentes se envían con las nuevas versiones de ONTAP (Gracias NetApp!), Pensé que sería bueno para documentar el procedimiento para el cambio de 7-Mode a C-Mode.

El primer paso es configurar las variables de entorno de pre-arranque. Con el fin de ser capaz de hacer esto, usted tendrá que arrancar en símbolo del cargador.

  • Boot NetApp
  • Presione Ctrl-C cuando le pida para detener el proceso de arranque
  • Esto le llevará al indicador de cargador. Si no, puede perder su oportunidad y tendrá que reiniciar de nuevo
  • En Loader prompt:
    • set-defaults
    • setenv bootarg.init.boot_clustered true
    • boot_ontap
  • Estos comandos crearán clustered-mode como la configuración default

Ahora que tenemos la instalación en clustered-mode como default, el Filer arrancará en clustered-mode, pero no hemos terminado todavía. A continuación, tendrá que arrancar en el menú de arranque e inicializar las unidades. TENGA CUIDADO, ya que esto borrará todos sus datos. Así que este recorrido se aplica si usted está trabajando en un nuevo archivador o volver a la propuesta de un filer de 7-mode al clustered-mode. Si usted tiene alguna información que necesita ser salvado, o esto es un environment de producción, no siga estos pasos. Llame a support.

El arranque del menú de inicio:

  • Si va a configurar los parámetros por defecto de los pasos anteriores, esperar a que el declarante se reinicie
  • Si no, reinicie el Filer
  • A medida que el Filer está reiniciando, espere a que el indicador para entrar en el menú de inicio y pulse Ctrl-C para entrar en el menú.
  • Desde este menú seleccione la opción 4 (configuración limpia e inicializar todos los discos)
  • Recuerde que este paso será borrar todos sus datos, incluyendo la configuración, tales como direcciones IP, DNS, etc.)









  • El Filer se reiniciará y comenzará la inicialización de los discos.
    • Este proceso puede tardar bastante tiempo dependiendo de la cantidad de unidades instaladas.

Después de todos los discos se han inicializado, el script de instalación le pedirá para la entrada con el fin de configurar el “nuevo” Filer.

Si tiene más de un node, repeta todos los pasos en el otro node(s).

Casos de uso: Nuevas Configuraciones. Re-propositivo nodes de 7-modo para el modo C.

Recover your VMs in a Snap with Veeam, NetApp & VMware

recoveryWhen it comes to business continuity and disaster recovery, there are a plethora of options out there. From built-in vendor tools, third party tools and your typical backup/recovery strategy. Choosing a solution does not always result in the best solution, if we take into account the fact that no one person knows all the tools available, and no one has time to research them all. A lot of times tools are chosen based on the vendor’s size, reputation and word of mouth; and of course, a lot of marketing, which I am not a fan of. Every vendor will always say that their solution is the best out there, so don’t rely on marketing material, instead talk to colleagues and other IT individuals through social media, conferences, etc.

Recently I was tasked with providing a BC solution for a specific application. The business was overwhelmed when I presented six different approaches since they really didn’t know what they wanted. After some meetings, I was able to extract what they wanted to achieve, which was a cheap/free solution utilizing current infrastructure that provides granular, and fast recovery of VMs and file level. This sounded like a challenge, but luckily I had just attended a Veeam session at Cisco Live 2015.

The solution selected was Veeam Backup and Replication. This tool allowed for full visibility of existing NetApp volume snapshots of the VMware environment without having to run new backups/snapshots or any additional jobs. Veeam B&R, includes an Explorer tool that connects to both the VMware vCenter and the NetApp arrays. It is then capable of looking inside each volume snapshot, and present the actual VM instead of all individual files. At this point, you have the option to restore the entire VM or even individual files within that object. The great part about this is that if you have a snapshot for exchange server, you are actually able to restore files within that Exchange snap.



Veeam also supports other storage vendors such as HP Lefthand and 3PAR, and new storage vendors will soon be added to this product.

Give it a try, at some point this may be the right solution to a problem or business requirement.

Drunk History – Storage

For those of you that have watched this show (Drunk History), you either love it or hate. I love learning about history, specially when the narrators are drunk. It makes it very interesting and funny. Anyway, this blog post is not about the show, but about the history of storage breakthroughs that changed the way we do storage.

Anyway, there has been many technology advances that not only affected the storage realm, but also other software define solutions such as hypervisors. The birth of snapshots, array replication, cloning, etc are just some of the many advances that we now take for granted. Here is a good representation of the advances provided by NetApp for the last 30+ years.



When you are shopping for hardware, consider the slide above and ask yourself, what company has the most experience and are the pioneers in the field.

I’m just going to leave this here…



Deploying VVols on NTAP

VVolsEven before the release of vSphere 6, the hype for VVols has been in the upswing, and for a good reason. VVols allow for a granular management of VM objects within one or more datastores based on policies. I have written a few blogs about VVols, and also the requirements within NetApp here. I tend to write about the integration between the two vendors as I really like, and believe on their technology, and I am an advocate for both.

Anyway, deploying VVols on NetApp requires to first understand how this all works. So, with that in mind, don’t forget that this a software solution that relies on policies from both the VMware side and the NetApp side. As I explained on previous posts, deploying VVols on NetApp has certain requirements, but the one I’ll focus on is the VASA provider (VP). The VP acts as the translator between the VMware world and the storage array world, regardless of the storage vendor. Some storage vendors integrate the VP within the array others come as an OVA.

So, from the storage side, you first need to deploy the VP, and also in this case VSC, which is NetApp’s storage console within VMware. After all components have been installed, VASA will become your best friend as it will provision not only VVol datastores, but will also provision the volumes within NetApp, automatically create exports with proper permissions, and create the PE among others. The PE is a logical I/O proxy that the host sees and utilizes to talk to VVols on the storage side. In the case of an NFS (NAS) volume, the PE is nothing more than a mount point, in the case of iSCSI (SAN), the PE is a lun. Again, the VASA provider will automatically create the PE for you when you provision a VVol datastore.

Let’s start the roll out. Assumptions here are that you have already deployed VSC 6.0, VASA 6.0, and currently have vSphere 6.0 or later. On the NetApp side it is assumed that you have at least ONTAP 8.2.1 or later, and that you have already created an SVM of the protocol of preference whether it is iSCSI, FCP/FCoE or NFS, up to you.

The first thing you should do if you have both NetApp and VMware, or FlexPod for that matter, is to make sure your VMware hosts have the recommended settings from NetApp. To do this, go to VSC within the VMware Web Client, click summary, and click on the settings that are not green. VSC will open a new window and allow you to deploy those settings to the hosts. You should do this regardless if you are deploying VVols or not.



The next step is to create a Storage Capability Profile within VSC/VASA. Within the VSC, go to VASA Provider for cDOT, and select Storage Capability Profiles (SCP). Here you will create your own profile of how you would like to group your storage, based on a specific criteria. For example, if you want a criteria for high performance, you may select a specific storage protocol, SSD drives, dedupe options, replication options, etc. This is the criteria that VASA will use to create your storage volumes when deploying VVol datastores, and if you already created a volume, this is also the criteria that will be qualified as compliant for the desired VVol storage.

I created an SCP that required the protocol to be iSCSI and SAS drives, the rest was set to any. This will result in VVol creation on the SAS drives only, and under the SVM that has iSCSI protocol and LIFs configured. If there are no iSCSI SVMs this would not work. Pretty self explanatory, I hope.


Now that the SCP is created, we can provision a VVol Datastore. Right click on the cluster or host and select “VASA Provider for clustered Date ONTAP”, then Provision VVol datastore.


Start the wizard and type the name of the VVol datastore, and select the desired protocol. Select the SCP that you want to include within the VVol, the qualified SVM(s) will be available if it matches the SCP you selected. For example, if you selected the SCP/protocol that calls for iSCSI and you only have one iSCSI SVM, that will be the only one that you will have as an option, and the NFS or FCP/FCoE SVMs will not appear. If there is a qualified volume, you may select to use it, or you may select none to create a new. If creating a new vol, choose the name, SCP, and other options just like you would from NetApp’s System Manager. You will also have the capability to add/create more volumes to the VVol datastore. The last step is to select a default SCP the VMs will use if the do not have a VMware profile assigned to them.


This will cause VASA to talk to your NetApp array and create a volume based on the SCP specified, at the same time, VASA will create the PE, which in this case is a lun.  You can add/remove storage to the VVol datastore you created at a later time simply by right-clicking the VVol and go to the VASA settings. Below you can see the PE that the VP created within the volume that was created during the VVol deployment process.



The next step is to create a VM Storage Policy that points to the SCP. Once this policy is attached to a VM, it will “tell” the VM which datastore it is supposed to be on. So if you have a SQL VM on a high performance policy, you know that as long as the VM is in compliance, it will run in the high performance profile you created.  To create the VM policy within the Web Client, click on VM Storage Policies, select new (scroll with green + sign), give it a name and select the vCenter. For the rule set, select the VP from the drop-down box for “Rules based on data services” and add a rule based on profile name. For the profile name option, select the SCP you created initially under VASA. This will show you what storage is compatible with this rule. Since I selected the iSCSI SCP, it will show me the iSCSI VVol I have already created. This creates the VM policy that you can assign to individual VMs.




You can also have different storage policies for the Home folder and VMDK.





Pretty cool, right?!?

I hope this helps you get started with VVols.

SHIFT VMs between Hypervisors

computer_key_ShiftAs more and more hypervisors emerge in the market, and more features are added to current hypervisor offerings; businesses may opt to migrate between vendors to save money, add features, consolidate to a single platform, or simply to follow a strategic plan. The migration is costly, complex, time consuming and disruptive as it requires down time of the VMs to be migrated; which is often not an option.

If you use NetApp as your storage vendor, the solution for this problem is now available to you. NetApp has announced the release of OnCommand Shift; a tool that enables the migration between Hyper-V VMs into a VMware environment and vice versa. This conversion is automated and requires minimum intervention from the user, and it takes a fraction of the time that other tools would take otherwise. OnCommand Shift supports VMware ESX/ESXi 5.0 -> 6.0, and Microsoft Hyper-V 2008 R2 -> 2012 R2.

How does OnCommand Shift works?

OnCommand Shift utilizes NetApp’s FlexClone technology which allows for the creation of the target VM within seconds/minutes. This is accomplished by creating a VMDK; for example, from a VHDX file by simply creating pointers to the existing data rather than copying and duplicating such data in the storage array. So, regardless of the size of the VMs, the time necessary to create the new VMs will be minutes or even seconds, rather than hours or days.


OnCommand Shift creates a virtual hard disk file in the format of the destination hypervisor and includes headers, metadata, and writes only the differences in the file format, instead of copying all the data from the source. Shift also collects and stores all VM information, as well as other VM settings, removes any hypervisor proprietary tools, and takes a backup of the VM prior to the conversion. It then proceeds to convert the VMs, say from Hyper-V to VMware, and then it restores all the network interface configuration as well as other settings.



  • NetApp FAS2440 or higher
  • NetApp cDOT 8.2 or later
  • NetApp NFS and CIFS/SMB license for the controllers
  • Server to control the migration process (Physical or Virtual)
    • 2 vCPUs
    • 4GB RAM
    • 250GB storage Minimum (500GB preferred)
  • Data ONTAP PowerShell Toolkit version 3.0.1 or higher
  • PowerCLI 5.1 or higher
  • Microsoft Hyper-V PowerShell cmdlets
  • Microsoft .NET Framework 3.5