Hi Miguel, good to see you again!

Let me first explain why that space feels stuck, then the tempting answer you should NOT take, and then the right one.

Why it is stuck: in AIX one disk equals one physical volume, and one physical volume belongs to exactly one volume group. Your 800 GB drive is almost certainly carved as a SINGLE NVMe namespace covering the whole drive, because when a namespace is created the default size is the maximum drive capacity. That whole-drive namespace shows up as one hdisk, the hdisk went into rootvg, and mirrorvg doubled the arrangement on the second drive. Result: 2 x 700 GB of free space imprisoned inside rootvg.

The tempting answer: yes, you could create logical volumes in that free rootvg space and map them to client partitions as vSCSI backing devices. It works, and it is a classic trap. VIOS best practice keeps client data OUT of rootvg, because VIOS maintenance treats rootvg as disposable: an upgrade or reinstall of the VIOS rebuilds rootvg, and any client data living there goes with it, plus your viosbr backup and restore story and your performance separation get messier. So do not go there.

The right answer on NVMe hardware is namespaces. An NVMe drive can be carved into MULTIPLE namespaces, and each one appears to AIX and VIOS as its own hdisk. The design for your case: on each drive, one small namespace for the VIOS itself (100 to 150 GB is plenty) and one large namespace (roughly 650 GB) for data. rootvg gets mirrored across the two small ones, and the two large ones become a separate volume group or storage pool for whatever you need. The management is all in smit nvme, under Namespace Management and Attachment (create, attach, delete), and this time you specify the size explicitly instead of taking the whole-drive default that created your situation. The two references worth keeping:
https://www.ibm.com/support/pages/installing-vios-os-nvme-drives
https://community.ibm.com/community/user/blogs/harsha-kotapati/2025/02/25/nvme-namespace-management-in-aix

Now the catch: re-carving a drive is destructive for that drive, the existing namespace has to be deleted to free the capacity. Two scenarios.

If this system is not in production yet, do it clean: create the namespaces first (from the standalone diagnostics or from an existing partition, the support page above covers both paths), then install the VIOS on the small namespace and mirror to its twin. Ten minutes of planning, zero gymnastics.

If the VIOS is already live, there is an online dance, one drive at a time: unmirrorvg rootvg from the second drive, reducevg it out, remove the hdisk device, then from smit nvme delete its namespace and create the small plus large pair, cfgmgr, extendvg rootvg onto the new small hdisk, mirrorvg, bosboot on both copies, fix the bootlist, verify, and only then repeat the same sequence on the first drive. Two honest warnings: during each half of the dance rootvg runs on a SINGLE copy, so pick a quiet window and take a fresh viosbr and mksysb backup before you start; and do not skip the bosboot and bootlist steps on both disks, that is where these operations bite people.

One architectural note on what to put in the big namespaces: they are internal, non-shared storage of THIS VIOS. In a dual-VIOS setup, client disks backed by them cannot be served by the partner VIOS, so no dual-path redundancy for those specific disks. That makes the space perfect for the virtual media library (your ISO repository), for lab and development client disks, or for anything you accept as single-VIOS-served, while production client storage in a dual-VIOS world usually keeps coming from the external array.

If you tell me the Power model, the VIOS level, whether you run single or dual VIOS, and what you would like to host on that space, I can help you pick between a plain data volume group and a storage pool, and sanity check the sequence.

Cheers