|
|
| (170 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | The QuantaStor Users Guide focuses on how to configure your hosts to access storage volumes (iSCSI targets) in your QuantaStor storage system. The first couple sections cover how to configure your iSCSI initiator to login and access your volumes. The second section goes over how to configure your multi-path driver. | + | [[Category:user_guide]] |
| | + | The QuantaStor Users Guide focuses on how to configure your hosts (Linux, Windows, MacOS, VMware, XenServer, etc) to access file and block storage in your QuantaStor storage systems. |
| | | | |
| − | == iSCSI Initiator Configurations == | + | == User Guide Topics == |
| | | | |
| − | === Microsoft iSCSI initiator configuration for Windows 7 & Windows 2008 Server ===
| + | [[iSCSI Initiator Setup]] |
| − | Connecting to your QuantaStor (QS) storage system via the Microsoft iSCSI initiator is very simple. Before connecting though you'll need to add a 'Host' entry for your initiator.
| + | |
| − | To do so, login to QuantaStor Manager, select the 'Hosts' section and then choose 'Add Host' from the toolbar or right-click in the Hosts section and choose 'Add Host' from the pop-up menu. Next, enter the host name and the initiator IQN for your host.
| + | |
| − | The initiator IQN (iSCSI Qualified Name) is an identifier that uniquely identifies your host to the storage system. By default this name is generated for you so you'll need to go to your Windows system and run the iSCSI Initiator application to get the IQN. The initiator name will look something like this: 'iqn.1991-05.com.microsoft:yourhostname'.
| + | |
| − | <pre>
| + | |
| − | Note: The first part of the initiator name identifies the initiator vendor,
| + | |
| − | in this case "iqn.1991-05.com.microsoft", the second part is typically your
| + | |
| − | host name or the fully qualified domain name (FQDN) for the host
| + | |
| − | (ex: yourhostname.yourdomainname.com). All IQNs start with 'iqn.' and IQNs have various restrictions on what characters you can use. So if you modify the IQN try keeping your changes to the host name portion of the IQN and only use alpha-numeric characters.
| + | |
| − | </pre>
| + | |
| − | A software iSCSI initiator comes with Windows and you will find it under the 'Administrative Tools' section under the Windows Start menu. Once you have the 'iSCSI Initiator Properties' dialog loaded, choose the 'Configuration' tab and in there you'll see the 'Initiator Name:'. Copy & paste that IQN into the 'Add Hosts' dialog in QuantaStor Manager using the clipboard (Ctrl-C & Ctrl-V). Note that you must enter the IQN into the 'Add Hosts' dialog exactly as it is written in 'iSCSI Initiator Properties', if you make a typo then the host will not successfully login to the storage system.
| + | |
| − | Now that you have a host entry in QuantaStor for your Windows host, you can now assign storage to your Windows system and access it from your windows box. After you have assigned one or more storage volumes to the host, return to your Windows system and bring up the 'iSCSI Initiator' application again. On the first page under the 'Targets' tab, you can enter the IP address of your QuantaStor storage system in the box marked 'Target:' then press 'Quick Connect...'. After a moment you will see your storage volumes appear in the 'Discovered targets' section. When they appear simply select the storage volume you want to connect to, then press the 'Connect' button. Within a few seconds you'll be connected to the storage volume (iSCSI target). Unless this is a storage volume you've previously formatted and utilized, you'll need to use the Windows Disk Management screen to quick format the disk before you begin using it.
| + | |
| | | | |
| − | <!--
| + | [[Multipath IO Configuration]] |
| − | === Microsoft iSCSI initiator configuration for Windows XP ===
| + | |
| − | ''under development''
| + | |
| − | -->
| + | |
| | | | |
| − | === iSCSI initiator configuration for Apple Mac OS X ===
| + | [[NFS Configuration]] |
| | | | |
| − | We recommend using the ATTO Xtend SAN iSCSI initiator available [http://www.attotech.com/products/product.php?scat=17&sku=INIT-MAC0-001 here]. We do not recommend using the globalSAN initiator as we have seen problems with it in testing.
| + | [[VMware Configuration]] |
| | | | |
| − | Once you have the IQN for your OS/X system you'll need to add a host entry to QuantaStor using the QuantaStor manager web UI. Just press the 'Add Host' button and then enter the name of your system, and enter the IQN in the box that says 'IQN'. Now that you have a host added, you can assign volumes to your Mac. After you've assigned some storage, go back to the iSCSI initiator dialog in OS/X and enter the IP address of your QuantaStor system and you should immediately see all the storage volumes listed which you have assigned to the host. Note that you'll need to partition the disk after you connect to the iSCSI device / volume. We recommend that you use 'quick format' because a full format will end up reserving blocks in the storage system which defeats the purpose of using thin-provisioning which is the default when you 'Create Storage Volume'.
| + | [[XenServer Configuration]] |
| | | | |
| − | <!--
| + | [[VSA iSCSI Configuration]] |
| − | === Open iSCSI initiator configuration for Linux ===
| + | |
| − | -->
| + | |
| | | | |
| − | == Multipath Configuration ==
| + | [[FIPS Mode]] |
| − | QuantaStor supports round-robin style active/active multipathing using Microsoft's MPIO and via Linux using the device-mapper multipath (dmmp) driver. Active/active multipath support not only boosts performance, it also gives you the benefit of automatic path failover when a network connection is lost to one of your NICs on the host (initiator side) or the storage system (target side).
| + | |
| − | | + | |
| − | For Microsoft MPIO configuration you'll need to add the QuantaStor vendor / model information so that Microsoft's default DSM (device specific module) can detect QuantaStor volumes and automatically enable multipathing for them thereby combining multiple paths to your QuantaStor Storage System in a single device as seen in the Windows Disk Manager.
| + | |
| − | | + | |
| − | For Linux, you'll need to first install dmmp for your Linux distribution, and then modify the /etc/multipath.conf file to include an additional stanza so that the system properly identifies the QuantaStor devices and uses the correct multi-path device identification and path management rules.
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | Note: QuantaStor supports SCSI-3 Persistent Reservations so you can use it with Microsoft's Failover Clustering / Hyper-V and other cluster solutions that require SCSI-2 or SCSI-3 reservations.
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | === Configuring Microsoft MPIO ===
| + | |
| − | | + | |
| − | | + | |
| − | === Configuring Linux Device-Mapper Multipath (DMMP) ===
| + | |
| − | | + | |
| − | After you have device mapper installed on your Linux distribution, you'll need to login to your system as root and then add this section to your ''/etc/multipath.conf'' file:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | device {
| + | |
| − | vendor "OSNEXUS"
| + | |
| − | product "QUANTASTOR"
| + | |
| − | getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
| + | |
| − | path_grouping_policy multibus
| + | |
| − | failback immediate
| + | |
| − | path_selector "round-robin 0"
| + | |
| − | rr_weight uniform
| + | |
| − | rr_min_io 100
| + | |
| − | path_checker tur
| + | |
| − | }
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Once the file is updated you'll want to restart the multipath service like so:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | service multipathd restart
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Once you have it all configured and you're logging into the iSCSI target / storage volume with your iSCSI initiator you'll want to run 'multipath -l' to list the paths and you should see something like this:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | 14f534e455855530038323061623737393365306365643738dm-2 OSNEXUS,QUANTASTOR
| + | |
| − | [size=512M][features=0][hwhandler=0]
| + | |
| − | \_ round-robin 0 [prio=0][active]
| + | |
| − | \_ 120:0:0:0 sdg 8:96 [active][undef]
| + | |
| − | \_ 119:0:0:0 sdf 8:80 [active][undef]
| + | |
| − | 14f534e455855530038323061623737393735393231656332dm-1 OSNEXUS,QUANTASTOR
| + | |
| − | [size=4.0G][features=0][hwhandler=0]
| + | |
| − | \_ round-robin 0 [prio=0][active]
| + | |
| − | \_ 118:0:0:0 sde 8:64 [active][undef]
| + | |
| − | \_ 117:0:0:0 sdc 8:32 [active][undef]
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Remember, you'll need to make sure that you mount your filesystems using the correct unique device ID under ''/dev/mapper/'' so that the multipath driver is utilized. If you mount your filesystem from /dev/sdXX you'll have completely bypassed the multi-path driver and will not get the performance an fail-over capabilities.
| + | |
| − | | + | |
| − | == XenServer Configuration ==
| + | |
| − | === XenServer iSCSI Storage Repository Setup & Configuration ===
| + | |
| − | | + | |
| − | | + | |
| − | === XenServer NFS Storage Repository Setup & Configuration ===
| + | |
| − | | + | |
| − | | + | |
| − | === XenServer StorageLink Storage Repository Setup & Configuration ===
| + | |
| − | | + | |
| − | The following notes on StorageLink support only apply to XenServer version 6.x. Starting with version 2.7 QuantaStor now has an adapter to work with the StorageLink features that have been integrated with XenServer.
| + | |
| − | | + | |
| − | ==== Installing the QuantaStor Adapter for Citrix StorageLink ====
| + | |
| − | To install the adapter takes just a few simple steps.
| + | |
| − | First, get the files from the QuantaStor box. To do this you can use the command:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | wget -q --no-check-certificate https://192.168.0.142:8153/StorageLink/qssl-adapter.tgz
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Next, unpack the .tgz file returned by running the command:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | tar zxvf qssl-adapter.tgz
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | After the file is unpacked, cd into the directory.
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | cd QuantastorAdapter/
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Now you can run the installer file. This should copy the adapter files to the correct directories, along with patching a few minor changes to the StorageLink files. You can run the installer with the command:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | ./install-qs-cslg.sh
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | ==== QuantaStor Utility Script ====
| + | |
| − | The installer also comes with a file named qstorutil.py. This file can be executed with specific command line arguments to discover volumes, create storage repositories, and introduce preexisting volumes. The file is also copied to “/usr/bin/qstorutil.py” during the installation of the QuantaStor adapter for easier access.
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | The script has a help page with examples that can be accessed via:
| + | |
| − | qstorutil.py --help
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | While the script is the easiest way to create storage repositories or introduce volumes, the adapter will work just fine using the xe commands. We provide the qstorutil.py to make the configuration simpler due to the large number of somewhat complex arguments required by xe.
| + | |
| − | | + | |
| − | ==== Creating XenServer Storage Repositories (Srs) ====
| + | |
| − | The easiest way to create a XenServer storage repository is to use the QuantaStor utility script. To do this you can run either of the commands below:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | qstorutil.py --create_sr -a <quantastor-ip-address> -u admin -p password --spid <quantastor-storage-pool-uuid> -n <sr-name>
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | qstorutil.py --create_sr -a <quantastor-ip-address> -u admin -p password --sp_name <quantastor-storage-pool-name> -n <sr-name>
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Both of these commands will create a storage repository. One takes the QuantaStor spid where as the other takes the QuantaStor storage pool name (and uses it to figure out the spid). When you create a storage repository, a small metadata volume is created. The metadata volume name with have the prefix “SL_XenStorage__” and then a guid.
| + | |
| − | | + | |
| − | ==== Storage Volume Discovery ====
| + | |
| − | Storage volume discovery will show you a list of all the volumes on the QuantaStor box specified (via ip address). The list will specify the name of the volume, the QuantaStor id of the volume, the StorageLink id of the volume, the storage system name, and the storage system id. If the volume is in a storage repository on the local XenServer system it will also have three additional fields. These fields are the VDI name, the VDI uuid, and the storage repository uuid.
| + | |
| − | | + | |
| − | In addition to listing all of the volumes, the discover command will also print out the storage repositories on the local XenServer system. The fields listed are the storage repository name, and the storage repository uuid.
| + | |
| − | | + | |
| − | To call the discovery command you can use the command below:
| + | |
| − | <pre>
| + | |
| − | qstorutil.py --discover -a <quantastor-ip-address> -u admin -p password
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | ==== Introducing a Preexisting Volume to XenServer ====
| + | |
| − | To introduce a preexisting volume to XenServer you should first run the storage volume discovery command. To introduce a volume run one of the three commands below:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | qstorutil.py --vdi_introduce -a <quantastor-ip-address> -u admin -p password --vol_uuid <quantastor-volume-uuid> --sr_uuid <storage-repository-uuid> -n <vol-name>
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | qstorutil.py --vdi_introduce -a <quantastor-ip-address> -u admin -p password --svid <storagelink-volume-id> --sr_uuid <storage-repository-uuid> -n <vol-name>
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | qstorutil.py --vdi_introduce --svid <storagelink-volume-id> --vol_uuid <quantastor-volume-uuid> --sr_uuid <storage-repository-uuid> -n <vol-name>
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Each of these commands do the exact same thing, they just require slightly different parameters. Use whichever command works best for you. The reason for running the discover command before introducing a volume is that the volume vol_uuid, svid, and sr_uuid are all provided in the discover.
| + | |
| − | | + | |
| − | === Creating XenServer Storage Repositories (SRs) ===
| + | |
| − | | + | |
| − | Generally speaking, there are three types of XenServer storage repositories (SRs) you can use with QuantaStor.
| + | |
| − | | + | |
| − | * iSCSI Software SR
| + | |
| − | * StorageLink SR
| + | |
| − | * NFS SR
| + | |
| − | | + | |
| − | The 'iSCSI Software SR' which allows you to assign a single QuantaStor storage volume to XenServer and then XenServer will create multiple virtual disks (VDIs) within that one storage volume/LUN. This route is easy to setup but it has some drawbacks:
| + | |
| − | | + | |
| − | '''iSCSI Software SR'''
| + | |
| − | *Pros:
| + | |
| − | ** Easy to setup
| + | |
| − | *Cons:
| + | |
| − | ** The disk is formatted and laid out using LVM so the disk cannot be easily accessed outside of XenServer
| + | |
| − | ** The custom LVM disk layout makes it so that you cannot easily migrate the VM to a physical machine or other hypervisors like Hyper-V & VMWare.
| + | |
| − | ** No native XenServer support for hardware snapshots & cloning of VMs
| + | |
| − | ** Potential for spindle contention problems which reduces performance when the system is under high load.
| + | |
| − | ** Within QuantaStor manager you only see a single volume so you cannot setup custom snapshot schedules per VM and cannot roll-back a single VM from snapshot.
| + | |
| − | | + | |
| − | The second and most preferred route is to create your VMs using a Citrix StorageLink SR. With StorageLink there is a one-to-one mapping of a QuantaStor ''storage volume'' to each virtual disk (VDI) seen by each XenServer virtual machine.
| + | |
| − | | + | |
| − | '''Citrix StorageLink SR'''
| + | |
| − | *Pros:
| + | |
| − | ** Each VM is on a separate LUN(s)/storage volume(s) so you can setup custom snapshot policies
| + | |
| − | ** Leverage hardware snapshots and cloning to rapidly deploy large numbers of VMs
| + | |
| − | ** Enables migration of VMs between XenServer and Hyper-V using Citrix StorageLink
| + | |
| − | ** Enables one to setup custom off-host backup policies and scripts for each individual VM
| + | |
| − | ** Easier migration of VMs between XenServer resource pools
| + | |
| − | ** VM Disaster Recovery support via StorageLink (requires QuantaStor Platinum Edition)
| + | |
| − | *Cons:
| + | |
| − | ** Requires a Windows host or VM to run StorageLink on.
| + | |
| − | ** Some additional licensing costs to run Citrix Essentials depending on your configuration.
| + | |
| − | *** (A free version exists which supports 1 storage system)
| + | |
| − | | + | |
| − | With the next version of Citrix StorageLink we'll be directly integrated so it will be just as easy to get going using the StorageLink SR if not easier as it will do all the array side configuration for you automatically.
| + | |
| − | | + | |
| − | ==== Creating a XenServer Software iSCSI SR ====
| + | |
| − | | + | |
| − | Now that we've discussed the pros/cons, let's get down to creating a new SR. We'll start with the traditional "one big LUN" ''iSCSI Software SR''. The name is perhaps a little misleading, but it's called a 'Software' SR because Citrix is trying to make clear that the iSCSI software initiator is utilized to connect to your storage hardware. Here's a summary of the steps you'll need to take within the QuantaStor Manager web interface before you create the SR.
| + | |
| − | | + | |
| − | * Login to QuantaStor Manager
| + | |
| − | * Create a ''storage volume'' that is large enough to fit all the VMs you're going to create.
| + | |
| − | ** Note: If you use a large thin-provisioned volume that will give you the greatest flexibility.
| + | |
| − | * Add a ''host'' for each node in your XenServer resource pool
| + | |
| − | ** Note: You'll want to identify each XenServer host by it's IQN. See the troubleshooting section for a picture of XenCenter showing a server's initiator IQN.
| + | |
| − | * (optional) Create a ''host group'' that combines all the Hosts
| + | |
| − | * Assign the ''storage volume'' to the ''host group''
| + | |
| − | | + | |
| − | Alternatively you can assign the storage to each host individually but you'll save a lot of time by assigning it to a host group and it makes it easier to create more SRs down the road.
| + | |
| − | | + | |
| − | After you have the storage volume created and assigned to your XenServer hosts, you can now create the SR.
| + | |
| − | | + | |
| − | [[File:xencenter_iscsisr.png|640px|Citrix XenCenter iSCSI SR]]
| + | |
| − | | + | |
| − | This picture shows the iSCSI Software SR type selected.
| + | |
| − | | + | |
| − | | + | |
| − | [[File:xencenter_iscsisr_part2.png|640px|Citrix XenCenter iSCSI SR]]
| + | |
| − | | + | |
| − | This screen captures the main page of the wizard. Enter the IP address of the QuantaStor storage system and then press the Discover Targets and Discover LUNs button to find the available devices. Once selected, press OK to complete the mapping.
| + | |
| − | | + | |
| − | ===== Optimal XenServer iSCSI timeout settings =====
| + | |
| − | | + | |
| − | Since the virtual machines on the XenServer will be using the iSCSI SR for their boot device, it is important to change the timeout intervals so that the iSCSI layer has several chances to try to re-establish a session and so that commands are not quickly requeued to the SCSI layer. This is especially important in environments with potential for high latency.
| + | |
| − | | + | |
| − | Per the README from open-iSCSI, we recommend the following settings in the iscsid.conf file for a XenServer.
| + | |
| − | | + | |
| − | *Turn off iSCSI pings by setting:
| + | |
| − | *:node.conn[0].timeo.noop_out_interval = 0
| + | |
| − | *:node.conn[0].timeo.noop_out_timeout = 0
| + | |
| − | | + | |
| − | *Set the replacement_timer to a very long value:
| + | |
| − | *:node.session.timeo.replacement_timeout = 86400
| + | |
| − | | + | |
| − | ==== Creating a XenServer StorageLink SR (LUN per VDI) ====
| + | |
| − | | + | |
| − | Once you have the StorageLink adapter software installed as outlined above, you can quickly create new SRs using the StorageLink Manager UI. StorageLink SRs map one-to-one with a QuantaStor Storage Pool. So when you create the SR you'll indicate which pool you want your storage volumes created in for that SR and as new VMs are created with that SR StorageLink will automatically provision the storage volumes for you and deploy them into your XenServer environment. To get started first you'll need to login to Citrix StorageLink Manager and tell it about your storage system.
| + | |
| − | You'll do this by selecting the "Administration" section, then select "OS NEXUS QuantaStor" from the list vendor modules, then right-click and choose "Add Credentials". You'll see this dialog:
| + | |
| − | | + | |
| − | [[File:storagelink_addcred.png|480px|Citrix StorageLink Add Credentials]]
| + | |
| − | | + | |
| − | In here you need to tell StorageLink the IP address of your QuantaStor storage system and the username/password to login so that it can dynamically configure the storage system for you. If you have multiple teams using a common QuantaStor storage system, you might want to first setup some QuantaStor ''storage clouds'' so that you can securely separate the resources between the teams. That way each team will only see their devices within their StorageLink/XenServer deployment, and you can place quotas on them.
| + | |
| − | | + | |
| − | Next you'll want to look at the ''Storage Infrastructure'' tree inside Citrix StorageLink Manager to make sure your QuantaStor hardware has been properly detected. If you see it there, you're all set, just click the "Create Storage Repository" button in the Action pane on the right hand side of the Citrix StorageLink Manager window and follow the wizard.
| + | |
| − | | + | |
| − | === Troubleshooting StorageLink ===
| + | |
| − | | + | |
| − | If you run into problems we recommend that you create a traditional iSCSI SR to verify connectivity to the array before you start allocating LUNs via a StorageLink SR. To do that, first you'll need to allocate a storage volume using the QuantaStor Manager, then you'll need to assign it to all the nodes in your XenServer resource pool. To summarize:
| + | |
| − | * Login to QuantaStor Manager
| + | |
| − | * Create a ''storage volume''
| + | |
| − | * Add a ''host'' for each node in your XenServer resource pool
| + | |
| − | * (optional) Create a ''host group'' that combines all the Hosts
| + | |
| − | * Assign the ''storage volume'' to the ''host group''
| + | |
| − | | + | |
| − | Note that when you add the hosts using the 'Add Host' dialog in QuantaStor Manager you'll want to enter the XenServer host's initiator IQN and that can be found using XenCenter as shown in this picture.
| + | |
| − | | + | |
| − | [[File:xencenter_iqn.png|640px|Citrix XenCenter IQN Configuration]] | + | |
| − | | + | |
| − | At this point you can create the iSCSI SR by pointing it to the QuantaStor storage system and your storage volume will appear. The great thing about this method is that you can use it to verify that StorageLink is properly identifying your storage volumes using the device identification rules you added to the scsi_device_id_config.xml file.
| + | |
| − | | + | |
| − | Next we're going to verify that your iSCSI LUN is being properly identified by the internal StorageLink tools on your XenServer host. To do this, first you'll need to go to the console window of your XenServer dom0 and then issue the following commands
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | cd /opt/Citrix/StorageLink/bin
| + | |
| − | ./csl_devscan --native
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | This is going to print out a list of all the SCSI devices that are visible to the system and their StorageLink identifiers. In that list that is printed you should see a StorageLink storage volume identifiers (SVIDs) for all your SCSI disks and you should see at least one that looks something like this:
| + | |
| − | <pre>
| + | |
| − | OSNEXUS__QUANTASTOR__820ab779__b8b2c67f
| + | |
| − | </pre>
| + | |
| − | This identifier shows the vendor and model of the hardware (OSNEXUS / QUANTASTOR) and the two hex numbers '''820ab779''' and '''b8b2c67f''' at the end uniquely identify the storage system and the storage volume respectively. If you don't see any OSNEXUS devices listed, then XenServer has not yet logged into the storage system.
| + | |
| − | If you see a OSNEXUS QUANTASTOR device and it is followed by a very long number (typically starting with 0080 and 0083) then the XenServer host is not properly identifying the devices using the rules you added to the ''scsi_device_id_config.xml'' file. The way to fix this is to manually edit the local ''scsi_device_id_config.xml'' device configuration file at the dom0 console window:
| + | |
| − | <pre>
| + | |
| − | nano /opt/Citrix/StorageLink/bin/scsi_device_id_config.xml
| + | |
| − | </pre>
| + | |
| − | Once you're in the text editor you'll need to copy and paste in this XML block that was noted above which you added to the scsi_device_id_config.xml on Windows.
| + | |
| − | <pre>
| + | |
| − | <ScsiDeviceIDProcessor>
| + | |
| − | <InquiryMatch>
| + | |
| − | <Vendor>OSNEXUS</Vendor>
| + | |
| − | <Product>QUANTASTOR</Product>
| + | |
| − | </InquiryMatch>
| + | |
| − | <VendorID value="OSNEXUS" />
| + | |
| − | <ProductID value="QUANTASTOR" />
| + | |
| − | <EnclosureID page="131" offset="16" length="8" />
| + | |
| − | <DeviceID page="131" offset="24" length="16" />
| + | |
| − | </ScsiDeviceIDProcessor>
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Note that the enclosure ID / device ID settings above have changed. The old v1.4 and earlier versions of QuantaStor used these settings for the enclosure/device ID:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | <EnclosureID page="128" offset="4" length="8" />
| + | |
| − | <DeviceID page="128" offset="12" length="8" />
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | | + | |
| − | StorageLink's auto-upgrade process generally updates this configuration file for you so you shouldn't have to do this step but there may be some corner cases where the auto-upgrade isn't triggered. Once you have the scsi_device_id_config.xml file updated you'll want to re run the ''csl_devscan'' command again you should now see the storage volume ID (SVID) properly identified as shown in the example above. (''OSNEXUS__QUANTASTOR__820ab779__b8b2c67f'').
| + | |
| − | At this point go ahead and create a StorageLink SR for XenServer using the Citrix StorageLink Manager GUI and try creating a new virtual machine to test it out.
| + | |
The QuantaStor Users Guide focuses on how to configure your hosts (Linux, Windows, MacOS, VMware, XenServer, etc) to access file and block storage in your QuantaStor storage systems.
