Veritas Software SCSI & RAID Devices Driver Download For Windows

Often used with Veritas volume manager - which is an LVM software, and can properly identify disk statuses. Normally uses SCSI reservation for I/O fencing, but can be used also without this. Works only with SCSI disk devices. Comes as an added product for Solaris operating systems. Reinstall the Veritas software. 115323, 140441 Disk controller firmware upgrades. For a workaround to Sun Bug ID 4164338, use the procedure described in 'Upgrading disk controller firmware' in the 'Administering Dynamic Multipathing (DMP)' chapter of the Veritas Volume Manager Administrator's Guide. T3B firmware upgrade on Solaris 9.

• Veritas Software Scsi & Raid Devices Driver Download For Windows 10
• Veritas Software Scsi & Raid Devices Driver Download For Windows Xp
• Veritas Software Scsi & Raid Devices Driver Download For Windows 8.1
• Veritas Software Scsi & Raid Devices Driver Download For Windows 7

Veritas Volume Manager known issues

See the following sections for information about known problems and issues in this release of VxVM.

Installation and upgrade issues

ASL support for Sun StorEdge T3 and T3+ arrays

This release does not include the libvxpurple.so array support library (ASL) to support Sun StorEdge T3 and T3+ arrays. Any existing version of the libvxpurple.so ASL is removed when VxVM is upgraded to 5.0. Any T3 and T3+ arrays must be configured in autotrespass mode, and treated as JBODs of type A/P. An ASL to support Sun StorEdge T3 and T3+ arrays will be provided in the 5.0 Maintenance Pack 1 release.

If an array is of type A/A-A, A/P or A/PF, and a suitable ASL is not available, the array must be claimed as an JBOD of type A/P. This is to prevent path delays and I/O failures arising. As JBODs are assumed to be type A/A by default, and neither T3 nor T3+ arrays are of this type, you must create appropriate JBOD entries for such arrays.

To configure a Sun StorEdge T3 or T3+ array as a JBOD of type A/P

1. Stop all applications, such as databases, from accessing VxVM volumes that are configured on the array, and unmount all VxFS file systems and checkpoints that are configured on the array.
2. Configure the T3 or T3+ array in autotrespass mode.
3. Add the array as a JBOD of type A/P:

   # vxddladm addjbod vid=SUN pid=T300 policy=ap

4. If you have not already done so, upgrade the Storage Foundation or VxVM software to 5.0. Device discovery will be performed during the upgrade, and the array will be claimed as an A/P JBOD.

   If you have already upgraded your system to 5.0, run the following command to perform device discovery:

   # vxdctl enable

5. Verify that the array has been added with the policy set to APdisk:

   # vxddladm listjbod

   VID PID Opcode Page Code Page Offset SNO length Policy

   SUN T300 18 -1 36 12 APdisk

6. Check that the correct devices are listed for the array:

   # vxdisk list

   DEVICE TYPE DISK GROUP STATUS

   APdisk_0 auto:cdsdisk - - online invalid

   APdisk_1 auto:cdsdisk - - online invalid

   APdisk_2 auto:cdsdisk - - online invalid

   ...

Error messages seen during live upgrade

When running the vxlufinish script to upgrade VxVM, you may see error messages similar to the following.

Such messages are harmless and can be ignored.

Initializing disks previously under VxVM control

If you are planning to initialize disks, check to see if any of the disks were previously under VxVM control. If so, and if they were used on the same host system, the disk groups they represent are imported automatically during the installation process if the proper removal procedures were not followed. An attempt during installation to initialize or encapsulate disks that were previously under VxVM control fails. After installation, if you no longer want to use those disk groups, use the destroy option of the vxdg command to remove those disk groups. Alternately, you can use vxdiskunsetup to remove the disks from VxVM control. Be aware that these options can result in data loss if used incorrectly.

Recognizing simple disks from earlier releases

In earlier releases of VxVM, some users minimized the allocation of disks to the disk group, rootdg, by associating rootdg with a small disk partition that was characterized as a simple disk. This procedure would have been achieved by using the command, vxdctl add disk, which is no longer supported in VxVM 4.0 and later releases.

If you created one of these simple disks, you will need to carry out a procedure similar to the one described in the following example.

Assuming that the simple disk is defined to be on c1t21d0s7, you would see the following entry in /etc/vx/volboot:

disk c1t21d0s7 simple privoffset=1

After upgrading to VxVM 5.0, you must reboot the system. After rebooting, execute the command, vxdisk list, and you will see that c1t21d0s7 is not listed. This is because vxconfigd now ignores disk entries in /etc/vx/volboot.

To retain access to data on a simple disk

1. Define a disk access record that will be created in /etc/vx/darecs

   # vxdisk define c1t21d0s7 type=simple

2. Request that vxconfigd should extract information from this disk:

   # vxdctl enable

3. Discover the name of the disk's disk group:

   # vxprint -th

4. Enable access to the disk's disk group; rootdg in this example:

   # vxvol -g rootdg startall

[137838]

Error messages output by the upgrade script

If a swap volume specified in /etc/vfstab is mirrored at the time that upgrade_start is run, the upgrade_finish script starts a resynchronization of the volume. This can cause a message similar to the following to be printed when the command to reboot the system is issued:

xvm:vxvol: tutil0 field for plex plex_name changed unexpectedly

This message can be ignored.

For a system on which the root file system is contained on a mirrored volume, the upgrade_start script can choose a mirror on a disk other than the normal boot disk to perform the upgrade. If this occurs, the reboot after running upgrade_finish can initially fail, claiming that the mirror on the boot disk is stale, as follows:

Boot the system from one of the disks named. If the eeprom option use-nvramrc? is set to true, boot the system by specifying vx-diskname.

Interruption of an upgrade

If the installation software is interrupted on the local system during certain upgrade situations, Veritas Volume Manager configurations may be lost after a reboot. If this happens, the entire Veritas Volume Manager package must be reinstalled and a recover must be done manually by recreating the disks, disk groups, and volumes and restoring the data from backup. [13033]

'SIGHUP caught' message on the console

When running vxinstall on a system with a SENA array that is enabled with enclosure naming, you may see a message similar to the following:

newmac.veritas.com console login: Dec 31 00:00:00

syseventd[59]: SIGHUP caught

You can safely ignore this message. [Sun Bug ID 4955989, i138955]

Misleading alerts generated on a system with the VAIL package installed

An alert with the text message 'SymCLI command line tools are not installed properly' will be generated in each of the following two cases when SYMCLI is either absent or not installed properly on the host on which a VAIL package is installed.

Case 1. When host comes up after a reboot and SYMCLI is either absent or not installed properly.

Case 2. When a rescan of Symmetrix provider is initiated and SYMCLI is either found to be absent or found to be not installed properly but SYMCLI installation was proper before rescan of Symmetrix provider was initiated.

In either of Case 1 or Case 2 one should ignore the alert message on the host on which VAIL package is installed if there is no EMC Symmetrix array being managed on that host. [Sun Bug ID 6211778, 297830]

Utility issues

No support for non-global zones

Veritas Volume Manager does not support non-global zones.

Global Device Naming

The Global Device Naming (GDN) option to the vxddladm command should only be used with the Storage Foundation Volume Server software. [608621]

Current naming scheme

There is no option in the vxddladm command to display the current naming scheme. The naming scheme that is in operation can be deduced from the output to the vxdisklist command. [611320]

Specifying an enclosure to the vxdmpadm getportids command

The enclosure attribute should be used to specify an enclosure name to the vxdmpadmgetportids command, instead of the enclr attribute that is shown in the Veritas Volume Manager Administrator's Guide and the vxdmpadm(1M) manual page.

vxdiskadm displays error V-5-1-9764 when excluding devices

The vxdiskadm operation displays error V-5-1-9764 if a vendor and product ID combination are specified to exclude devices from multipathing. This error is harmless and can be ignored. The error is not seen if controller or device names are specified instead. [587435]

Disk group is disabled if private region sizes differ

A disk group is disabled if the vxdginit command is used to create it from a set of disks that have pre-existing private regions that differ in size. This may occur if the disks previously belonged to disk groups in older releases of VxVM.

The workaround is to reinitialize the disks before creating the disk group (for example, by using the vxdisk-finit command), or to use the vxdgadddisk command to add the disks to the disk group after it has been created. [592180]

Volume tags are lost after disk group split

If a disk group is split from a source disk group, volumes in the split-off disk group do not retain their volume tags. You must recreate the tags by using the vxassistsettag command. [605743]

Maximum size of a VxVM volume

VxVM supports volume lengths up to 256TB. However, any 32-bit legacy applications that use system calls such as seek, lseek, read and write are limited to a maximum offset that is determined by the operating system. This value is usually 2³¹-1 bytes (1 byte less than 2 terabytes).

Resizing volumes with detached remote plexes

If a volume in a Remote Mirror configuration has detached plexes at a remote site, you can use the following procedure to resize it:

1. Turn off the allsites attribute for the volume:

   # vxvol -g diskgroup set allsites=off volume

2. Remove the detached plexes:

3. Use the vxresize command to resize the volume.

When the remote site comes back up:

1. Replace the removed plexes using storage at the remote site:

2. Turn on the allsites attribute for the volume:

   # vxvol -g diskgroup set allsites=on volume

Shrinking a swap volume

vxassist has no built-in protection to prevent you from shrinking the swap volume without first shrinking what the system sees as available swap space. If it is necessary to shrink the swap volume, the operation must be done in single user mode and the system must be rebooted immediately. Failing to take these precautions can result in unknown system behavior or lock-up. [6154]

Adding a log and mirror to a volume

The vxassist command does not add a mirror and a log when processing a command such as the following:

# vxassist mirror volume layout=log ...

The mirror is added, but the log is silently omitted. To add a log and a mirror, add them in two separate vxassist invocations, as follows:

# vxassist mirror volume ...

# vxassist addlog volume ...

[13488]

Replacement of the old_layout attribute

The old_layout attribute is no longer supported when the vxdisksetup command is used to make a disk into a VxVM controlled disk. Use the noreserve attribute instead. [121258]

Using vxvol and vxmend with layered volumes

The vxvol and vxmend commands do not handle layered volumes very well. When vxmend is executed on the top level volume to change the state of a volume, it is executed only on the top level volume; the change is not propagated to the lower level volumes. As a result, the volume states can become inconsistent and a subsequent vxvolinit command might fail.

The vxvol command exhibits the same problem. When a vxvolinit command is executed on the top level volume, the change is not propagated to the volumes corresponding to its subvolumes.

Workaround: When executing the vxvol or vxmend command on a layered volume, first issue the command to the lower level volumes in a bottom-up fashion; then execute the command on the top-level volume.

In this example, a volume, vol, has two subvolumes, vol-L01 and vol-L02. The state of the volumes is first set to empty, and then the initialization commands are executed:

# vxmend -o force -g mydg fix empty vol

# vxmend -o force -g mydg fix empty vol-L01

# vxmend -o force -g mydg fix empty vol-L02

# vxvol -g mydg init zero vol

# vxvol -g mydg init zero vol-L01

# vxvol -g mydg init zero vol-L02

[134932]

Growing or shrinking layered volumes

Due to the current implementation of a resize of layered volumes, it is recommended that you do not grow or shrink layered volumes (for example; stripe-mirror, concat-mirror) while resynchronization is ongoing. Note that this limitation does not apply to ISP layered volumes.

Internally, VxVM converts the layout of layered volumes and updates the configuration database before it does the actual resize. This causes any ongoing operation, such as a resynchronization, to fail.

If the system reboots before the grow or shrink of a layered volume completes, the volume is left with an intermediate layout. In this case, you have to use vxassist convert to restore the volume to its original layout.

After a layered volume is resized, the volume names, the plex names and the subdisk names associated with the subvolumes, are changed.

Converting a multipathed disk

Under Solaris 10 when converting a multipathed disk that is smaller than 1TB from a VTOC label to an EFI label, you must issue a format-e command for each path. For example, if a node has two paths, c1t2d0s2 and c2tsd0s2, you need to apply the format-e command to each of the two paths. [269566]

Startup script messages not seen on the console

With the introduction of SMF support in Solaris 10, startup script messages are no longer seen on the console.

These messages can be viewed (cat or vi) in SMF log files found at:

/var/svc/log

/etc/svc/volatile

The file names are based on the specific startup script:

#/var/svc/log: ls

system-vxvm-vxvm-startup2:default.log

system-vxvm-vxvm-sysboot:default.log

Also, other startup messages can be found in:

#/var/svc/log: ls

milestone-multi-user-server:default.log

milestone-multi-user:default.log

milestone-name-services:default.log

milestone-single-user:default.log

#/etc/svc/volatile

system-vxvm-vxvm-startup2:default.log

system-vxvm-vxvm-sysboot:default.log

[269949]

Bad disk block warning

When vxio detects a bad disk block on a disk, it will display a warning message indicating that an uncorrectable write error has been encountered. [272176]

Do not specify a long device name in the /etc/vx/disks.exclude file

It is recommended that you do not edit the /etc/vx/disks.exclude file directly. Some scripts like vxdiskadm fail with an error message if a long device name is specified in this file. You should instead use option 17 or 18 of the vxdiskadm command to suppress or unsuppress devices from VxVM's view. [Sun Bug ID 6228464, 311275]

Unable to boot system without bootdg link to the boot disk group

A system may fail to boot with the following errors:

One possible cause for the error that the symbolic link between bootdg and the boot disk group under /dev/vx/dsk or /dev/vx/rdsk is missing.

The workaround for this error is as follows

1. Make sure that your system does not have a link under /dev/vx/dsk and /dev/vx/rdsk

   bootdg -> rootdg

2. Boot the system from cdrom or net.
3. Mount the / from CDROM. In this example cxtxdxs0 is the boot disk.

   # mount -F ufs -o nologging /dev/dsk/cxtxdxs0 /mnt

4. Create the link. This example assumes that the boot disk group is called rootdg:

   # cd /mnt/dev/vx/dsk

   # ln -s rootdg bootdg

   # cd /mnt/dev/vx/rdsk

   # ln -s rootdg bootdg

   # cd

   # umount /mnt

   # init 0

5. Reboot the system.

[Sun Bug ID 6230224]

Device issues

Stale device entries slow down VxVM

Under Solaris 10, stale device entries in the /dev/[r]dsk directories can cause the VxVM configuration daemon, vxconfigd, to consume a large amount of CPU time. Remove the stale entries by entering the following sequence of commands:

# devfsadm -C

# touch /reconfigure

# init 6

Newly added disks should be labeled

When new disks are added to a Solaris configuration, these disks should be labeled before they are used with VxVM. VxVM can discover unlabeled disks, but it cannot read their disk geometry, nor can it initialize them. A console message similar to the following is displayed for each unlabeled disk:

When VxVM discovers unlabeled disks, the disk configuration information is added to DMP. If DMP attempts to open the unlabeled device, the open fails, and the paths are disabled. If the system is subsequently rebooted with the unlabeled disks, DMP disabled path messages are also displayed for the unlabeled disks.

To prevent unnecessary delay occurring at boot time, it is recommended that you use the format command to label new disks before having VxVM discover and initialize them. [544797]

vxddladm addsupport command limitations

The vxddladm addsupport command could cause your system to hang when using a Sun SCSI Enclosure Service (SES) Driver. This situation can be caused by stale entries in /dev/es. A stale entry is a device link in /dev/es, for which no corresponding device is connected to the system.

In some circumstances, installing VxVM can cause a system to hang because the vxddladm addsupport command is also run.

If your system hangs, perform the following workaround

1. Reboot the system.
2. Remove all entries, both stale and valid, from /dev/es.
3. Run the devfsadm command to recreate /dev/es with valid entries:

   # devfsadm -C

4. Reinstall the Veritas software.

[115323, 140441]

Disk controller firmware upgrades

For a workaround to Sun Bug ID 4164338, use the procedure described in 'Upgrading disk controller firmware' in the 'Administering Dynamic Multipathing (DMP)' chapter of the Veritas Volume Manager Administrator's Guide.

T3B firmware upgrade on Solaris 9

On Solaris 9 only, a T3B upgrade to firmware version 2.1 must follow the procedure below. Not using the procedure leads to disabled disk groups or an inability to mount file systems. (i95877)

1. Use the umount command to unmount related file systems

   # umount mount_point

2. Stop all VxVM volumes:

   # vxvol -g dg_name stopall

3. Stop VxVM:

   # vxdctl stop

   # vxiod -f set 0

4. Upgrade the T3B firmware to version 2.1.

5. Start VxVM:

   # vxiod set 10

   # configd -m disable

   # vxdctl enable

6. Start the VxVM volumes:

   # vxvol -g dg_name start vol_name

7. Use the mount command to remount the file system, for example:

   # mount -F vxfs /h/filesys

Event source daemon dies

If the host-side switch port is disabled and enabled on a Brocade switch, the event source daemon (vxesd) dies if the latest Solaris patches for the SUNWfchba, SUNWfchbr and SUNWfchbx packages have not been applied to the system. For Solaris 8 or 9, SAN Foundation kit 4.4.7 or later is required. For Solaris 10, install the latest recommended Patch Cluster. [534392]

Hitachi arrays in Active/Active mode

When Hitachi DF400, DF500, HDS9200, HDS9500 or HDS9700 arrays are configured as Active/Active mode arrays, performance is degraded. The correct ASL must be installed that allows these arrays to be claimed as A/PG-type arrays. [73154]

Relayout of volumes on the root disk

Do not run the vxrelayout and vxassist commands to relayout a volume that is part of root disk. This action may corrupt the layout of the root disk so that you cannot boot from it. On an encapsulated root disk, a relayout can cause an upgrade to fail. [103991]

Failure to add a disk from a T3 array

On a T3 array, VxVM may display the following failure when trying to add a disk (typically from vxinstall or vxdisksetup):

vxvm:vxdisk: ERROR: Device XXXX: online failed

Device path not valid

This can happen in cases where the T3 disk was re-partitioned (or re-formatted) prior to one or more disks being added. [105173]

SFCFS with I/O fencing is not supported on HDS9200 arrays

If you attempt to boot a cluster with I/O fencing (PGR) enabled, HDS9200 disks will show up in error state on the slaves. This error does not appear if I/O fencing is disabled. [131926]

Disks in V480 and V880 internal disk enclosures

Fujitsu and Hitachi disks in V480 and V880 internal disk enclosures may not be automatically recognized as JBOD disks. This could potentially cause data corruption if multipathing is not configured correctly. After installing any Sun-qualified FC disks as FRU replacements, use the procedure described in 'Adding Unsupported Disk Arrays to the DISKS Category' in the 'Administering Disks' chapter of the Veritas Volume Manager Administrator's Guide to add each such disk to the JBOD category. It is important that both the vendor ID and product ID are specified for each such disk to avoid conflicts with similar disks in other arrays. For Fujitsu disks, the number of characters in the serial number must also be specified. [Sun Bug ID 4900508, i133579]

Encapsulation of disks with insufficient space for a private region

Disks with insufficient space for the allocation of an on-disk database copy cannot be encapsulated. The database requires at least the same space as is allocated for other disks in the same disk group. The default required size is 32MB. To work around this, relocate the data on the last partition of the disk to a volume on a different disk, and free the space by reducing the partition size to 0.

The space for the database must be allocated from the beginning or the end of the disk, with the exception of the root disk. The root disk can be encapsulated by carving out space from the swap partition if there is no space at the beginning or at the end of the disk. This is done by creating a subdisk for the private partition in the space obtained from the swap partition.

Workaround: The problem of insufficient space on a disk to store private VxVM information has no workaround. VxVM requires a small region of private storage for proper disk identification. The number of VxVM objects that can be configured in a disk group is almost directly proportional to the size of the private region. The default private region size is 32MB. If this size is overridden, it is recommended that it be made no smaller than 1MB.

Errors when using JNI cards

If the model number of your JNI card is one of FCE-1063, FCE2-1063, FCE-6410, FCE2-6410, or FCE2-6412, you may experience error messages of the form:

Oct 22 00:16:18 ds13un jnic: [ID 709123 kern.notice] jnic1: Link Up

Oct 22 00:16:18 ds13un jnic: [ID 229844 kern.notice] jni

Contact JNI support for more information.

Workaround: Add the following parameter to the JNI configuration file (jnic.conf):

FcEnableContextSwitch = 1;

Sun StorEdge Traffic Manager (SSTM)

The Sun StorEdge Traffic Manager (SSTM) boot support feature that is available through SAN 4.3 or later is not supported. Booting from fabric devices under SSTM or boot encapsulation of fabric devices under SSTM is also not supported.
[Sun Bug ID 4912232, 4909641, 4912667].

Loss of disk space in 3510 arrays

If a 3510 array disk that is larger than 512GB is initialized to be a CDS disk, the value that is returned by a SCSI mode sense command for the number of sectors per track may be incorrect. This can cause the sector count to be miscalculated and some disk space to be lost. [272241]

Hitachi 9990 Genesis array

After installing the Storage Foundation software, errors such as the following may be displayed on the console.

This failure has been observed on the Hitachi 9990 (Genesis) arrays where the disk geometry data is being handled incorrectly by vxconfigd, resulting in the indicated message during vxdctl enable or vxconfigd startup. This message does not affect VxVM's use of the array. [Sun Bug ID 6221005, 301931, 308975]

Error messages when IDE devices are discovered

When an internal Intelligent Drive Electronics (IDE) device is claimed, VxVM attempts to obtain geometry data for the device using SCSI commands, which results in error messages being displayed:

These messages can be ignored as no data is lost, and VxVM claims the device correctly. [Sun Bug ID 6222054, 308336]

S-VOL devices on HDS with TrueCopy enabled

When using HDS with True Copy enabled, the primary devices (P-VOL) and their mirrors (S-VOL devices) are both seen in vxdisk list output. The P-VOL devices are available for import but the S-VOL devices are not available for import. Do not try to use S-VOL devices even though they appear in the vxdisk list output. [300979]

Hot-relocation issues

Impact of hot-relocation on performance

Except for rootvol and swapvol, the hot-relocation feature does not guarantee the same layout of data or performance after relocation. It is therefore possible that a single subdisk that existed before relocation may be split into two or more subdisks on separate disks after relocation (if there is not enough contiguous space on a single disk to accommodate that subdisk). [14894]

Disk information in notification messages

When a disk failure occurs, the hot-relocation feature notifies the system administrator of the failure and any relocation attempts through electronic mail messages. The messages typically include information about the device offset and disk access name affected by the failure. However, if a disk fails completely or a disk is turned off, the disk access name and device offset information is not included in the mail messages. This is because VxVM no longer has access to this information. [14895]

DMP issues

I/O is not restored on a path

If a path is re-enabled after a failback or a non-disruptive upgrade (NDU) operation, I/O may not be restored on that path. To unblock I/O on the path, run the vxdiskscandisks command. [617331]

DMP obtains incorrect serial numbers

DMP cannot obtain the correct serial number for a device if its LUN serial number contains a comma (,). This problem has been seen on EMC Symmetrix arrays with more than 8096 LUNs. [611333]

Disabling switch ports can cause I/O failures

Disabling the switch ports on the secondary paths to an A/P array can cause I/O failures on the primary path. This is because a fabric reconfiguration can take some time to stabilize depending on the complexity of the SAN fabric. Running the vxdiskscandisks command returns the primary paths to the enabled state. [607996]

Failure of mirroring with A/PF arrays

Mirroring a volume by using option 6 to the vxdiskadm command fails if the device discovery layer chooses a secondary path to a device in an A/PF array. There is no known workaround for this issue. [603164]

Event source daemon can dump core

Under rare circumstances, the event source daemon (vxesd) can produce a core dump. [593076]

Default I/O policy

The default I/O policy for Active/Active (A/A) arrays has been changed from balanced to minimumq. The default I/O policy for Asymmetric Active/Active (A/A-A) and Active/Passive (A/P) arrays has been changed from singleactive to round-robin.

Cluster functionality issues

Failure to detach a bad plex

If the cluster detach policy is set to global, and a non-mirrored volume experiences a disk media failure, the disk is not shown as failed and the volume is not disabled. However, I/O requests fail. [521182]

Node rejoin causes I/O failures with A/PF arrays

A cluster node should not be rejoined to a cluster if both the primary and secondary paths are enabled to an A/PF array, but all the other nodes are using only the secondary paths. This is because the joining node does not have any knowledge of the cluster configuration before the join takes place, and it attempts to use the primary path for I/O. As a result, the other cluster nodes can experience I/O failures and leave the cluster.

Workaround

1. Before joining the node to the cluster, disconnect the cable that corresponds to the primary path between the node and the A/PF array.
2. Check that the node has joined the cluster by using the following command:

# vxclustadm nidmap

The output from this command should show an entry for the node.

3. Reconnect the cable that corresponds to the primary path between the node and the array.
4. Use the following command to trigger cluster-wide failback:

# vxdisk scandisks

All the nodes should now be using the primary path.

[579536]

Volume persists in SYNC state

If a node leaves the cluster while a plex is being attached to a volume, the volume can remain in the SYNC state indefinitely. To avoid this, after the plex attach completes, resynchronize the volume manually with the following command:

# vxvol -f resync volume

[Sun Bug ID 4087612; 20448]

RAID-5 volumes

VxVM does not support RAID-5 volumes in cluster-shareable disk groups.

File systems supported in cluster-shareable disk groups

The use of file systems other than Veritas Storage Foundation Cluster File System (SFCFS) on volumes in cluster-shareable disk groups can cause system deadlocks.

Reliability of information about cluster-shareable disk groups

If the vxconfigd program is stopped on both the master and slave nodes and then restarted on the slaves first, VxVM output and VEA displays are not reliable until the vxconfigd program is started on the master and the slave is reconnected (which can take about 30 seconds). In particular, shared disk groups are marked disabled and no information about them is available during this time. The vxconfigd program must therefore be started on the master first.

Messages caused by open volume devices

When a node terminates from the cluster, open volume devices in shared disk groups on which I/O is not active are not removed until the volumes are closed. If this node later joins the cluster as the master while these volumes are still open, the presence of these volumes does not cause a problem. However, if the node tries to rejoin the cluster as a slave, this can fail with the following error message:

cannot assign minor #

This message is accompanied by the console message:

WARNING:minor number ### disk group group in use

Remote Mirror issues

Volume relayout

Volume relayout is not supported for site-confined volumes or for site-consistent volumes in this release. [528677]

Setting site consistency on a volume

The vxvol command cannot be used to set site consistency on a volume unless sites and site consistency have first been set up for the disk group. [530484]

Adding a remote mirror

Adding a remote mirror to a new site for a site-consistent volume does not also create a DRL log plex or a DCO plex at that site. The workaround is to use the vxassistaddlog command to add a DRL log plex, or the vxsnap command to add a version 20 DCO plex at the specified site (site=sitename). [533208]

Replacing a failed disk

It is not possible to replace a failed disk while its site is detached. You must first reattach the site and recover the disk group by running these commands:

# vxdg -g diskgroup reattachsite sitename

# vxrecover-g diskgroup

The vxdiskadm command gives an error when replacing disk on which the site tag had been set. Before replacing such a failed disk, use the following commands to set the correct site name on the replacement disk:

# vxdisk -f init disk

# vxdisk settag disk site=sitename

[536853, 536881]

Reattaching a site

Reattaching a site when the disks are in the serial-split brain condition gives an error message similar to the following if the -ooverridessb option is not specified:

Use the following commands to reattach the site and recover the disk group:

# vxdg -g diskgroup -o overridessb reattachsite sitename

# vxrecover-g diskgroup

[540351]

Site records are not propagated during disk group split, move or join

Split, join and move operations fail on a source disk group that has any site-confined volumes. This is because site records cannot be propagated to a target disk group during such operations.

One of the following messages is displayed as a result of a failed disk group split, join or move operation:

The suggested workaround is to ensure that allsites=off is set on all the volumes that are being moved between disk groups:

1. Run the following command on each of the volumes that is being moved split or joined to find out if allsites=on is set on any of them.

   # vxprint -g diskgroup -F %allsites volume

2. Run the following command on each of the volumes with allsites=on set that you found in the previous step.

   # vxvol -g diskgroup set allsites=off volume

3. Proceed with the disk group split, join or move operation.

[563524]

Restoring site records

The vxmake command can be used to recreate a disk group configuration, but not to restore site records. After restoring a disk group configuration, use the following command to recreate the site records manually:

# vxdg -g diskgroup addsite site

[584200]

Snapshot and snapback issues

Using snapshots as root disks

It is recommended that you do not use snapshots of the root volume as a bootable volume. A snapshot can be taken to preserve the data of the root volume, but the snapshot will not be bootable. The data from the snapshot would have to be restored to the original root volume before the system could be booted with the preserved data.

Warning message when taking a snapshot of an SFCFS file system

When taking a snapshot of an SFCFS file system, the following warning message might appear:

vxio: WARNING: vxvm:vxio: Plex plex detached from volume vol

Workaround: No action is required. This behavior is normal and is not the result of an error condition.

File system check of a snapshot

Normally, a file system would have no work to do when a snapshot is taken. However, if a CFS file system is not mounted, it is likely that the fsck of the snapshot will take longer than is usually necessary, depending on the I/O activity at the time of the snapshot.

Workaround: When taking a snapshot of a CFS file system, you should ensure that at least one of the volumes defined in the command line is mounted on the CVM master.

Mount operation can cause inconsistencies in snapshots

Inconsistencies can arise in point-in-time copies if a snapshot administration operation is performed on a volume while a file system in the volume is being mounted.

Space-optimized snapshot creation fails

Using the vxsnapmake command to create a space-optimized snapshot of a volume can fail if a large amount of I/O is active on the volume. The following error is displayed:

The command succeeds if I/O is suspended while the snapshot is created. [606613]

Cache volumes in volume sets

Do not add cache volumes (used by space-optimized instant snapshots) to volume sets. This causes data corruption and system panics.

[614061, 614787]

Intelligent Storage Provisioning issues

Creating application volumes

To create application volumes successfully, the appropriate licenses must be present on your system. For example, you need a full Veritas Volume Manager license to use the instant snapshot feature. Vendors of disk arrays may also provide capabilities that require special licenses for certain features of their hardware. [Sun Bug ID 4948093, i137185]

Number of columns in a RAID-5 ISP volume

If an ISP volume is created with the RAID-5 capability, the parameters ncols and nmaxcols refer only to the number of data columns, and do not include the parity column. For this reason, the number of columns that are created in such a volume is always one more than the number specified. [Sun Bug ID 4976891]

Miscellaneous issues

Disks with write-back caches

Disk drives configured to use a write-back cache, or disk arrays configured with volatile write-back cache, exhibit data integrity problems. The problems occur after a power failure, SCSI bus reset, or other event in which the disk has cached data, but has not yet written it to non-volatile storage. Contact your disk drive or disk array manufacturer to determine whether your system disk drives use a write-back cache, and if the configuration can be changed to disable write-back-caching.

Auto-import of disk groups

If a disk that failed while a disk group was imported returns to life after the group has been deported, the disk group is auto-imported the next time the system boots. This contradicts the normal rule that only disk groups that are (non-temporarily) imported at the time of a crash are auto-imported.

If it is important that a disk group not be auto-imported when the system is rebooted, the disk group should be imported temporarily when the intention is to deport the disk group (for example, in HA configurations). Use the -t flag to vxdgimport. [13741]

Volumes not started following a reboot

During very fast boots on a system with many volumes, vxconfigd may not be able to auto-import all of the disk groups by the time vxrecover-s is run to start the volumes. As a result, some volumes may not be started when an application starts after reboot.

Workaround: Check the state of the volumes before starting the application, or place a sleep (sleepsec) before the last invocation of vxrecover. [14450]

Forcibly starting a volume

The vxrecover command starts a volume only if it has at least one plex that is in the ACTIVE or CLEAN state and is not marked STALE, IOFAIL, REMOVED, or NODAREC. If such a plex is not found, VxVM assumes that the volume no longer contains valid up-to-date data, so the volume is not started automatically. A plex can be marked STALE or IOFAIL as a result of a disk failure or an I/O failure. In such cases, to force the volume to start, use the following command:

# vxvol -f start volume

However, try to determine what caused the problem before you run this command. It is likely that the volume contents need to be restored from backup, and it is also possible that the disk needs to be replaced. [14915]

Failure of memory allocation

On machines with very small amounts of memory (32 megabytes or less), under heavy I/O stress conditions against high memory usage volumes (such as RAID-5 volumes), a situation occurs where the system can no longer allocate pages of physical memory.

Using long device paths with Sun Online:Backup

The Sun Online:Backup^TM facility does not accept the long device path names for volumes. A limitation of Online: Backup is that it does not accept device paths longer than 24 characters.

Workaround: Use symbolic links to the longer /dev/vx/dsk/volname paths from a shorter path name.

Messages about Veritas Volume Replicator licenses

The following messages may get displayed on the console during a system reboot or during VxVM initialization when you are running vxinstall:

No VVR license installed on the system; vradmind not started

No VVR license installed on the system; in.vxrsyncd not started

These messages are informational only, and can be safely ignored if you are not a Veritas Volume Replicator user.

Solaris Issues

Dynamic Tracing Function Boundary Tracing probes

Dynamic Tracing (DTrace) Function Boundary Tracing (FBT) probes are not supported with the vxio driver. This is because of a limitation in Solaris 10 that such probes cannot handle modules with a text size larger than 2MB. The following error message is generated on the console as a result of using DTrace FBT probes with the vxio driver:

fbt: WARNING: couldn't allocate FBT table for module vxio

These messages are harmless, and can be safely ignored.

Number of inodes required in the root file system

The default maximum number of inodes in a UFS file system depends on the size of the file system. Once a UFS file system has been created, you cannot change the number of inodes without re-creating the file system. On a system with a large number of LUNs, the root file system can run out of inodes. This causes errors to be seen both from the operating system and from Veritas Volume Manager. As a general rule, the number of inodes thatDMP creates for every LUN is 16 times the number of separate paths to the device. For example, 8,000 LUNs connected over 2 paths would require 256,000 additional inodes. [538039]

Compatibility of kernel drivers

The versions of the kernel drivers for VxVM are incompatible with some versions of the Solaris operating system. Multiple kernel modules are installed and properly maintained by the installation and upgrade software. It is possible for a mismatch to occur (for example, if the administrator moves the kernel driver files). If a mismatch occurs, the VxVM kernel prints a warning message on the console similar to the following message:

WARNING: vxio: incompatible kernel version (5.X), expecting 5.X

If this message is displayed, the system must be booted for recovery (as explained in the Veritas Volume Manager Troubleshooting Guide) and the correct kernel modules installed. To install the correct kernel module versions, cd to the kernel/drv directory of the mounted root file system. To list the VxVM kernel modules, use the following command:

# ls -l vxio* vxspec* vxdmp*

The release-specific versions of the kernel modules are stored as module.OS_release, where OS and release are the result of running the uname -s and uname -r commands on the system, respectively.

For example, on a misconfigured system running Solaris 2.6, the listing for vxio* may be similar to the following:

-rw-r--r-- 1 root other 1682424 ... vxio

-rw-r--r-- 1 root sys 1647664 ... vxio.SunOS_5.7

-rw-r--r-- 1 root sys 1661340 ... vxio.SunOS_5.8

-rw-r--r-- 1 root sys 1682424 ... vxio.SunOS_5.9

The size of the vxio kernel module that is in use matches the vxio.SunOS_5.8 version. To correct the problem, copy the SunOS_5.6 versions to the in-use module name:

# cp vxio.SunOS_5.6 vxio

Finally reboot the system. [13312]

Encapsulation of swap partitions

During encapsulation, VxVM does not consider a partition to be a swap partition unless its partition tag (as shown by prtvtoc) is swap or 3. Any partition used as a swap partition but not tagged as such is encapsulated as a file system. In the vfstab file, a note is made that the partition has been encapsulated, but the vfstab entry is not translated, and thus, the partition is not added as a swap area as part of the boot process. All partitions that are to be used as swap devices must be marked with the swap tag to be properly encapsulated. [13388]

Protection of block 0 on disks

Since the disk label is stored in block 0 of the disk, block 0 must not be used (that is, no application should write any information in block 0). Special protection has been built into VxVM to protect block 0 from being overwritten.

Definition of disk slice 2

On Solaris, slice 2 of a non-EFI disk is the full disk by default. When finding connected disks, VxVM checks slice 2 of a disk. Slice 2 on a disk must always be defined as the full disk slice with a tag of 0x05.

Messages caused by long swap volume names

If multiple swap partitions are encapsulated on your disks, VxVM names them as swapvol, swapvol1, swapvol2, and so on. When the system is rebooted, the following error message is displayed:

/dev/vx/dsk/swapvol2 : Overlapping swap files are not allowed

However, the swap devices are correctly added with no ill effects on the system. To avoid seeing this message, shorten the names of swap volumes (other than swapvol) from swapvoln to swapn.

Veritas Enterprise Administrator issues

Note Refer to the Veritas Storage Foundation Installation Guide for information on how to set up and start the VEA server and client.

Controller states

Controller states may be reported as 'Not Healthy' when they are actually healthy, and 'Healthy' when they are actually not healthy. [599060]

Remote Mirror (campus cluster)

There is no option to create site-based snapshots. [541104]

Action pull-down menu items

No Action pull-down menu items exist for the Layout View, the Disk View or the Volume View. [596284]

Java exception error in the Statistics View

A Java exception error occurs in the Statistics View. [618146]

Out of bounds exception error

When connecting to the central host, an 'OutOfBoundException' error occurs. [616661]

Volume tags not displayed

On Microsoft Windows systems, existing volume tags are not displayed when adding a new volume tag. [602953]

Cache volumes shown as available for volume sets

The volume set creation wizard shows cache volumes in the 'Available Volumes' list. Cache volumes should not be listed as available. Including cache volumes in volume sets can cause data corruption and system panics. [614761]

Storage Agent dumps core if there are many LUNs

Configurations with more than 10240 LUNs can cause the Storage Agent to dump core in the directory /var/vx/isis. [584092]

Workaround

1. Rename the Device Discovery Layer (DDL) library file:

   # mv /opt/VRTSddlpr/lib/ddl.so /opt/VRTSddlpr/lib/ddl.so.orig

   This prevents the DDL provider from loading, but has the effect of making enclosure, path and controller objects no longer available in the VEA client GUI.

2. Restart the Storage Agent:

   # /opt/VRTSobc/pal33/bin/vxpal -a StorageAgent

Maximum alert log and task log file sizes

The default maximum size for each of the alert and task log files is 1953K. The maximum configurable size is 99999999K. Before increasing the maximum file size, ensure there is sufficient space available. Performance is not an issue with very large file size. [578688]

Disk group creation failure with a duplicate disk ID

VEA fails to create a disk group that contains a duplicate disk ID, and gives no other options.
[Sun Bug ID 4923820]

Printing errors from VEA on Windows 2000 Service Pack 2

When a user tries to print the volume layout view from VEA, the print is not clear.

Workaround: Upgrade the printer device driver to 0.3.1282.1 and install Service Pack 3. Upgrade to the latest version of VEA and print again. [286476]

Veritas Volume Manager Web GUI issues

Managing a Solaris X64 platform host

It is not possible to use the Web GUI to manage a Solaris X64 host that is running under Veritas Storage Foundation 4.1. [615554]

Creating a file system on a disabled volume

Creating a file system on a disabled volume returns both success and failure messages. In fact, the operation fails. [565072]

Maximum size of a volume

The maximum size of a volume is shown as a rounded-down integer number of gigabytes. If the maximum size is less than 1GB, the maximum size is shown as 0GB. [573897]

Creating a volume without an existing disk group

Attempting to create a volume without an existing disk group produces the following misleading error:

Info V-46-1-300 No Volume available to create a file system

[574410]

Disabling paths to SENA storage arrays

Disabling a path to a SENA storage array produces the following dialog:

pathname is the last path to its root disk. Are you sure you want

to disable it?

The message is erroneous, and it is safe to continue the operation. [575262]

Failures when importing disk groups

Messages about failures to import disk groups are not displayed by the Web GUI. [596648]

Failures when creating ISP volumes

Messages about failures to create ISP volumes are not displayed by the Web GUI. [601157]

All Active Alerts View

The All Active Alerts View does not display correct information. [601167]

Deleting an active cache volume

Attempting to delete an active cache volume fails with an error message that is incomplete. [615395]

Veritas Software Scsi & Raid Devices Driver Download For Windows 10

Corrupted import disk group dialog

If some objects are not present, the import disk group dialog may be displayed as blank or may show the text <!--td align='center' height='287' valign='midd'. For example, this can occur when attempting to import a disk group from a host that is being rebooted. [607096]

Initializing a disk

At least one object must be selected in the GUI before proceeding to initialize a disk. [607026]

Veritas Storage Foundation Basic soft limitation messages

Messages about exceeding the Storage Foundation Basic soft limitations are not displayed by the Web GUI. [619039]

Create disk group wizard

The create disk group wizard shows internal disks as being available for the creation of shared disk groups. [574717]

Object not found error on creating a volume set

An 'object not found error' may be displayed when a volume set is created. [615960]

Java exception when deleting a volume

Deleting a volume that has just been deleted produces a Java exception. This can happen if you do not wait for the Web page to be refreshed after the first delete operation. [608573]

Message when forcibly removing a volume from a volume set

Forcibly removing a volume from a volume set displays a message that recommends that the force option be selected. [605468]

Java exception when removing a volume from a volume set

Removing a volume from a volume set returns an incorrect Java exception on success. [564455]

Error message when removing a disk from a disk group

Removing a disk from a disk group gives the incorrect error message 'no valid disk selected.' [611894]

Disconnecting a disk produces a ghost entry

Ghost entries for disconnected disks in the All Disks View cannot be removed by using the GUI. A command such as vxdg-gdiskgrouprmdiskdiskname must be used instead. [576794]

Upgrading disk group versions

All disk groups have a version number associated with them. Each VxVM release supports a specific set of disk group versions and can import and perform tasks on disk groups with those versions. Some new features and tasks work only on disk groups with the current disk group version, so you need to upgrade existing disk groups before you can perform the tasks. The following table summarizes the disk group versions that correspond to each VxVM release from 2.0 forward:

If you want to take advantage of the new features in this release, you must upgrade the Veritas Cluster Volume Manager (CVM) protocol Version (70), and upgrade to the latest disk group version (140).

Use the following command to find the version of a disk group:

# vxdg list diskgroup

You can also determine the version by using the vxprint(1M) command with
the -l option.

To upgrade a disk group to Version 140, use the following command:

# vxdg upgrade diskgroup

For shared disk groups, the latest disk group version is only supported by the latest cluster protocol version. To see the current cluster protocol version, type:

# vxdctl support

To upgrade the protocol version for the entire cluster, enter the following command on the master node:

# vxdctl upgrade

See the 'Administering Cluster Functionality' chapter of the Veritas Volume Manager Administrator's Guide.

Available controllers not shown

The Scan Disks By Controller View does not list the available controllers. [566619]

Warning messages about exceeding SF Basic limitations are not propogated to Web GUI

When the SF Basic limitations are exceeded, the warning message regarding this is sent to the task log, not to the GUI. This only occurs if a volume is successfully created. [619039]

Veritas Software Scsi & Raid Devices Driver Download For Windows Xp

Veritas Software Scsi & Raid Devices Driver Download For Windows 8.1

Veritas Technologies LLC. is an American international data management company headquartered in Santa Clara, California. The company has its origins in Tolerant Systems, founded in 1983 and later renamed Veritas Software. It specializes in storage management software including the first commercial journaling file system, VxFS, VxVM, VCS, the personal/small office backup software Backup Exec and the enterprise backupsoftware, NetBackup. Veritas Record Now was an early CD recording software.

Prior to merging with Symantec (now known as NortonLifeLock) in 2004, Veritas was listed on the S&P 500 and the NASDAQ-100 under the VRTS ticker symbol.

In 2014, Symantec announced that it would demerge its information management business as Veritas Technologies LLC, in order to focus on security. It was purchased as part of the demerger by the private equity firmThe Carlyle Group for $8 billion in cash.

History[edit]

Early history[edit]

The company was founded by Eli Alon and Dale Shipley (both from Intel) as Tolerant Systems in 1983 to build fault-tolerant computer systems based on the idea of 'shoe box' building blocks. The shoe box consisted of an OS processor, running a version of Unix called TX, and on which applications ran, and an I/O processor, running a Real Time Executive, developed by Tolerant, called RTE: both processors were 320xx processors. The system was marketed as the 'Eternity Series.'

The TX software gained a level of fault-tolerance through check-pointing technology. Applications needed to be fortified with this check-pointing to allow roll-back of the application on another processor if a hardware failure occurred. Tolerant also developed a forerunner of today's RAID systems by incorporating a journaling file system and multiple copies of the disk drive content.

Dale Shipley formed Tolerant Software in January 1988. Tolerant Software produced a journaling file system and a virtual disk management system for the AT&T UNIX platform, which was built by a new team led by John Carmichael.

The firm started out with a relationship with AT&T to provide the file (Veritas File Manager – VxFS) and disk management (Veritas Volume Manager – VxVM) software for its UNIX operating system, and to jointly market and support the products to the System OEMS (Sun, HP, etc.). The OEM model provided royalties to Veritas when the OEM shipped its products to end users.

On December 9, 1993 the company had its initial public offering (IPO), selling 16 million shares to the public, and valuing the company at $64 million.

Growth and Acquisitions[edit]

At the end of 1996, Veritas had revenues of $36 million.

• Tidalwave Technologies Acquisition: In 1995 the company acquired Tidalwave Technologies, a small San Francisco-based company for $4.2 million in stock. Tidalwave specialized in cross-platform High Availability (HA) Software and thus entered the HA business.
• OpenVision Acquisition: In 1997 the company acquired OpenVision Technologies, another public company of the same size, and thus entered the backup business. Although the company only retained $20 million of OpenVision's 1996 base, it completed the 1997 year at $120 million. It was during this high growth period that the Veritas Board decided to consolidate the various business locations into a 550,000 SF facility in Mountain View, CA. Ernst & Young Consultants led by David Bentley as the project manager were brought in to lead this effort and soon hired HOK as the architect and Rudolf and Sletten as the general contractor. The new facility was completed in 2000.
• Seagate NSMG Acquisition: The company achieved $200 million in 1998, and in 1999 acquired the backup business from Seagate Software, which was also approximately $200 million in 1998. In 1999 the combined company achieved revenues of $700 million, and became the undisputed leader in the Storage Management Software industry. In 2000 the company achieved revenues of $1.2 billion, was added to the S&P 500, became a Fortune 1000 company, and became the tenth largest software company in the world by revenues, and third largest by market capitalization.
• Internet Bubble: In 2001 the industry went through a major downturn as the internet bubble burst. Nonetheless the company was able to achieve revenue growth of 25% to $1.5 billion, and operating margins of 25%.
• Growth of 42X: Through this accelerated growth, Veritas went from a $36 million company to a $1.5 billion company, a growth multiple of 42X in five years.
• April 1997 – Acquired OpenVision Technologies. This included NetBackup.
• May 1999 – Acquired the Network and Storage Management Group of Seagate Software. This included Backup Exec.
• August 2003 – Acquired Israel's Precise Software Solutions, one of the Application Performance Management (APM) leaders,^[1] for about $400 million in cash and 7.4 million shares of its stock for a total of about $609 million.^[2]

2004–2014: Merger with Symantec[edit]

On December 16, 2004, Veritas and Symantec announced their plans for a merger in a deal valued at $13.5 billion. The deal created the fourth-largest software firm in the world to date.^[3] Veritas and Symantec's shareholders approved the merger on June 24, 2005, and it was completed on July 2.

2014–2016: Demerger[edit]

On October 10, 2014, Symantec announced it planned to split the company into two parts.^[4] The security business would remain with Symantec, and the information management business would be known as Veritas Technologies Corporation. The separation of the companies was completed on January 29, 2016.^[5]

Veritas Software Scsi & Raid Devices Driver Download For Windows 7

On August 11, 2015, Symantec announced the sale of its Veritas information management business to The Carlyle Group.^[6] Veritas and Symantec achieved operational separation on October 1, 2015. The sale completed on January 30, 2016, when Veritas became a privately held company.^[6][7] The sale to go private was for $8 billion, and represented a mark-down on Symantec stock.^[8]

2016: The New Beginning[edit]

After the demerger from Symantec in 2016, Veritas rebranded itself as Veritas Technologies LLC. with a new logo. As CEO, Bill Coleman was able to transform the company to have 'a startup, win-in-the-marketplace, customer-first culture' during the two-year turnaround.^[9] On January 28, 2018, Veritas Technologies LLC. named Greg Hughes as its CEO.^[10] With a new brand and a new CEO, Veritas Technologies planned to move its employees to its new headquarters in Santa Clara by the end of summer 2018.^[11] In September 2020, Veritas Technologies LLC acquired Los Angeles-based software company Globanet.^[12]

Products & Services[edit]

• Access
• VxFS and VxVM
• NetBackup Appliances
• Cluster Server (VCS)
• Enterprise Vault.cloud
• Enterprise Administrator
• Volume Replicator (VVR)
• SANPoint
• eDiscovery Platform
• APTARE IT Analytics™
• CloudPoint
• SaaS Backup
• Desktop and Laptop Option
• Flex Appliance
• Information Studio
• Data Insight
• Veritas Infoscale, data management such as HyperScale for OpenStack
• Resiliency Platform

Lawsuits[edit]

In 1999, VERITAS Software Corp. (VERITAS US) and VERITAS Ireland entered into a cost-sharing agreement (CSA) which was the subject of litigation with the U.S. Internal Revenue Service.^[13]

See also[edit]

• Veritas Services and Operations Readiness Tools (SORT)

References[edit]

1. ^'Veritas Buys Pair of Software Firms'. eWeek. 2002-12-19.
2. ^Boulton, Clint (June 30, 2003), 'Veritas Closes Precise Software Purchase', InternetNews.com, retrieved 2009-11-03
3. ^https://www.ecommercetimes.com/story/39030.html
4. ^Robertson, Jordon (Oct 10, 2014), 'Symantec to Split Into Storage, Security Companies', Bloomberg, retrieved 2014-10-10
5. ^corporate press release, Symantec and The Carlyle Group Plan to Close Acquisition of Veritas January 29, 2016, retrieved 2016-01-03
6. ^ ^abcorporate press release, Symantec to Separate Into Two Focused, Industry-Leading Technology Companies, retrieved 2015-08-12
7. ^corporate press release, Symantec and Veritas separation(PDF), retrieved 2016-02-15
8. ^Preimesberger, Chris (Aug 11, 2015), Veritas Goes Private for $8 Billion Following Split from Symantec, retrieved 2017-03-23
9. ^'Veritas taps new CEO, saying two-year turnaround is complete – SiliconANGLE'. SiliconANGLE. 2018-01-08. Retrieved 2018-05-04.
10. ^Technologies, Veritas. 'Veritas Names Greg Hughes as Chief Executive Officer'. www.prnewswire.com. Retrieved 2018-05-04.
11. ^'Veritas moving headquarters, hundreds of workers, to Santa Clara'. The Mercury News. 2017-11-20. Retrieved 2018-05-04.
12. ^'Veritas Acquires Globanet, Extending Its Leading Digital Compliance Portfolio'. finance.yahoo.com. Retrieved 2020-09-29.
13. ^https://scholar.google.com/scholar_case?case=17681094442401642589&q=Veritas+Software+Corp.+v.+Commissioner,&hl=en&as_sdt=6,48&as_vis=1

External links[edit]