How to increase the size of vxdisk,volume, and filesystem following lun addition or expansion

— ny_wk

To resize a VxVM disk, volume and VxFS filesystem after a SAN team adds or expands a LUN, you either initialize the new disk and add it to the disk group (new LUN) or resize the existing VxVM disk in place (expanded LUN), then grow the volume and filesystem in one step with vxresize. On a Veritas Cluster Server (VCS) node you must freeze the service group first so the cluster does not react to the storage change. This guide walks through both scenarios end to end with the exact commands, the safety checks that prevent data loss, and the verification that proves the new space is live.

Growing storage on Veritas Volume Manager (VxVM) is one of the most common tasks for a Unix or Linux storage administrator, and it is also one of the easiest to get wrong. Skip a backup, run a resize on the wrong disk group, or forget to rescan the passive node, and you can take an application offline at exactly the moment it needs more space. The procedure below is the safe, repeatable way to do it.

Understanding the storage stack before you resize VxVM

Before touching anything, it helps to picture how the layers sit on top of each other. Capacity flows up from the array to the application through four distinct layers, and a clean resize touches each one in order.

• LUN — the block device presented by the storage array (EMC, Hitachi, Pure, etc.). The storage engineer either presents a brand-new LUN or grows an existing one.
• Multipath device — software such as EMC PowerPath (emcpowerNN) or native dmp/multipath aggregates the multiple SAN paths into one pseudo device.
• VxVM disk and disk group — VxVM labels the device (cdsdisk format), names it inside a disk group such as datadg, and carves volumes from the pooled free space.
• VxFS filesystem and volume — the Veritas File System (VxFS) that the application actually reads and writes, mounted on a path like /var/data.

There are two genuinely different jobs hiding under the phrase "add more space." Case 1 is a brand-new LUN: you initialize it and add it as a new VxVM disk. Case 2 is an expanded LUN: the existing device simply got bigger and you grow the VxVM disk in place. The volume and filesystem growth step is identical for both.

Pre-flight checklist: never resize VxVM without these backups

Capacity changes are low-risk only when you can roll back. On a clustered pair, run these on both nodes and save the output before you change anything.

1. Capture the multipath topology so you can map LUN IDs back to devices: powermt display dev=all (PowerPath) or vxdmpadm getsubpaths for native DMP.
2. Capture the full VxVM configuration of the affected disk group: vxprint -rth -g datadg. This records every disk, plex and subdisk layout.
3. Record current usage so you can prove the before/after delta: df -h /var/data.
4. Note the disk group name, the volume name, and the mount point. Confirm them — a resize against the wrong disk group is the classic outage.

Match the LUN IDs your storage team gives you to local pseudo names so you are certain which devices are new. Two quick commands do this:

1. powermt display dev=all — lists every PowerPath device with its logical device ID and size.
2. echo | format | grep emcpower63 — confirms the OS sees the device (Solaris-style format; on Linux use fdisk -l or lsblk).

Build this table for your own LUNs. The pseudo name plus LUN ID is the unambiguous fingerprint you will reference at every later step.

Freeze the VCS service group before any storage change

If the host is part of a Veritas Cluster Server pair, the disk group, mount and application run as resources inside a service group. Initializing disks or resizing volumes while VCS is monitoring them can trigger an unwanted failover. Freeze the group so the cluster engine stops acting on resource state, but the application keeps running.

1. Freeze the group persistently so it survives a restart of the cluster engine:
   hagrp -freeze server-sg -persistent
2. Confirm the freeze and check which node owns the group:
   hastatus -sum

In the hastatus -sum output, the GROUPS FROZEN section should list server-sg, and the GROUP STATE section tells you which node holds it ONLINE. Do all the active work on that node — in this example, server1. The -persistent flag matters: a non-persistent freeze evaporates if had restarts mid-change.

Case 1: Add a brand-new LUN to a VxVM disk group

This is the path when the storage team presents entirely new devices. The goal is to take three raw emcpower devices, label them for VxVM, add them to datadg, and grow the volume into the new free space.

Step 1 — Confirm the new disks are visible and unlabeled

List the new devices and check their status:

1. vxdisk list | egrep "emcpower62|emcpower63|emcpower64"

A fresh, unowned disk shows TYPE auto with status nolabel and no disk group. That is exactly what you want — it confirms VxVM sees the hardware but nothing owns it yet, so initializing it is safe.

Step 2 — Identify the disk group that needs the space

Map the mount point to its volume and disk group so you grow the right thing:

1. df -h /var/data

The Filesystem column reads /dev/vx/dsk/datadg/datavol, which tells you the disk group is datadg and the volume is datavol. At 85% used on a 15 TB volume, this filesystem clearly needs the extra capacity.

Step 3 — Initialize each new disk in CDS format

Label each device as a cdsdisk (Cross-platform Data Sharing), the modern default that lets a disk group move between platforms:

1. vxdisk init emcpower62 format=cdsdisk
2. vxdisk init emcpower63 format=cdsdisk
3. vxdisk init emcpower64 format=cdsdisk
4. Re-check status: vxdisk list | egrep "emcpower62|emcpower63|emcpower64"

After initialization the TYPE changes to auto:cdsdisk and status flips to online. The devices are now valid VxVM disks but still belong to no disk group.

Step 4 — Add the disks to the disk group

First find the next free media name so your naming stays sequential. List existing members and note the highest number:

1. vxdisk -o alldgs list | grep datadg

If the last media name is datadg20, your new disks become datadg21, datadg22 and datadg23. Add each device — note you reference the partition name (s2 slice), not the bare pseudo name:

1. vxdg -g datadg adddisk datadg21=emcpower62s2
2. vxdg -g datadg adddisk datadg22=emcpower63s2
3. vxdg -g datadg adddisk datadg23=emcpower64s2
4. Verify membership: vxdisk -o alldgs list | grep datadg

The three new rows now show the datadg group with your chosen media names and an online status. The free space has joined the pool but no volume is using it yet.

Step 5 — Check how much you can grow and resize the volume

Ask VxVM for the maximum the volume can expand to within the disk group:

1. vxassist -g datadg maxsize

This returns a value in sectors, e.g. Maximum volume size: 4282972160 (2091295Mb). Now grow the volume and the VxFS filesystem in a single atomic operation with vxresize. The leading + means "add this many sectors" rather than "set total size to":

1. /etc/vx/bin/vxresize -F vxfs -g datadg datavol +4282972160

Why vxresize and not vxassist growby plus a manual fsadm? Because vxresize extends the volume and the filesystem together and keeps them consistent. The -F vxfs flag tells it the filesystem type so it can call the correct grow utility automatically.

Step 6 — Verify the new size on the active node

1. df -h /var/data

The volume should jump — in this example from 15 TB to 17 TB, with usage dropping from 85% to 75%. Capture this output as your proof of completion.

Step 7 — Unfreeze the service group

With the work done on the node that owns the group, release the freeze:

1. hagrp -unfreeze server-sg -persistent
2. hastatus -sum

The GROUPS FROZEN section should now be empty and the group fully ONLINE on its node. VCS is monitoring resources again.

Step 8 — Make the passive node discover the new disks

The standby node still has a stale view of the SAN. Log in to it and refresh VxVM's device tree so a future failover finds every disk:

1. vxdctl enable — rebuilds the VxVM device list from the OS.
2. vxdisk scandisks — rescans the storage for new or changed devices.
3. Confirm the new disks now appear: vxdisk -o alldgs list | grep datadg

Before the rescan the passive node will not list emcpower62/63/64; afterward they appear with the disk group shown in parentheses, e.g. (datadg), meaning the node sees the disks but the group is imported elsewhere. That is the correct state for a passive node.

Case 2: Resize an existing (expanded) LUN in VxVM

When the storage team grows a LUN that is already a VxVM disk, you do not add anything — you tell VxVM the device is now larger, then grow the volume into the reclaimed space. There is no vxdisk init and no vxdg adddisk here, and on a cluster you still freeze the service group first.

Step 1 — Grow the VxVM disk in place

VxVM caches the disk geometry, so it will not notice a bigger LUN until you tell it to re-read the size. The -f flag forces the resize:

1. Syntax: vxdisk -f -g <dg> resize <disk>
2. Example: vxdisk -f -g Cnv1 resize c13t1d0

Critical prerequisite: the OS and multipath layer must already see the larger device. If they do not, rescan the SCSI bus first (on Linux, echo 1 > /sys/block/sdX/device/rescan per path, then multipath -r or powermt display). VxVM cannot grow past what the kernel reports.

Step 2 — Confirm the disk media grew

Inspect the disk-media (dm) record in the disk group to confirm the new public-region length:

1. Syntax: vxprint -htg <dg>
2. Example: vxprint -htg Cnv1

The dm line for your disk should now show the larger size. If it has not changed, VxVM did not pick up the new geometry — recheck the OS-level rescan before going further.

Step 3 — Check available growth and resize

1. Check the headroom: vxassist -g Cnv1 maxsize
2. Grow volume and VxFS together: /etc/vx/bin/vxresize -F vxfs -g Cnv1 vol30 +104857600

The +104857600 adds that many 512-byte sectors (about 50 GB). You can also pass human-friendly units, e.g. +200g for 200 GB, which is far less error-prone than counting sectors.

Step 4 — Verify the filesystem

1. On Linux: df -h /your/mount
2. On HP-UX: bdf /your/mount

The mounted filesystem should reflect the new capacity immediately, because vxresize grows the live VxFS online — no unmount required.

Common pitfalls when you resize VxVM and VxFS

Most failed capacity changes trace back to a handful of avoidable mistakes. Watch for these.

• Forgetting to freeze the service group. On a VCS node, an unfrozen group can fault or fail over the moment a resource changes state during your work. Always freeze with -persistent and unfreeze only after verification.
• Resizing the wrong disk group or volume. Confirm with df -h before you touch anything. The vxresize command does not ask twice.
• Adding the bare device instead of the partition. Use emcpower63s2 (the slice/partition), not emcpower63, in vxdg adddisk.
• Skipping the OS rescan in Case 2. vxdisk resize cannot exceed what the kernel reports. Rescan every SAN path and refresh multipath first, or VxVM grows by zero.
• Never rescanning the passive node. If you forget vxdctl enable and vxdisk scandisks on the standby, the next failover can fail to import the disk group.
• Confusing sectors with bytes. maxsize and the +N argument are in 512-byte sectors. When in doubt, use suffixed units like +200g.
• Resizing a mirrored volume without enough matching free space. For mirrored layouts, each plex needs growth room; check vxassist maxsize for the actual layout, not the raw disk-group free space.

How to verify the VxVM resize succeeded

A clean job is one you can prove. Run this short verification pass on the active node, and confirm the device view on the passive node.

1. Filesystem capacity grew: df -h /var/data shows the new size and lower usage percentage.
2. Volume length matches: vxprint -g datadg datavol shows the expected number of sectors.
3. New disks are in the group: vxdisk -o alldgs list | grep datadg lists every member as online.
4. Cluster is healthy and unfrozen: hastatus -sum shows no frozen groups and all resources ONLINE.
5. Passive node sees the disks: after vxdctl enable; vxdisk scandisks, the new devices appear with (datadg) in parentheses.

If all five checks pass, the capacity is live, persistent, and safe across a failover.

A note on Veritas InfoScale and modern equivalents

Veritas Volume Manager and Veritas Cluster Server are now packaged together as Veritas InfoScale (formerly the Storage Foundation / SFHA suite, and the product line moved under Arctera in 2024). The commands above remain valid across recent InfoScale releases. On native Linux stacks without Veritas, the equivalent flow is LVM plus a filesystem grow: rescan the device, pvresize the physical volume, lvextend the logical volume, then resize2fs or xfs_growfs for the filesystem. The principles — backup, confirm the target, grow each layer in order, verify — are identical regardless of the volume manager.

Key Takeaways

• Always back up vxprint -rth and powermt display dev=all on both cluster nodes, and freeze the VCS service group with -persistent before any storage change.
• For a new LUN: vxdisk init format=cdsdisk → vxdg adddisk (use the s2 partition) → vxresize.
• For an expanded LUN: rescan at the OS layer, then vxdisk -f -g <dg> resize <disk> → vxresize.
• /etc/vx/bin/vxresize -F vxfs grows the volume and the VxFS filesystem together, online, in one consistent step.
• After unfreezing, run vxdctl enable and vxdisk scandisks on the passive node so a future failover finds every disk.

Frequently Asked Questions

What is the difference between vxresize and vxassist growby?

vxassist growby (or growto) only extends the volume; you would then have to grow the filesystem separately with fsadm. vxresize extends both the volume and the filesystem in a single atomic command, keeping them consistent, which is why it is the recommended tool for a VxFS volume.

Do I need to unmount the filesystem to resize a VxVM volume?

No. VxFS supports online resizing, so vxresize grows the live, mounted filesystem with no downtime. The application keeps running throughout — which is exactly why you freeze the VCS service group rather than taking it offline.

Why must I freeze the service group in a VCS cluster?

Veritas Cluster Server constantly monitors the disk group, mount and application resources. Initializing disks or resizing a volume can briefly change resource state, which an active cluster might interpret as a fault and trigger a failover. A persistent freeze tells VCS to leave the group alone while you work, then you unfreeze after verifying.

Why does the new disk not appear on the standby node automatically?

Each node maintains its own cached view of the SAN. The node that owns the disk group sees changes immediately, but the passive node needs vxdctl enable to rebuild its device tree and vxdisk scandisks to pick up the new LUNs. Until then, a failover could fail to import the enlarged disk group.

If this walkthrough saved you a maintenance window, subscribe to @explorenystream on YouTube for more Linux and Veritas storage how-tos.