It would be much easier to simply move vol0 to aggr1 and destroy unused aggr0 after that. This can even be done non-disruptive if controller is in HA pair or with minimal downtime otherwise. ... View more

You can simply share/export /vol/voldata and move using host command content of myqtree to volume root (mv myqtree/* . or similar). ... View more

"Synchronous SnapMirror" != "sync mirror". In cDOT you have option for SyncMirror, but you do not have support for Synchronous SnapMirror. ... View more

cDOT does not support synchronous snapmirror at all. ... View more

I'm not sure I understand the problem. Client will contact server based on client side name resolution; if CIFS server name resolves to address in your data VLAN, client will be using it. There is not much you can do on filer side. ... View more

The first snapshot is baseline; the last snapshot is previous baseline (most likely already deleted on source). Last snap mirror transfer was delta between previous and current baseline snapshots. ... View more

Fractional reserve ensures your LUNs won't suddenly get out of space. Make sure you understand implications before disabling it. ... View more

De duplication creates snapshot internally. So it may happen. The first thing to check would be fractional reserve settings. ... View more

Snap mirror creates snapshots by itself, it does not rely on scheduled snapshots. If you delete snap mirror base snapshot, next update will fail indeed and you will need to rebaseline (you may be able to resync if some other common snapshot is still available). ... View more

That sounds like hardware problem then. If you have RLM, you could try to connect it to LAN with DHCP server (default is to use DHCP). ... View more

You did not show any information related to snap mirror, so I am afraid I do not understand your question. You have automatic scheduled snapshots; old snapshots will be deleted according to retention policy in your schedule. ... View more

You do not provide enough information. What are you doing exactly? Connect console. Set terminal program to 9600, 8 bits, no parity, no flow control. Switch FAS on. Wait at least a couple of minutes (it takes time). Are you sure you are using the right port for console connection? ... View more

Yes, cluster peering can share ports with data LIFs. It is used to replicate SVM config, so I do not expect very high bandwidth demand here after initial configuration. ... View more

MetroCluster Installation and Configuration Guide contains detailed steps to do it, as well as references to other resources. There are also Express Guides and MetroCluster Management and Disaster Recovery Guide. Again - if something is missing there or not clear, it is better to ask specific questions.   I thought you had experience with 7-Mode MetroCluster, may be I misunderstood it. In a nutshell - you have two single node clusters that connect to the same set of disk shelves. Disks are mirrored between two locations on aggregate level (SyncMirror) - each aggregate consists of two plexes, each plex has disks from the same location. This ensures that even if one location is completely lost, data is still available. SVM configuration is replicated between two clusters; when failover happens, the SVMs are started on partner cluster using the same disks from failed node (may be only half of them if location is not available).   In normal operations each cluster (i.e. single node in your case) works independently, using own disks. So you need to only be concerned about standard configuration tasks - MetroCluster is mostly transparent here.   Network configuration should be symmetrical - both nodes must have access to the same network resources (VLAN, subnets etc) and ports must be configured accordingly. When SVM configuration is replicated, matching LIFs are created that are (attempted to be) connected to the same network objects. ... View more

CNA target in Ethernet mode can perfectly work for FCP LIFs using FCoE, which is why more information what OP actually wants is needed. Also changing mode from CNA to FC requires hardware change, so is more involved than just a single command. ... View more

Stretched metrocluster consists of two single node clusters. Card with SFPs is FC-VI and is required for NVRAM mirroring. Other than that you can by and large consider it very similar to 7-Mode - you have mirrored aggregates that are taken over by partner. So network design should be pretty much the same. The main difference is FCP where multipathing is limited to one node only for obvious reasons. Standard Data ONTAP documentation offers pretty detailed step by step description how to cable and setup stretch metrocluster. Did you read it? What is missing there? ... View more

If you have cDOT, volumes are not presented by nodes - volumes are presented by SVM. You need to create data LIFs on second node and add them to SVM that contains those volumes. ... View more

I am not sure I understand how "making vserver" is related to FCP adapters. Please paste exact command and its output. ... View more

All ports are active means LIFs can be active on any physical port. But each LIF is still bound to a single port (or ifgrp) at any given time. So you can distribute LIFs, but not traffic for each LIF. ... View more

I do not think completely non-disruptive migration is possible here. Clients still need to remount from target filer. ... View more

7-Mode or C-Mode? Both filers part of the same cluster or not? ... View more

I do not see real usage for second level VIF in cDOT. You have LIF failover between different physical ports as the first class citizen; and it is also active/active, while VIF is always active/passive. Unless you are explicitly interested in link probes implemented by single mode VIF; I do not think LIF failover does it. ... View more