The shelves/disk must be unowned from the original filer and owned by the new filer when you are moving from one filer to another.
Regards, Bill
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of toasters-request@teaparty.net Sent: Friday, March 27, 2015 11:04 PM To: toasters@teaparty.net Subject: Toasters Digest, Vol 44, Issue 34
Send Toasters mailing list submissions to toasters@teaparty.net
To subscribe or unsubscribe via the World Wide Web, visit http://www.teaparty.net/mailman/listinfo/toasters or, via email, send a message with subject or body 'help' to toasters-request@teaparty.net
You can reach the person managing the list at toasters-owner@teaparty.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of Toasters digest..."
Today's Topics:
1. Re: Snapmirror relationships (Jeff Cleverley) 2. RE: Snapmirror relationships (Gelb, Scott)
----------------------------------------------------------------------
Message: 1 Date: Fri, 27 Mar 2015 16:05:07 -0600 From: Jeff Cleverley jeff.cleverley@avagotech.com To: "Parisi, Justin" Justin.Parisi@netapp.com Cc: "Toasters@teaparty.net" Toasters@teaparty.net Subject: Re: Snapmirror relationships Message-ID: CAANBop0oKE6+mA4R81jMVbD1iVZDkjA2uE9Wrf8Eb+AixtvDeQ@mail.gmail.com Content-Type: text/plain; charset="utf-8"
Justin and Steve,
Thanks for the information about the shares and also the cifsconfig_share.cfg file. The location I primarily support does very little CIFS. The group I inherited uses a lot of CIFS. I'm having to get up to speed on some things.
The AD will be the same so that won't be a problem. I expected I would have to create shares since the FilerB volume names don't match the originals. I'll double check the security on both sides and make sure those are the same.
It seems this should work either way I do it, but things don't always work as I planned them :-)
Jeff
On Fri, Mar 27, 2015 at 2:22 PM, Parisi, Justin Justin.Parisi@netapp.com wrote:
If you want to retain the shares, copy the file in /vol/vol0/etc called cifsconfig_share.cfg.
That file basically runs commands at boot that creates the shares:
# cat cifsconfig_share.cfg
#Generated automatically by cifs commands
cifs shares -add "ETC$" "/etc" -comment "Remote Administration"
cifs access "ETC$" S-1-5-32-544 Full Control
cifs shares -add "HOME" "/vol/vol0/home" -comment "Default Share"
cifs access "HOME" S-NONE "nosd"
cifs shares -add "C$" "/" -comment "Remote Administration"
cifs access "C$" S-1-5-32-544 Full Control
cifs shares -add "CIFS" "/vol/cifs" -comment "CIFS"
cifs access "CIFS" S-NONE "nosd"
If you have shares in that file already on the destination filer, append the new shares.
If you want to load the shares without rebooting after you add the ones you want, use the source command.
parisi-7mode> source /vol/vol0/etc/cifsconfig_share.cfg
There is already a share named ETC$.
1 share(s) have been successfully modified
There is already a share named HOME.
1 share(s) have been successfully modified
There is already a share named C$.
1 share(s) have been successfully modified
There is already a share named CIFS.
1 share(s) have been successfully modified
Snapmirror is a block for block copy of files, which includes permissions/ACLs. If using the same domain, no issues.
From: <Klise>, Steve Steve.Klise@wwt.com Date: Friday, March 27, 2015 at 4:10 PM To: Jeff Cleverley jeff.cleverley@avagotech.com, "Toasters@teaparty.net" Toasters@teaparty.net Subject: RE: Snapmirror relationships
Not sure about the security on the volumes, but the NTFS perms should follow, as long as its in the same AD domain, but the shares won?t follow; you will have to recreate the shares. I would update the disk/shelf firmware prior personally.
*From:* toasters-bounces@teaparty.net [ mailto:toasters-bounces@teaparty.net toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Friday, March 27, 2015 12:55 PM *To:* Toasters@teaparty.net *Subject:* Snapmirror relationships
Greetings,
We have to split a cluster and one shelf will go to one site, and the rest go to another site. The single shelf (DS4243, 2 TB SATA) comprising 2 aggregates and 11 volumes will get moved to a different NetApp. The shelf will end up on a system with new names and no aliases can be used. There are some variable moving parts so I need a sanity check.
FilerA 7.3.7 - owner of the one shelf
FilerB 8.1.2P4 - soon to be owner of the one shelf
I've setup a snapmirror with a daily cron update that goes from FilerA to FilerB. This seems OK. If we can get the shelf owners to split the same day the other moves, I'm just going to move the shelf, change ownership, import the aggregate/volumes, create cifs shares, and update the snapvault relationship.
If they insist on moving before that, I have to break the mirrors after a final sync, rename the current snapmirror destination volumes, update snapvault relationships and create cifs shares. This seems OK.
Now the questions :-)
- Are there any issues associated with this process with the OS
differences or snapmirror not keeping filesystem security type, share, permissions, etc?
- If I have to split the shelf later, I want to add it to FilerB and
make that shelf the production shelf. This is a short term solution and the heads and shelves are not supported. Is there a graceful way to sync back to the DS4243 shelf? I don't want to disrupt the CIFS users very much.
- Any other glaring issues that stand out?
Thanks,
Jeff
--
Jeff Cleverley IT Engineer
4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
-- Jeff Cleverley IT Engineer 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611