I would like to know what is the procedure to migrate a vfiler from default IPspace to a new one.
This is the procedure as i see it
As far as i know, it is neccessary to remove every IP address from an ethernet adapter so that you can remove that adapter from default ipsapce.
The second thing to know is that you just can assign a vfliler to a ipspace at creation time.
The third thing is that if you want tlo use an older /etc from another vfiler when creating a new vfiler, then you cannot specify the IPspace
Then if i'm currently working with a vfiler running into default ipspace, the steps to follow are:
1) vfiler stop
2) vfiler destroy
3) remove ipaddress from ethernet adapter to remove from defaulIPspace
4) create the new IPspace
5) create the new vfiler over the new vfiler
6) copy some /etc/files ( but .... what files? )
In this procedure my doubts are
a) can i preserve the older vfiler ( do i have to destroy it ? )
b) what are the files to be copied from the original /etc ?
A new doubt arises related to the new IPspaces management.
into default IPspace there is just one routing table for the whole vfilers running into it ( vfiler0 and the rest of vfilers )
if a vfiler is runnig into a new IPspace i must to create new routes starting from a new default route.
Do i have to create a default route for every vfiler into each IPspace?
Good questions. To start at the end, if you have 2 vFilers in the same IPspace, then you can only have 1 default route. So, if you have "vfiler run vfilername route add default" for the 1st vFiler in /etc/rc of vfiler0, then you can't add a default for the 2cnd vFiler since there is only 1 default gateway per ipspace. However, you may need to add "vfiler run vfilername route add net/host" if you need net or hosts routes if the vFiler needs separate routing on different networks. You may also need to add net/host routes if a single vFiler has multiple subnets.
You are correct below that you need to destroy the vFiler and create it from scratch. Unfortunately, there is no way to change the IPspace of an existing vFiler.
Copying /etc files typically includes hosts, host.equiv, exports, resolv.conf, nsswitch.conf, cifs__nbalias.cfg, usermap.cfg, quotas, cifs_homedir.cfg (and make sure to renable quotas, cifs homedir load, cifs nbalias load, etc.), but you also will need to re-enter all options. So, I would backup the entire etc directory, the output of all options and also cifs shares for the vfiler. You can copy files to keep the cifs settings, but I would setup cifs manually since copying the files can sometimes be unpredictable. I have a list of files I have copied to get cifs moved between vFilers without having to re-run setup but won't post them since it's unsupported (but email me privately and I can send it to you, but without any support and at your own risk). Manually you will need to recreate all cifs shares, but you can copy that config file and it usually works with some entries missing...but my method of copying specific cifs files (including kerberos key tab) works but again, if you can reset manually I would do that unless you have a significant number of shares.
Some other considerations when you destroy and recreate from scratch.. the iscsi node name (iqn)...take note of that prior to destroying so you can reset it to what it was before so hosts don't have to be reset (assuming iscsi is in use).
Also, after step 4 below, ipspace assign the interface you removed the ip from in step 3... Document all settings in the vFiler prior to destroying it...recreating it will recreate /etc again and you won't have those settings anymore. I would copy off etc, list all options (mentioned above but again since you really want to do that), check iscsi nodename, cifs shares, nfs exports and everything else already mentioned...also create a snapshot of the root volume prior to this... then worst case you can recreate the vfiler from a flexclone of that snapshot... using vfiler create -r to recreate to the old settings but in the original ipspace..but will give you some flexibility if you need to revert back.
Let us know how it goes...and test out on a test vfiler or in the simulator to give yourself some comfort level with recreating all settings. You may find you don't have quotas or the other things mentioned which will make it more simple to recreate.
We are not using block access so we can reduce the migration stuff to cifs and nfs issues.
So we will have to focus on /etc/files for these two protocols.
I would like to work with simulators but the real thing is that simulator work always ok, the problem arises at real machines.
To be honest, in my simulator i cannot check things like what's going with the CIFS registration in customer's Active Directory?
by the way, another question has just arised me.
If you issue a vfiler status -r vfilerxx you can see an UUID like this:
NAS500MAJA01> vfiler status -r DESA01
IP address: 10.255.221.223 [vif_desa_01]
Path: /vol/vol0/DESA01 [/etc]
Will this UUID used in the Active Directory registration? ... in other words, will i have to re-register again the vfiler into the AD.
Or in the other side, are there any files than can be copied from the original /etc to avoid this new AD registration?
Fortunately i have a vif not yet in use, so i will make tests with this environment in the real AD
Thanks again for your answer
You could setup a simulator interface as bridged to get out to the network, but I wouldn't do this at a customer...only in your lab for testing. But that would allow you to join a domain, or setup another VM with AD running to join local on the same VMnet as the sim.
For the UUID, you can still rejoin the domain using the same name as before without concern of the uuid. Then recreate the cifs shares as they were before. For support, you will need to join the domain and recreate all shares, quotas, etc.
If you want to veer away from a supported method (this is not supported and is at your own risk).... you could take these files (with cifs terminated) then copy to the new vfiler then "cifs restart" and go from there...The only time I have done this is when there is an issue with user domain credentials (for example, it was a Sunday at 4AM and the admin had rights to rejoin vfiler0 under a new netbios name, but did not have rights to reuse the prior name of vfiler0 when trying to rejoin the vfiler using the old vfiler0 netbios name)... a brute force method, but good to use for your test environment to see what files are used for domain and shares. Specific to domain membership I have been able to get around rejoining a domain with these files (but again, no support)...
Well i finally achieved the migration with sucess.
I just rejoined the vfiler using the old register in the AD and then copied the usermap cifs_shares and exports.
Everything was ok but in the following day, one of the vfilers could not log in any domain controller. I realized that the vfiler has no default route. There was another vfiler in the same ipspace running with the default route and according to your previous post i did not see neccessary to setup it.
Anyway it did not solve the problem.
cifs resetdc neither
and cifs terminate / restsart neither
I had to run cifs setup again using the old entry and everything was fine again ... and so far ....
thanks for your help again
I'm reading up on ipspaces -
assign ipspacename interface-list
Assigns the named interface(s) to the named ipspace. The named interface(s) must not be configured with any addresses. Trunked interfaces and base VLAN interfaces cannot have their ipspace reassigned. All interfaces start off by being in the default-ipspace.
Does this imply ipspaces must have dedicated physical interfaces? We only have 2 x 10g (e1b, e2b) interfaces and use a single mode interface group for redundancy.
How would you configure this with multiple ipspaces sharing the same 2 physical nics?
Thanks - I worked that out just now.
So I have migrated a vfiler (destroyed it, and created it in v205 with the original volume and the exports file restored) from the default-ipspace to the v205 space where vlan 205 is defined.
Now, I need to assign an IP to the default-ipspace so I can administer this head so does this need to be a unique vlan?
Or can the same vlan exist in multiple ipspaces?
cci-na01> ipspace list
Number of ipspaces configured: 2
default-ipspace (e0a e0b e1a e2a e3a e3b e0M losk cci01-vif0)
I chose a new vlan for the default-ipspace.
Now I am vetting my new "ipspace-ified" /etc/rc file
Previously each vfiler used to have an /etc/rc line
"ifconfig <interface> alias <vfilerIPaddress..."
What is the ipspace-ified version (since the command I used to assign IP was during the vfiler create stage - but obviously the create is a one time operation so not appropriate for the /etc/rc file)
Or are these ifconfig alias cmds no longer required with ipspaces?
Vfilers don't have an rc file so all ifconfig must be in rc of vFiler0. It can be am ifconfig of the interface or an alias. However an alias is to an existing configured interface which would be the same Ipspace for all aliases and the ip set on the original interface.
Sent from my iPhone 5
So I used the command line vfiler create <vfilername> -s <ipspace> -i ipaddress <path>
then was PROMPTED for additional settings like netmask etc.
What /etc/rc form do those PROMPTED variables take?
If I used System Manager instead of the command line, would it write those /etc/rc lines for me?