Veritas InfoScale™ 7.4 Solutions Guide - Solaris
- Section I. Introducing Veritas InfoScale
- Section II. Solutions for Veritas InfoScale products
- Section III. Improving database performance
- Overview of database accelerators
- Improving database performance with Veritas Quick I/O
- About Quick I/O
- Improving database performance with Veritas Cached Quick I/O
- Improving database performance with Veritas Concurrent I/O
- Section IV. Using point-in-time copies
- Understanding point-in-time copy methods
- Backing up and recovering
- Preserving multiple point-in-time copies
- Online database backups
- Backing up on an off-host cluster file system
- Database recovery using Storage Checkpoints
- Backing up and recovering in a NetBackup environment
- Off-host processing
- Creating and refreshing test environments
- Creating point-in-time copies of files
- Section V. Maximizing storage utilization
- Optimizing storage tiering with SmartTier
- Optimizing storage with Flexible Storage Sharing
- Optimizing storage tiering with SmartTier
- Section VI. Migrating data
- Understanding data migration
- Offline migration from Solaris Volume Manager to Veritas Volume Manager
- How Solaris Volume Manager objects are mapped to VxVM objects
- Overview of the conversion process
- Planning the conversion
- Preparing a Solaris Volume Manager configuration for conversion
- Setting up a Solaris Volume Manager configuration for conversion
- Converting from the Solaris Volume Manager software to VxVM
- Post conversion tasks
- Online migration of a native file system to the VxFS file system
- Migrating a source file system to the VxFS file system over NFS v3
- VxFS features not available during online migration
- Migrating storage arrays
- Migrating data between platforms
- Overview of the Cross-Platform Data Sharing (CDS) feature
- CDS disk format and disk groups
- Setting up your system to use Cross-platform Data Sharing (CDS)
- Maintaining your system
- Disk tasks
- Disk group tasks
- Displaying information
- File system considerations
- Specifying the migration target
- Using the fscdsadm command
- Maintaining the list of target operating systems
- Migrating a file system on an ongoing basis
- Converting the byte order of a file system
- Migrating from Oracle ASM to Veritas File System
- Section VII. Veritas InfoScale 4K sector device support solution
Run convertname
The convertname utility takes Solaris Volume Manager device paths as arguments (metadevice paths or raw disk paths) and returns the VxVM volume path for the device as it will show after the conversion. Use the command to make a list of path names for replacing references in applications. One or more device paths as arguments returns one line for each argument with the proposed VxVM path. Use absolute path names. For example:
# convertname /dev/md/dsk/d2 /dev/md/rdsk/d3
Table: Examples of the translation of device path names shows examples of how names are translated by the conversion process:
Table: Examples of the translation of device path names
Metadevice path | VxVM volume path |
---|---|
/dev/md/dsk/d2 | /dev/vx/dsk/rootdg/d2 |
/dev/md/rdsk/d3 | /dev/vx/rdsk/rootdg/d3 |
/dev/md/setname/dsk/d10 | /dev/vx/dsk/setname/d10 |
/dev/md/setname/rdsk/d12 | /dev/vx/rdsk/setname/d12 |
The following metadevices do not retain their dN names or are converted from raw partitions that did not have dN names:
The volume for the root file system is always named rootvol as a VxVM convention.
A trans metadevice has its data device converted using the master device name. The log device is lost.
A file system encapsulated from a raw partition is named for the last component of its mount point.
A swap device on a disk that will include VxVM volumes after the conversion receives a name starting with swapvol.
The /usr, /opt, and /var file systems when converted from being Solaris Volume Manager metadevices or when encapsulated retain the names /usr, /opt, and /var.
Warning:
Any partition that is on a disk with Solaris Volume Manager metadevices and that is not listed as a file system in /etc/vfstab is lost during the conversion. The partition is considered free space when the disk is converted to VxVM control. Even if the partitions are in use, such as for Oracle raw tablespace data, they are not encapsulated during the conversion. The raw partitions are lost when the disk layout changes. Either encapsulate the partition under the Solaris Volume Manager software and allow the conversion to convert the resulting metadevice, or back up the partition, plan to create a new volume for it, and restore the partition after the conversion.