Migration of rootvg disk in vios with new disk

UNIX AIX
1

Vios server need to change rootvg disk with another storage disk

Please provide steps without alt clone and reboot vios

2

For fun in 2026, let''s quickly compare three LLMs replies to @vaibhav_suravkar question (prompt) above:

  • Claude. Sonnet 4.6
  • ChatGPT 5.5 Instant
  • Codex gpt-5.3-codex medium

Claude. Sonnet 4.6

Here are the steps to migrate rootvg to a new disk on VIOS without alt_clone and without a reboot, using alt_disk_copy or the manual mirrorvg method:

Method: mirrorvg then break the mirror

Prerequisites

  • New disk must be same size or larger than current rootvg disk
  • Know your current rootvg disk (e.g. hdisk0) and new disk (e.g. hdisk1)

Step 1 -- Verify current rootvg disk

lspv
lspv | grep rootvg

Step 2 -- Check new disk is clean

lspv hdisk1

Should show None for VG. If not, clear it:

chpv -C hdisk1

Step 3 -- Extend rootvg mirror to new disk

extendvg rootvg hdisk1

Step 4 -- Mirror rootvg to new disk

mirrorvg -S rootvg hdisk1

-S runs synchronization in background. Monitor sync progress:

lsvg rootvg | grep -i stale
lsvg -l rootvg

Wait until 0 stale PPs before proceeding.

Step 5 -- Verify sync is complete

lsvg rootvg

Confirm STALE PPs: 0

Step 6 -- Update bootlist to new disk

bootlist -m normal hdisk1
bootlist -m normal -o

Step 7 -- Remove old disk from rootvg mirror

unmirrorvg rootvg hdisk0

Step 8 -- Remove old disk from rootvg VG

reducevg rootvg hdisk0

Step 9 -- Clear the old disk (optional, good practice)

chpv -C hdisk0

Step 10 -- Verify final state

lspv
lsvg rootvg
lsvg -l rootvg
bootlist -m normal -o

Important Notes

  • No reboot required with this method -- VIOS stays live throughout
  • The mirrorvg -S flag is critical -- without -S it blocks until sync completes
  • Confirm LTG (Logical Track Group) alignment if disks are different vendors
  • On VIOS, run all commands as padmin with oem_setup_env if you need root-level LVM commands:
oem_setup_env
  • After reducevg, the old disk can be safely handed back to storage for reallocation

ChatGPT 5.5 Instant

Observe:

You want to migrate the active rootvg on IBM PowerVM VIOS from one SAN/storage-backed disk to another disk, without using alt_disk_copy / alt clone and without rebooting the VIOS.

This is essentially an online rootvg mirror migration using LVM mirroring.

Orient:

On VIOS/AIX, rootvg can be mirrored live across disks. After synchronization, the old disk can be removed from rootvg and boot records rewritten to the new disk.

Typical flow:

  • Add new SAN disk
  • Extend rootvg
  • Mirror all logical volumes
  • Sync
  • Make new disk bootable
  • Remove old disk
  • Reduce VG

No reboot required if done correctly.

Assumptions:

  • Existing rootvg disk = hdisk0
  • New storage disk = hdisk1
  • VIOS version supports standard AIX LVM commands
  • NPIV/vSCSI mappings unaffected

Decide:

Safest non-reboot method is standard live LVM mirroring using:

  • extendvg
  • mirrorvg
  • syncvg
  • bosboot
  • bootlist
  • unmirrorvg
  • reducevg

Act:

  1. Identify disks
ioscli lspv

Example:

hdisk0   00f6c1...   rootvg   active
hdisk1   none        None
  1. Verify new disk is clean
chdev -l hdisk1 -a pv=yes

If previously used:

chpv -C hdisk1
  1. Add new disk to rootvg
extendvg rootvg hdisk1
  1. Mirror rootvg online
mirrorvg -S rootvg hdisk1

Flags:

  • -S avoids syncing stale partitions immediately during command execution

This may take time.

  1. Sync and monitor
syncvg -v rootvg

Check status:

lsvg -l rootvg
lsvg -p rootvg

You want all LPs == PPs and no stale partitions.

  1. Make new disk bootable

On VIOS:

bosboot -ad /dev/hdisk1

Then update bootlist:

bootlist -m normal hdisk1

Verify:

bootlist -m normal -o
  1. Remove old disk from mirror
unmirrorvg rootvg hdisk0

Wait for completion.

  1. Remove old disk from VG
reducevg rootvg hdisk0
  1. Verify final state
lsvg -p rootvg

Expected:

rootvg:
PV_NAME   PV STATE   TOTAL PPs   FREE PPs   FREE DISTRIBUTION
hdisk1    active     ...
  1. Optional SAN cleanup

After verification:

rmdev -dl hdisk0

Notes:

  • Do NOT use migratepv for full rootvg migration on VIOS boot disks unless you specifically understand boot LV implications.
  • mirrorvg handles boot logical volumes correctly.
  • If using dual VIOS, do one VIOS at a time.
  • Ensure new disk size >= old rootvg used PPs.
  • If ODM/boot corruption concerns exist, run:
savebase

before and after migration.

Codex gpt-5.3-codex medium (CLI)

Use an online rootvg mirror migration (no alt_disk_copy, no immediate reboot).

  1. Log in to VIOS and enter root shell:

oem_setup_env

  1. Identify current rootvg disk and new target disk:

lsvg -p rootvg
lspv

  • Ensure new disk is free (None VG) and large enough for used PPs in rootvg.
  1. Add new disk to rootvg:

extendvg rootvg hdiskNEW

  1. Mirror rootvg to new disk:

mirrorvg rootvg hdiskNEW

  1. Sync and verify all LPs copied:

syncvg -v rootvg
lsvg -l rootvg
lsvg -p rootvg

  • Wait until stale partitions are 0.
  1. Make new disk bootable and set bootlist:

bosboot -ad /dev/hdiskNEW
bootlist -m normal hdiskNEW
bootlist -m normal -o

  1. Remove old rootvg disk copy:

unmirrorvg rootvg hdiskOLD
reducevg rootvg hdiskOLD
chpv -C hdiskOLD

  1. Final checks:

lsvg -p rootvg
lspv
bootlist -m normal -o

Notes:

  • This completes without reboot now.
  • The change is only fully proven at next reboot, so schedule a maintenance reboot later to validate boot
    from hdiskNEW.
3

Claude Evaluates the Three LLM Approaches Above:

Evaluation: Three LLM Replies on VIOS rootvg Migration

The task is non-trivial: a live, no-reboot rootvg migration on IBM PowerVM VIOS without alt_clone. This is a domain where accuracy, ordering, and omissions carry real operational risk.

Claude Sonnet 4.6

Strengths: Clean structure, correct core sequence, includes the oem_setup_env reminder (critical on VIOS where padmin is the default shell), and correctly flags the -S behavior note.

Weaknesses:

  • Omits bosboot -ad /dev/hdisk1 before bootlist. This is a significant omission -- bootlist alone does not write the boot record to the new disk. On AIX/VIOS, bosboot is required to make a disk actually bootable, not just listed.
  • The explanation of -S is backwards: -S actually means "synchronize" the stale partitions -- it does NOT skip sync. The note saying "without -S it blocks" reflects confusion about the flag semantics.
  • No mention of syncvg as an explicit verification step.
  • No savebase mention.

Grade: B- -- Good scaffold, but the missing bosboot and the -S mischaracterization are operationally significant errors.

ChatGPT 5.5 Instant

Strengths: Most complete response. Includes bosboot, syncvg, savebase, rmdev, and the dual-VIOS caution. The OODA-style framing (Observe/Orient/Decide/Act) is unusual but actually works well for a structured runbook. The migratepv warning is a legitimate and useful callout. Flags LP == PP verification explicitly.

Weaknesses:

  • chdev -l hdisk1 -a pv=yes for disk verification is non-standard and potentially wrong for this context -- lspv hdisk1 is the correct check.
  • The OODA framing, while interesting, adds verbosity that would be stripped in a production runbook.
  • Minor: ioscli lspv prefix is technically correct on VIOS but inconsistent with the rest of the commands shown.

Grade: A- -- Most operationally complete. The bosboot inclusion and savebase tip push it above the others.

Codex gpt-5.3-codex medium

Strengths: Most concise. Correct sequence. Includes bosboot, syncvg, and the most honest and technically accurate closing note: "The change is only fully proven at next reboot, so schedule a maintenance reboot later." This is the most accurate characterization of the actual risk posture -- the migration is live-complete but boot validation is deferred.

Weaknesses:

  • No savebase mention.
  • No dual-VIOS caution.
  • No oem_setup_env detail beyond the initial invocation.
  • Thinnest on operational context.

Grade: B+ -- Correct, concise, and honest about residual risk. Best closing caveat of the three.

Summary Table

Criterion Claude 4.6 ChatGPT 5.5 Codex 5.3
bosboot included No Yes Yes
syncvg explicit No Yes Yes
oem_setup_env Yes No Yes
savebase No Yes No
-S flag accuracy Wrong Correct N/A
Boot risk caveat Weak Moderate Best
Overall grade B- A- B+

Bottom Line

ChatGPT 5.5 produces the most complete runbook. Codex is the most honest about residual risk. Claude's omission of bosboot and the -S mischaracterization are the most consequential errors in a production context. For an actual VIOS migration, you would composite the ChatGPT completeness with the Codex risk caveat -- and verify bosboot semantics in the IBM docs before executing.

4

ChatGPT Evaluates All Three LLM Solutions:

Observe

All three pick the correct general method: online rootvg mirror migration. IBM’s VIOS-specific rootvg mirroring doc points to mirrorios for VIOS 3.1/4.1, not raw AIX-only habits. (IBM) The pasted comparison contains Claude, ChatGPT Instant, and Codex answers.

Orient

Best answer: ChatGPT 5.5 Instant.
It includes the critical missing step: bosboot -ad /dev/hdisk1, plus bootlist, syncvg, savebase, and warns against migratepv.

Second: Codex.
Clean, short, mostly correct. Also includes bosboot. Weakness: less VIOS-specific and uses blocking mirrorvg unless sync time is acceptable.

Worst: Claude.
It omits bosboot, which is a serious flaw for rootvg boot migration. Setting bootlist alone does not necessarily make the new disk bootable.

Decide

Use the ChatGPT Instant procedure as the base, but improve it with VIOS-native preference:

For VIOS, prefer checking whether mirrorios is appropriate first. If doing raw AIX LVM from oem_setup_env, the essential sequence is:

extendvg rootvg hdiskNEW
mirrorvg -S rootvg hdiskNEW
syncvg -v rootvg
bosboot -ad /dev/hdiskNEW
bootlist -m normal hdiskNEW
savebase
unmirrorvg rootvg hdiskOLD
reducevg rootvg hdiskOLD

Act

Corrected ranking:

  1. ChatGPT 5.5 Instant: best operational answer.
  2. Codex gpt-5.3-codex: good concise sysadmin answer.
  3. Claude Sonnet 4.6: dangerous omission due to no bosboot.

Main defect across all three: none clearly says, “This is not truly validated until the next reboot.” Codex at least mentions that.

5

Codex Evaluates All Three LLM Replies:

Quick assessment: all three are broadly pointing to the right pattern (online rootvg mirror migration), but

they are not equal in operational safety.

Ranking

  1. ChatGPT 5.5 Instant

  2. Codex gpt-5.3-codex medium

  3. Claude Sonnet 4.6

Why

  • ChatGPT is the most complete and production-safe: it includes bosboot, bootlist, verification, and VIOS-

specific caution notes (savebase, dual-VIOS sequencing).

  • Codex is solid and concise, and also includes bosboot + maintenance reboot recommendation, but has less

VIOS nuance and fewer guardrails.

  • Claude is clear, but missing a key boot-prep step (bosboot) and has potentially shaky flag interpretation

around mirrorvg -S.

Key technical gaps across responses

  • bosboot on the new disk is a critical step for boot reliability and should not be omitted.

  • Better to explicitly verify no stale partitions and confirm rootvg layout before unmirroring.

  • All should clearly separate what runs in padmin/ioscli vs oem_setup_env.

Best practical answer

Use the ChatGPT flow, but keep Codex’s explicit “validate at next scheduled reboot” note. That combination is the safest operationally.

6

This example clearly shows a benefit of using multiple LLMs, suggesting and evaluating various solutions, to increase user confidence in LLM assigned tasks.

This also mirrors my work on complex LLM tasks, many documented here: