With my ISCSI Target configured on FreeNAS and my Solaris 11 Global Zone installed, it's time to configure the ISCSI initiator to discover the ISCSI target using the second NIC in my Solaris 11 host (or "Global Zone").
In my lab environment, I have created one big volume called "ONEBIGVOLUME" on my FreeNAS, consisting of 4 x 7500 RPM SATA Disks. Within this single volume, I have created 5 x 250GB ZVols from which I've then created 5 x iSCSI device extents for my Solaris 11 host to discover. I'll then create a single ZPool on my Solaris host, using these 5 iSCSI extents on FreeNAS as if they were local disks.
First I need to configure the 2nd NIC that I intend to use for iSCSI traffic on my network. I'll refer to my own post here to assist me in configuring that 2nd NIC.
The screen shot below shows the process end-to-end.
The oracle document here describes the process of enabling iSCSI.
I noticed that the subnet mask was incorrect on my 2nd NIC. My fault for not specifying it, the OS assumed a 8 bit instead of a 24 bit mask for my 10.0.0.0 network. I've included the steps taken to fix that below.
Note the commands highlighted below, that were not accepted by the OS and how I ultimately fixed it below.
Here, I use dynamic discovery to find all disks on the FreeNAS iSCSI target, using just the IP Address.
This is probably the simplest way of discovering the disks, but also dangerous as there may be another disk amongst the list that is being used by another system (in my case, I have a VMWare DataStore too).
So, I definitely do not want to use this disk on the Solaris system as it's already in use elsewhere by VMWare here. This is why it's a good idea to use static discovery and/or authentication!
On my Solaris host, I can go back and remove the FreeNas discovery address and start over using Static Discovery instead.
I know the IP Address, port, base name and target name of my FreeNAS where my iSCSI extents are waiting to be discovered so I may as well use static discovery.
It's a bad idea to use both static discovery and dynamic discovery simultaneously.
With static discovery set, I can now re-add the discovery address, not forgetting the port (like I just did, above).
You can see now, that by using Static discovery to only discover extents available at the "iqn.2005-10.org.freenas.ctl:solariszp1" target at 10.0.0.50 on port 3260, my Solaris 11 host has only discovered the 5 devices (extents) I have in mind for my ZPool, and the VMWare DataStore has not been discovered.
The format command is a convenient way to list the device names for your "disks" but you don't need to use format to do anything else to them. So CTRL-C to exit format.
I can use my notes here to help with configuring ZPools and ZFS.
Since my FreeNAS uses ZFS itself to turn 4 x Physical 2TB SATA disks into it's 7TB "ONEBIGVOLUME" that is subsequently carved up into a 1TB VMWare DataStore and my 5 x 250GB Solaris 11 ZPool1 volumes, the RAIDZ resilience to physical drive failure is set at the NAS level, and need not be used when configuring the ZPool from the 5 iSCSI extents. I could have created a single 1TB iSCSI extent and created my ZPool on the Solaris host with just one disk.
I could have created a single 1TB iSCSI extent and created my ZPool on the Solaris host from just the one "disk", since the RAIDZ resilience to physical disk failure exists on the FreeNAS. By creating 5, at least I have the option of creating my ZPool with RAIDZ on the Solaris host in my lab also.
Here you can see the system warning about the lack of RAIDZ redundancy in my new pool. If the disks were physical, it'd be a risk but in my lab environment, it's not a problem.
Although FreeNAS defaults to compression being turned on when you create a new volume in a pool, I created each of my 5 volumes used as iscsi extents here with compression disabled. This is because I intend to use the compression and deduplication options when creating the ZFS file systems that will be hosting my Solaris Zones on my Solaris 11 host instead.
I have a separate post here on Administering Solaris 11 Zones with the requisite commands but will post screenshots here from my own lab.
This is really where the post ends within the context of connecting Solaris 11 to iSCSI storage.
So that's the process end-to-end of discovering iSCSI SAN storage through logging into your new Solaris11 Zone.
This concise post aims to cover the basics of ZFS administration on Solaris. Excuse the brevity, it is for reference rather than a detailed explanation.
You can copy files to this zfs filesystem that has gzip compression enabled and save nearly half your disk space.
By copying multiple instances of the same file into /labpool/archive/a, b, c and d whereby the /labpool/archive filesystem has deduplication turned on, you'll see that zpool list labpool will increment the value in the DEDUP column to reflect the deduplication ratio as more and more similar files are added.
Note also that compression is enabled at the zfs file system level but copying an already gzipped file will not result in further gains – the value returned by zfs get compressratio labpool/archive stays at 1.00x.
Snapshots can be created that copy-on-write (or any other kind of IO) such that changes made can be rolled back. As a result, snapshots don't take up a lot of space, unless left in place for filesystems with high IO of course.
zfs list -r -t all labpool will show all the zfs filesystems including snapshots and clones. Changes can be made to the clone filesystem without affecting the original.
In Windows, plug in cable, search for Device Manager, then click on "Update Driver" on any Serial port items that show warnings. The internet found and installed working drivers for me.
Log on to the switch as admin and refer to the screenshot below to disable DHCP and configure a static IP address.
Next ping the new IP address, and attempt to connect using a web browser.
Log in using the same admin and password as with the console.
Log in to the Control Station as root.
Note: /sbin/ifconfig -a revealed eth3 to be my cs0 interface.
This changes the immediate configuration, but does not persist across restarts.
Look for lines with the old IP address.
Replace the old IP address with your new IP address.
If you are changing the Control Station IP address, but remaining on the same network, then the SP IP addresses for an integrated model need not be modified. However, if you are changing to a different network, the SP IP addresses must be modified to be on the same physical network as the Control Station for the Integrated model. Use the clariion_mgmt -modify -network command to update the IP addresses on the SP, as it will also update the files and Celerra database with the modified IP addresses.
Edit the network configuration file, /etc/sysconfig/network-scripts/ifcfg-eth3, by using a text editor.
To enable NFSv4 on your up-to-date (post VNX OE for File v7.1) VNX Unified storage system and configure a datamover to mount a filesystem to allow for NFSv4 access with a MIXED access policy, the following steps serve as a concise guide. NFSv4 cannot be done via Unisphere.
Log onto control station as nasadmin user via SSH using PuTTY.
It's highly likely that if you require NFS v4, then you'll also need to authenticate access, using a UNIX based Kerberos DC. The following notes cover the configuration steps involved. Please note that this section below is still a work in progress and you should refer to the official EMC documentation for a complete set of instructions with examples.
Note server_2 is set already during VNX installation.
Copy /.etc/krb.keytab file (if it exists) to the Kerberos KDC.
Copy the krb5.keytab file from Kerberos KDC to the Data Mover by using FTP and the server_file command.
Most things VNX can be exported using Unisphere's little export icon in the top right hand corner of most if not all dialogs. Disk information would be found under System, Hardware, Disks. You'll see there is a part number column, but no serial number column in Unisphere for the disks.
If a security file containing the credentials is already present on the storage management server, then you won't need to specify the username and password in plain text as shown above.
Step 1 Use the show user-accounts command to verify that your user name has network-admin privileges.
Step 2 If your user name has network-admin privileges, issue the username command to assign a new administrator password.
Step 3 Save the software configuration.