The Host Server. Citrix XenServer Configuration Guide. May The authority on real-time data

Transcription

1 The Host Server Citrix XenServer Configuration Guide May 2018 This guide provides configuration settings and considerations for Hosts running XenServer with SANsymphony. Basic XenServer storage administration skills are assumed including how to connect to iscsi and Fibre Channel target ports and the discovering, mounting and formatting of disk devices. The authority on real-time data

2 Table of contents Changes made to this document 3 Citrix XenServer compatibility lists 4 Citrix XenServer operating system versions SCSI UNMAP support 4 5 Qualified vs. Not Qualified vs. Not Supported 6 The DataCore Server's settings 7 Operating System Type 7 Port roles 7 Multipathing 7 ALUA support 7 Serving Virtual Disks 7 The XenServer Host's settings 9 XenServer 7.x Multipath Configuration 9 XenServer 6.x Multipath Configuration 11 Known issues 13 Hardware 13 General 13 Hotfixes 14 Appendix A 15 Preferred Server & Preferred Path settings 15 Appendix B 17 Reclaiming storage from Disk Pools 17 Previous changes 19

3 Citrix XenServer compatibility lists Changes made to this document The most recent version of this document is available from here: All changes since February 2018 Updated XenServer compatibility list SANsymphony is now supported for all 7.x Citrix versions. For previous changes made to this document please see page 19 Page 3

4 Citrix XenServer compatibility lists Citrix XenServer operating system versions SANsymphony 9.0 PSP 4 Update 4 (1) SANsymphony 10.0 (all versions) XENSERVER WITH ALUA WITHOUT ALUA WITH ALUA WITHOUT ALUA 6.0 or earlier Not Supported Not Supported Not Supported Not Supported 6.1 Qualified (2) Qualified Not Qualified Not Qualified 6.2 Not Qualified Not Qualified Not Qualified Not Qualified 6.5 Not Qualified Not Qualified Qualified (2) Qualified 7.x Not Supported Not Supported Qualified Qualified Notes: Qualified vs. Not Qualified vs. Not Supported See the next page for definitions. DataCore Server Port connections Both Fibre Channel and iscsi Front-End connections are supported. 1 Earlier versions are End of Life. See: 2 ISCSI Front End connections only. Fibre channel is Not Supported. Page 4

5 Citrix XenServer compatibility lists SCSI UNMAP support SANsymphony 9.0 PSP 4 Update 4 (1) SANsymphony 10.0 PSP 6 or greater XENSERVER WITH ALUA WITH ALUA 6.2 or earlier No UNMAP support No UNMAP support 6.5 Does not Work Tested/Works 7.x Does not Work Tested/Works Notes: SANsymphony 10.0 PSP 6 or greater only Earlier versions of SANsymphony 10.x will ignore UNMAP requests. 1 Earlier versions are End of Life. See: Page 5

6 Citrix XenServer compatibility lists Qualified vs. Not Qualified vs. Not Supported Qualified This combination has been tested by DataCore and all the host-specific settings listed in this document applied using non-mirrored, mirrored and Dual Virtual Disks. Not Qualified This combination has not yet been tested by DataCore using Mirrored or Dual Virtual Disks types. DataCore cannot guarantee 'high availability' (failover/failback, continued access etc.) even if the host-specific settings listed in this document are applied. Self-qualification may be possible please see Technical Support FAQ #1506 Mirrored or Dual Virtual Disks types are configured at the users own risk; however, any problems that are encountered while using XenServer versions that are 'Not Qualified' will still get root-cause analysis. Non-mirrored Virtual Disks are always considered 'Qualified' - even for 'Not Qualified' combinations of XenServer/SANsymphony. Not Supported This combination has either failed 'high availability' testing by DataCore using Mirrored or Dual Virtual Disks types; or the operating System's own requirements/limitations (e.g. age, specific hardware requirements) make it impractical to test. DataCore will not guarantee 'high availability' (failover/failback, continued access etc.) if the host-specific settings listed in this document are applied. Mirrored or Dual Virtual Disks types are configured at the users own risk. Self-qualification is not possible. Mirrored or Dual Virtual Disks types are configured at the users own risk; however, any problems that are encountered while using XenServer versions that are 'Not Supported' will get best-effort Technical Support (e.g. to get access to Virtual Disks) but no root-cause analysis will be done. Non-mirrored Virtual Disks are always considered 'Qualified' even for 'Not Supported' combinations of XenServer/SANsymphony. Citrix XenServer versions that are End of Support Life Self-qualification may be possible for versions that are considered Not Qualified by DataCore but only if there is an agreed support contract with Citrix. Please contact DataCore Technical Support before attempting any self-qualification of For any problems that are encountered while using XenServer versions that are EOSL with DataCore Software, only best-effort Technical Support will be performed (e.g. to get access to Virtual Disks). Root-cause analysis will not be done. Non-mirrored Virtual Disks are always considered 'Qualified'. Page 6

7 The DataCore Server's settings Operating System Type When registering the Host for the first time, choose the 'Citrix XenServer' menu option. Port roles Ports used for serving Virtual Disks to Hosts should only have the Front End (FE) role enabled. Mixing other Port Role types may cause unexpected results as Ports that only have the FE role enabled will be turned off when the DataCore Server software is stopped (even if the physical server remains running). This helps to guarantee that any Hosts do not still try to access FE Ports, for any reason, once the DataCore Software is stopped but where the DataCore Server remains running. Any Port with the Mirror and/or Back End role enabled do not shut off when the DataCore Server software is stopped but still remain active. Multipathing The Multipathing Support option should be enabled so that Mirrored Virtual Disks or Dual Virtual Disks can be served to Hosts from all available DataCore FE ports. Also see the Multipathing Support section from the SANsymphony Help: WebHelp/Hosts.htm Non-mirrored Virtual Disks and Multipathing Non-mirrored Virtual Disks can still be served to multiple Hosts and/or multiple Host Ports from one or more DataCore Server FE Ports if required; in this case the Host can use its own multipathing software to manage the multiple Host paths to the Single Virtual Disk as if it was a Mirrored or Dual Virtual Disk. ALUA support Please refer to your distribution s Compatibility Lists on page 4. Serving Virtual Disks For the first time DataCore recommends that before serving Virtual Disks for the first time to a Host, that all DataCore Front-End ports on all DataCore Servers are correctly discovered by the Host first. Then, from within the SANsymphony Console, the Virtual Disk is marked Online, up to date and that the storage sources have a host access status of Read/Write. To more than one Host port DataCore Virtual Disks always have their own unique Network Address Authority (NAA) identifier that a Host can use to manage the same Virtual Disk being served to multiple Ports on the same Host Server and the same Virtual Disk being served to multiple Hosts. While DataCore cannot guarantee that a disk device's NAA is used by a Host's operating system to identify a disk device served to it over different paths generally we have found that Page 7

8 The DataCore Server's settings it is. And while there is sometimes a convention that all paths by the same disk device should always using the same LUN 'number' to guarantees consistency for device identification, this may not be technically true. Always refer to the Host Operating System vendor s own documentation for advice on this. DataCore's Software does, however always try to create mappings between the Host's ports and the DataCore Server's Front-end (FE) ports for a Virtual Disk using the same LUN number where it can. The software will first find the next available (lowest) LUN 'number' for the Host- DataCore FE mapping combination being applied and will then try to apply that same LUN number for all other mappings that are being attempted when the Virtual Disk is being served. If any Host-DataCore FE port combination being requested at that moment is already using that same LUN number (e.g. if a Host has other Virtual Disks served to it from previous) then the software will find the next available LUN number and apply that to those specific Host-DataCore FE mappings only. Also See Registering Hosts Changing Virtual Disk Settings - SCSI Standard Inquiry Page 8

9 The XenServer Host's settings XenServer 7.x Multipath Configuration The 'defaults' section Add/Modify the polling_interval to a value of 10 (seconds). defaults { polling_interval 10 } This is a DataCore-required value that manages how often the Host checks for access on a previously failed Virtual Disk. A smaller setting will interfere with Host performance. Notes Do not add this parameter to the 'device' section of the multipath configuration file as the setting will not work as expected. The 'device' section For Host with ALUA enabled device { } vendor "DataCore" product "Virtual Disk" path_checker tur failback 30 path_selector "round-robin 0" rr_min_io 100 path_grouping_policy group_by_prio prio alua For Hosts without ALUA enabled device { } vendor "DataCore" product "Virtual Disk" path_checker tur failback 10 path_grouping_policy failover prio hp_sw Page 9

10 The XenServer Host's settings Notes All of the entries listed in the configuration settings are DataCore-required values. vendor / product By default all new Virtual Disks created in SANsymphony versions 8, 9 and 10 will use the vendor and product strings DataCore and Virtual Disk listed above. Virtual Disks that were originally created using the older DataCore SANsymphony 7 or SANmelody products will have different vendor and product values so a new, additional device section will need to be added to the multipath configuration file to work with those Virtual Disks, all other settings will remain the same, only the vendor and product strings will change. See the section SCSI Standard Inquiry from the online help: failback Adds an extra wait period (10 seconds) to prevent unnecessary failback attempts to a Virtual Disk whose Host Access value is currently Not Allowed. path_selector / path_checker One of either two values is allowed: Use path_selector for Hosts with ALUA enabled Use path_checker for Hosts without ALUA enabled path_grouping_policy One of either two values is allowed: Use group_by_prio for Hosts with ALUA enabled Use failover for Hosts without ALUA enabled In either case, make sure the Preferred Server setting on the DataCore Server is to 'Auto Select' or an explicit Server Name. See page 15 for more information regarding the 'Auto Select' setting. prio The 'hp_sw' switch was required to get failover and failback working during DataCore's own qualification tests for XenServer 7.x Hosts without ALUA enabled. rr_min_io (applies to ALUA enabled Hosts only) No other value should be used. Page 10

11 The XenServer Host's settings XenServer 6.x Multipath Configuration The 'defaults' section Add/Modify the polling_interval to a value of 10 (seconds). defaults { polling_interval 10 } This is a DataCore-required value that manages how often the Host checks for access on a previously failed Virtual Disk. A smaller setting will interfere with Host performance. Notes Do not add this parameter to the 'device' section of the multipath configuration file as the setting will not work as expected. The 'device' section ALUA enabled For XenServer Host versions 6.2 and 6.5 device { } vendor "DataCore" product "Virtual Disk" path_checker tur failback 30 path_selector "round-robin 0" rr_min_io 100 path_grouping_policy group_by_prio prio alua For XenServer Host versions 6.1 or 6.0 device { } vendor "DataCore" product "Virtual Disk" path_checker tur failback 30 path_selector "round-robin 0" rr_min_io 100 path_grouping_policy group_by_prio prio_callout "/sbin/mpath_prio_alua %d" Page 11

12 The XenServer Host's settings ALUA not enabled For any version of XenServer: device { } vendor "DataCore" product "Virtual Disk" path_checker tur failback 10 path_grouping_policy failover Notes All of the entries listed in the configuration settings are DataCore-required values. vendor / product By default all new Virtual Disks created in SANsymphony versions 8, 9 and 10 will use the vendor and product strings DataCore and Virtual Disk listed above. Virtual Disks that were originally created using the older DataCore SANsymphony 7 or SANmelody products will have different vendor and product values so a new, additional device section will need to be added to the multipath configuration file to work with those Virtual Disks, all other settings will remain the same, only the vendor and product strings will change. See the section SCSI Standard Inquiry from the online help: path_checker Use the value indicated above. No other value should be used. path_selector (applies to ALUA enabled Hosts only) Use the value indicated above. No other value should be used. failback Adds an extra wait period (10 seconds) to prevent unnecessary failback attempts to a Virtual Disk whose Host Access value is Not Allowed. path_grouping_policy One of either two values is allowed: Use group_by_prio for Hosts where ALUA is enabled Use failover for Hosts where ALUA is not enabled In either case, make sure the Preferred Server setting on the DataCore Server is to 'Auto Select' or an explicit Server Name. See page 15 for more information regarding the 'Auto Select' setting. prio / prio_callout (applies to ALUA enabled Hosts only) Use the prio setting for XenServer Hosts 6.2 and 6.5 Use prio_callouts setting for XenServer Hosts 6.1 or 6.0 rr_min_io (applies to ALUA enabled Hosts only) Use the value indicated above. No other value should be used. Page 12

13 Known issues The following is intended to make DataCore Software customers aware of any issues that may affect performance, access or generally give unexpected results under certain conditions when XenServer Hosts are used with SANsymphony. Some of the issues here have been found during DataCore s own testing but many others are issues reported by DataCore Software customers, where a specific problem had been identified and then subsequently resolved. DataCore cannot be held responsible for incorrect information regarding Citrix products. No assumption should be made that DataCore has direct communication with Citrix regarding the issues listed here and we always recommend that users contact Citrix directly to see if there are any updates or fixes since they were reported to us. For Known issues for DataCore s own Software products, please refer to the relevant DataCore Software Component s release notes. Hardware Affects XenServer 7.x and 6.x QLogic QLA405x/406x iscsi HBAs Use QLogic s Firmware revision or greater General Affects XenServer 7.x and 6.x Virtual Disks must be served to both the XenServer pool master as well as its members to be discovered as pool member operations always go 'via' the XenServer 'Master' Server. For example, if a XenServer Pool member has Virtual Disk 1 served to it but the Master Server does not (or vice versa), then XenServer will never discover Virtual Disk 1 when scanning for it. Affects XenServer 7.x and 6.x XenServer may not detect new size changes from a previously served Virtual Disk Even if a Storage Repository (SR) is destroyed (and the Virtual Disk(s) are unserved); any subsequent change to a Virtual Disk's size will not be re-detected when it is then served back to the same XenServer Host. In this case the previous Virtual Disk size will be reported. Page 13

14 Known issues Affects XenServer 7.x and 6.x The multipath.conf file may get overwritten when upgrading After upgrading from an older version of XenServer, always check that the upgrade has not overwritten changes made to the multipath.conf file. Depending on the version of XenServer, multipath.conf may be a soft link that points to /etc/multipath-enabled.conf. Note that it is usually not enough to simply save a copy of this file and re-apply it after the upgrade without a further reboot contact Citrix for more advice. Hotfixes Affects XenServer 6.x only A hotfix is required for XenServer when using space TRIM/UNMAP commands on Virtual Disks that are larger than 2TB In XenCenter, this feature is labelled 'Reclaim freed space' on the Xen host's Storage tab. Downloaded from: Note that running TRIM/UNMAP commands is only qualified with Virtual Disks served from SANsymphony 10.0 PSP 6 or greater. Please see Appendix B on page 17 for more details. Affects XenServer 6.x only A hotfix is required for XenServer when using iscsi FE Ports Downloaded from here: Affects XenServer 6.x only A hotfix is required for XenServer when using iscsi FE Ports Downloaded from here: Page 14

15 Appendix A Preferred Server & Preferred Path settings Without ALUA enabled If Hosts are registered without ALUA support, the Preferred Server and Preferred Path settings will serve no function. All DataCore Servers and their respective Front End (FE) paths are considered equal. It is up to the Host s own Operating System or Failover Software to determine which DataCore Server is its preferred server. With ALUA enabled Setting the Preferred Server to Auto (or an explicit DataCore Server), determines the DataCore Server that is designated Active Optimized for Host IO. The other DataCore Server is designated Active Non-Optimized. If for any reason the Storage Source on the preferred DataCore Server becomes unavailable, and the Host Access for the Virtual Disk is set to Offline or Disabled, then the other DataCore Server will be designated the Active Optimized side. The Host will be notified by both DataCore Servers that there has been an ALUA state change, forcing the Host to re-check the ALUA state of both DataCore Servers and act accordingly. If the Storage Source on the preferred DataCore Server becomes unavailable but the Host Access for the Virtual Disk remains Read/Write, for example if only the Storage behind the DataCore Server is unavailable but the FE and MR paths are all connected or if the Host physically becomes disconnected from the preferred DataCore Server (e.g. Fibre Channel or iscsi Cable failure) then the ALUA state will not change for the remaining, Active Nonoptimized side. However, in this case, the DataCore Server will not prevent access to the Host nor will it change the way READ or WRITE IO is handled compared to the Active Optimized side, but the Host will still register this DataCore Server s Paths as Active Non-Optimized which may (or may not) affect how the Host behaves generally. Also see Preferred Servers and Preferred Paths from: Page 15

16 Appendix A Preferred Server & Preferred Path settings In the case where the Preferred Server is set to All, then both DataCore Servers are designated Active Optimized for Host IO. All IO requests from a Host will use all Paths to all DataCore Servers equally, regardless of the distance that the IO has to travel to the DataCore Server. For this reason, the All setting is not normally recommended. If a Host has to send a WRITE IO to a remote DataCore Server (where the IO Path is significantly distant compared to the other local DataCore Server), then the WAIT times accrued by having to send the IO not only across the SAN to the remote DataCore Server, but for the remote DataCore Server to mirror back to the local DataCore Server and then for the mirror write to be acknowledged from the local DataCore Server to the remote DataCore Server and finally for the acknowledgement to be sent to the Host back across the SAN, can be significant. The benefits of being able to use all Paths to all DataCore Servers for all Virtual Disks are not always clear cut. Testing is advised. For Preferred Path settings it is stated in the SANsymphony Help: A preferred front-end path setting can also be set manually for a particular virtual disk. In this case, the manual setting for a virtual disk overrides the preferred path created by the preferred server setting for the host. So for example, if the Preferred Server is designated as DataCore Server A and the Preferred Paths are designated as DataCore Server B, then DataCore Server B will be the Active Optimized Side not DataCore Server A. In a two-node Server group there is usually nothing to be gained by making the Preferred Path setting different to the Preferred Server setting and it may also cause confusion when trying to diagnose path problems, or when redesigning your DataCore SAN with regard to Host IO Paths. For Server Groups that have three or more DataCore Servers, and where one (or more) of these DataCore Servers shares Mirror Paths between other DataCore Servers setting the Preferred Path makes more sense. So for example, DataCore Server A has two mirrored Virtual Disks, one with DataCore Server B, and one with DataCore Server C and DataCore Server B also has a mirrored Virtual Disk with DataCore Server C then using just the Preferred Server setting to designate the Active Optimized side for the Host s Virtual Disks becomes more complicated. In this case the Preferred Path setting can be used to override the Preferred Server setting for a much more granular level of control. Page 16

17 Appendix B Reclaiming storage from Disk Pools How much storage will be reclaimed? This is impossible to predict. SANsymphony can only reclaim Storage Allocation Units that have no block-level data on them. If a Host write its data all over its own filesystem, rather than contiguously, the amount of storage that can be reclaimed may be significantly less than expected. Defragmenting data on Virtual Disks It may be possible to use a Host s own defragmentation tools to consolidate data spread out all over the host s filesystem but care should be taken as even more storage may be allocated while the existing data is defragmented. Once any defragmentation is completed then additional steps will need to wipe the free filesystem space on the host and then use SANsymphony s Manual Reclamation feature see next. Notes on SANsymphony's Reclamation feature Automatic Reclamation SANsymphony checks for any zero write I/O as it is received by the Disk Pool and keeps track of which block addresses they were sent to. When all the blocks of an allocated SAU have received zero write I/O, the storage used by the SAU is then reclaimed. Mirrored and replicated Virtual Disks will mirror/replicate the zero write I/O so that storage can be reclaimed on the mirror/replication destination DataCore Server in the same way. Manual Reclamation SANsymphony checks for zero block data by sending read I/O to the storage. When all the blocks of an allocated SAU are detected as having zero data on them, the storage used by the SAU is then reclaimed. Mirrored Virtual Disks will receive the manual reclamation request on all DataCore Servers involved in the mirror configuration at the same time and each DataCore Server will read from its own storage. The Manual reclamation request is not sent to replication destination DataCore Servers from the source. Replication destinations will need to be manually reclaimed separately. Page 17

18 Appendix B Reclaiming storage from Disk Pools Reclaiming storage on the Host manually A suggestion would be create a raw VDI on the storage repository and format it using the 'vdi-create' command. Here is an example with a 50GB VDI file: xe vdi-create sr-uuid={datacore-sr-uuid} type=user virtual-size=50gib name-label=reclaimdisk / sm-config:type=raw Now present the VDI device to an existing virtual machine then from within the VM's own operating system issue 'zeroes' to the VDI disk device. For Microsoft Windows VMs use Microsoft s own sdelete tool. For Unix/Linux-based Hosts, use the dd command to fill all of the unused file system space with 'all-zero' write I/O. Also see Auto-reclamation of unused SAUs Reclaiming Unused Virtual Disk Space in Disk Pools: Page 18

19 Previous changes Updated General This document has been reviewed for SANsymphony 10.0 PSP 7. No additional settings or configurations are required. February 2018 Removed Appendix B Configuring Disk Pools The information here has been removed as it is now superseded by the information in: The DataCore Server- Best Practice Guidelines What was previously 'Appendix C' has now been moved to 'Appendix B'. Updated XenServer compatibility list XenServer 7.2 is now Qualified with SANsymphony-V 10.x with or without ALUA. November Updated XenServer compatibility list XenServer 7.1 is now Qualified with SANsymphony-V 10.x with or without ALUA. Mayr 2017 Added Known Issues April 2017 QLogic QLA405x/406x iscsi HBAs Use QLogic s Firmware revision or greater. This was previously documented in 'Known Issues - Third Party Hardware and Software'. Updated XenServer compatibility list XenServer 7.1 has been added to the table and is currently considered 'not qualified' with SANsymphony 10.x Added Known Issues December 2016 A hotfix is required for XenServer when using iscsi FE Ports Downloaded from here: Updated Appendix C - Reclaiming storage SCSI UNMAP is now supported with SANsymphony-V 10.0 PSP 6 or greater Page 19

20 Added The XenServer Host Multipath Configuration Settings for XenServer 7.x New settings are required when using XenServer 7.0 August 2016 Updated XenServer compatibility list XenServer 7.0 is now supported with SANsymphony-V 10.x with or without ALUA. ALUA is now supported on XenServer 7.0 using Fibre Channel as well as iscsi front end connections. Appendix C - Reclaiming storage SCSI UNMAP is now supported with SANsymphony-V 10.0 PSP 6 or greater Updated XenServer compatibility list This document has been reviewed for SANsymphony 10.0 PSP 5. No updates were required. July 2016 Updated XenServer compatibility list XenServer 7.0 was added not currently qualified. June 2016 Page 20

21 2015 and earlier December 2015 This document combines all of DataCore s Citrix XenServer-related information from older Technical Bulletins into a single document including: Technical Bulletin 15c: "Citrix XenServer 5.6/6.x Hosts" Technical Bulletin 8: "Formatting Host s File Systems on Virtual Disks created from Disk Pools" Technical Bulletin 11: "Disk Timeout Settings on Hosts" Technical Bulletin 16: "Reclaiming Space in Disk Pools" Updated SANsymphony-V 8.x and all versions of SANsymphony 9.x before PSP4 Update 4 are now End of Life. Please see: End of Life Notifications and earlier Technical Bulletin 15c: "Citrix XenServer 5.6/6.x Hosts" January 2014 Updated the General known issue regarding discovering ISCSI IQNs using the wildcard option when using XenServer A hotfix from Citrix is now available.. December 2013 Added Citrix XenServer 6.2. Updated multipath.conf with a different prio setting for XenServer 6.2 when using iscsi and ALUA. Added a new General known issue regarding discovering ISCSI IQNs using the wildcard option when using XenServer August 2013 Removed all references for SANmelody as this product is now end of life. Updated Host Minimum Requirements section. Updated Host Supported Versions section. Completely updated the Known Issues section. Updated multipath.conf entries and notes (includes new configuration entries for Round Robin). Removed out-of-date screenshots and instructions on how to configure XenServer using Citrix s own tools refer to Citrix s own documentation on how to configure and discover SRs and/or LUNs. October 2012 Updated the Configuring XenServer for Multipathing section. Added SANsymphony-V 9.x and removed the need for first 12 characters unique in vdisk names for SANsymphony-V Removed all (out of date) step-by-step instructions on how to manage and configure/format disk devices on the Host. November 2011 Added Citrix XenServer 6.x. removed all references to End of Life SANsymphony and SANmelody versions that are no longer supported as of July March 2011 Added SANsymphony-V R8.x December 2010 Initial Publication Page 21

22 The authority on real-time data Copyright 2018 by DataCore Software Corporation. All rights reserved. DataCore, the DataCore logo and SANsymphony are trademarks of DataCore Software Corporation. Other DataCore product or service names or logos referenced herein are trademarks of DataCore Software Corporation. All other products, services and company names mentioned herein may be trademarks of their respective owners. ALTHOUGH THE MATERIAL PRESENTED IN THIS DOCUMENT IS BELIEVED TO BE ACCURATE, IT IS PROVIDED AS IS AND USERS MUST TAKE ALL RESPONSIBILITY FOR THE USE OR APPLICATION OF THE PRODUCTS DESCRIBED AND THE INFORMATION CONTAINED IN THIS DOCUMENT. NEITHER DATACORE NOR ITS SUPPLIERS MAKE ANY EXPRESS OR IMPLIED REPRESENTATION, WARRANTY OR ENDORSEMENT REGARDING, AND SHALL HAVE NO LIABILITY FOR, THE USE OR APPLICATION OF ANY DATACORE OR THIRD PARTY PRODUCTS OR THE OTHER INFORMATION REFERRED TO IN THIS DOCUMENT. ALL SUCH WARRANTIES (INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE AND AGAINST HIDDEN DEFECTS) AND LIABILITY ARE HEREBY DISCLAIMED TO THE FULLEST EXTENT PERMITTED BY LAW. No part of this document may be copied, reproduced, translated or reduced to any electronic medium or machinereadable form without the prior written consent of DataCore Software Corporation