NetApp cDOT – Restore SVM root volume

In my previous entry I have briefly describe how you can protect SVM root volume by using load-sharing mirrors. (The post can be found here: NetApp cDOT – SVM root volume protection). If you haven’t read it, and you are not sure what are the consequences of root volume not being accessible, I would encourage to give the article a try. Long story short, each SVM (Storage Virtual Machine, a.k.a vserver), has it’s own namespace. Root volume is a root (/) path of SVM. If SVM root volume becomes unavailable all NAS (CIFS/NFS) clients will lose access to all shares from that particular SVM. If you want to read a little bit more into namespace concept, check out my other entry: NetApp cDOT – Namespace, junction path.

Remember: when a SVM root volume became unavailable, it will be disruptive for all NAS clients! Never “experiment” on production environment.

Continue reading

NetApp cDOT – what is SVM or vserver ?

Today I would like to give you a brief introduction to SVMs. I think it’s really important to understand the concepts of SVMs if you want to be able to successfully manage NetApp cDOT clusters. SVM stands for Storage Virtual Machine.

SVM or vserver?

In earlier version of cDOT (clustered Data ONTAP) NetApp used a name vserver. Later on they switched to using SVM instead. Why do I mention the old name anyways? Because, to be consequence while working with CLI – SVMs are still refferred as vservers, for example:

cDOT01::> vserver show
                    Admin     Root                  Name    Name
Vserver     Type    State     Volume     Aggregate  Service Mapping
----------- ------- --------- ---------- ---------- ------- -------
cDOT01      admin   -         -          -          -       -
cDOT01-01   node    -         -          -          -       -
finance_svm data    running   finance_   aggr1      file    file
3 entries were displayed.

What’s imporant to understand SVM = vserver. By the way, one thing you can notice on this examples are three types of SVMs, I will describe that a little bit later.

What are SVMs for?

Storage Virtual Machines are needed to serve data to our customers or custodians. SVM contains data volumes and data LIFs (boy, that’s a lot of new shortcuts in this article..). LIF is a logical interface and is used for communicating with clients. On NetApp 7-mode you could configure IP address straight on the physical port, or you could create a vif (virtual interface). With cDOT you have to first configure LIF and then on LIF you can configure IP address and associate it with SVM..  I will go deeper into explaining LIFs in one of my next articles.

Why do we use SVMs?

Similar to 7-mode vfilers, in clustered mode Data ONTAP SVM are used to isolate the shared visualized data storage and network. For example you can have two SVMs: finance and marketing. Each contain their private volume, private LIFs (logical interfaces). From the customer-point-of-view those are two completely separate objects. Each SVM can have a separate administrator and can be managed independently by its SVM administrator. On NetApp cDOT you have to configure Data SVM if you want to share data to customers.  Using SVM have some other benefits, such as non-disruptive operations (like adding or removing nodes from the cluster, or nodes upgrades) and scalability – single SVM can contains volumes from different aggregates, which might be located on different nodes.

Types of SVMs

What I described in previous paragraphs refers mostly to one type of SVM which is  Data SVM – those are used to serve data to the customers. But actually there are more types of the SVMs:

Admin SVM

This SVM is created automatically during the cluster setup process. Admin SVM represents the cluster itself and it’s never accessed by the customers.

Node SVM

a node SVM is created when the node joins the cluster. If your cluster have 8 nodes, as a consequence you will have also 8 Node SVMs. Those SVMs represents individual nodes on the cluster and are also never accessed by the customers

Data SVM

The only type of SVM that is accessed by the customers. A data SVM represents the data serving SVM. Data SVM must contains a root volume, one or more data volume and one or more data LIF (logical interface).

System SVM

This type of SVM is created automatically for cluster-level communications in an IPspace.


Almost always when someone talk about SVM, they actually talk about Data SVMs. Most of your daily tasks will be around creating and managing Data SVMs – and they are often referred to simply as SVMs or vservers. If you have experience with NetApp operating in 7-mode you probably think of SVM as something similar to vfiler. This is quite accurate comparison, however –  the biggest difference is that with NetApp 7-mode vfiler creation was optional, where-as with NetApp c-mode you have to create at least one Data SVM if you want to serve data to your customers. In the future I plan to create some screencast showing you how to create SVMs, and what are the benefits of using them, what are the new features that NetApp 7-mode does not have.