Volume Manager (VxVM)
The following notes and recommendations apply to the Volume Manager.
-
Disks with insufficient space (less than 1024 disk blocks) 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.
This size defaults to 1024 blocks.
A way to work around this is to 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 this 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 slice 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 slice.
There is no workaround to the problem of not having space on a disk to store
private VxVM information.
VxVM requires at least a small region of private storage (1024 blocks) for
proper disk identification.
-
The Volume Manager tracks disks using long unique identifiers that
VxVM stores on each disk.
VxVM expects each disk to have a different unique identifier, and does not
effectively guard against the situation where two disks have the same unique
identifier.
Duplicate identifiers should only occur as the result of the administrator
using dd or some other utility to perform physical copies of
the contents of an entire disk.
The only effective workaround is that the administrator should not do exact
physical disk copying.
-
It should be possible to prevent any access of a disk by VxVM.
For example, startup of VxVM could be severely impacted by a disk with
errors that result in I/Os that take a long time to fail.
However, when VxVM starts up, it accesses every disk on the system, by
reading its VTOC and possibly a few blocks from one partition.
There is currently no mechanism to prevent this.
A disk can be off-lined persistently, but the offline state is only
recognized after the probe of all disks.
-
RAID-5 cannot currently be mirrored or backed up online using any
mechanisms provided in VxVM.
-
The disk hot-sparing mechanism currently used in VxVM does not work
well for partial disk failures.
The model was written using the presumption that disks fail totally, rather
than partially, and that partial errors can usually be fixed by writing
back a failing sector (which is done automatically when using mirroring or
RAID-5).
Usually this is a good assumption, but some users have encountered situations
where only a few sectors failed and hot sparing did not occur.
-
On machines with low memory (32 megabytes or less), under heavy I/O
stress conditions against high memory usage volumes (that is, RAID-5
volumes), a situation occurred in which the system could not allocate
physical memory pages any more.
For example, such a situation may result when exercising heavy I/O stress
against RAID-5 volumes for 24 hours on a 32-megabyte machine.
-
UnixWare does not support raw interfaces for devices greater than 2 gigabytes.
-
VxVM assumes there are not more than 16 partitions defined on any disk VTOC.
It is assumed that the slices are s0 through s15.
-
Note that there is no protection built into vxassist to
prevent the user 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, this operation should be done
in single-user mode and the system should be rebooted immediately.
Failing to take these precautions could result in unknown system behavior
or lock-up.
-
Using vxdg free with a non-existent disk-media-name does not print
an appropriate error message.
It simply prints a header.
-
If you are mirroring your swap device, we recommend that you set aside a
dedicated dump slice to store possible system dumps.
Otherwise, the system may not detect the presence of a system dump on the
swap slice.
NOTE:
At least one disk must remain in the root disk group
(rootdg) while VxVM is running.
Upgrading SCO UnixWare 2.1 VxVM to UnixWare 7
You can preserve a
UnixWare 2.1 VxVM filesystem if it is not your
root or /usr filesystem.
To preserve a filesystem:
-
Ensure that the VxVM ODM packages are installed
and the filesystem is configured as you require it on the SCO UnixWare 2.1 system.
-
Mount the filesystem.
-
Create an s5 filesystem on a diskette as follows:
#
format /dev/rdsk/f03ht
#
mkfs -F s5 /dev/dsk/f03ht 2880
-
Mount the diskette and copy the necessary files and directories:
#
mount -Fs5 /dev/dsk/f0t /mnt
#
find /etc/vx/reconfig.d \
/etc/vx/tempdb \
/etc/vx/volboot \
/etc/vfstab | cpio -pd /mnt
-
Unmount the diskette and install UnixWare 7:
#
umount /mnt
CAUTION:
After the installation of UnixWare 7 do not perform a vxinstall.
-
Copy the files from the diskette back to the UnixWare 7 system:
#
mount -Fs5 /dev/dsk/f0t /mnt
#
cd /mnt
#
find etc/vx/reconfig.d \
etc/vx/tempdb \
etc/vx/volboot | cpio -pd /
Merge /mnt/vfstab and /etc/vfstab manually.
-
If the mountpoint used in SCO UnixWare 2.1 (in step 2) does not exist, create it:
#
mkdir mount_point
-
Remove the file /etc/vx/reconfig.d/state.d/install-db:
#
rm /etc/vx/reconfig.d/state.d/install-db
-
Reboot the system.
-
Mount the VxVM filesystem or volume:
#
mount /mount-point
Next topic:
Visual Administrator (VxVA)
Previous topic:
Software notes and recommendations
© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 22 April 2004