Operating System - HP-UX
1752795 Members
6854 Online
108789 Solutions
New Discussion

Storage migration - Should we migrate the disk at the VM or at the HOST?

 
Ky Nguyen
Visitor

Storage migration - Should we migrate the disk at the VM or at the HOST?

Hi all,

We are preparing to move storage from VMAX to XtremIO. Previously, as long as I can see the new disks, I can use LVM to mirror to the new, reduce the old, etc... This round, while surveying the env, I realize that I have a dilema.

We have a few HPUX servers running VSE-OE. As such, I can apply the old procedure against the host, but I dont know whether the GOSes (or the VMs) would inherit the changes. Or should I see the new disks, push that access to the GOSes, and then apply the procedure at that level?

Thx in advance!

Even if you are on the right track, you'd get run over if you just sit there
1 REPLY 1
Matti_Kurkela
Honored Contributor

Re: Storage migration - Should we migrate the disk at the VM or at the HOST?

You'll need to know the physical storage type on each VM.

Run "hpvmstatus -p <vm-number>" or "hpvmstatus -P <vm-name>" on each VM.

In the Storage Interface Details section, see the Physical Storage column. It identifies whether the VM disks are backed by host logical volumes or whole disks (or by files, in case of virtual DVDs).

If the physical storage type is "lv", the VM disk is backed by a host LV, then you can perform the migration at the host level. using standard LVM procedures.

Likewise, if the physical storage type is "file", the VM disk is just a file in the host filesystem, and as long as the file is available at the specified path, you can perform any LVM operations on the underlying filesystem and the VM won't notice any difference.

If the VM disk is backed by a whole disk/LUN at the host level, you'll probably have to present a similar new disk/LUN to the VM and then do whatever migration procedure is applicable within the VM. (Depends on what's on the disk: is LVM being used within the VM, or are there raw databases or something similar?)

Or if you can have some downtime, you could replicate the disks to new storage using whatever SAN-based methods are available, then shutdown the VM, unpresent the old disk from the VM and present the new one (with already-replicated contents) to the VM using the same VM bus/dev/function/target/LUN values as the original. Then restart the VM, and if the replication was bit-for-bit accurate as it should have been, the VM operating system should not notice any difference.

MK