Unlock LVM volumes from another machine by renaming the duplicate Volume Group (VG). This guide covers temporary activation, permanent renaming, and clean import/export methods to resolve VG name conflicts safely.

That LVM Disk From Another Server? Yeah, We Can Fix That.

I remember it like it was yesterday. 2 AM, the on-call pager screams, and our primary database server, prod-db-01, is completely offline. The hardware is toast. No problem, we think, we’ll just pull the data disks, slap them into our recovery box, dr-db-01, and pull the latest transaction logs. We physically move the drives, boot up the recovery box, and… nothing. A quick lsblk shows the disks are there, but lvs shows only the local volumes. The precious data volume from the dead server is nowhere to be found. That feeling of dread in the pit of your stomach? I’ve been there. You’re not crazy, and your data isn’t gone. You’ve just run into LVM’s built-in, and sometimes infuriating, safety feature.

First, Let’s Understand the “Why”

So, why does this happen? Let’s be real, most of us build our servers from a golden image or a template. Our production server, prod-db-01, and our recovery server, dr-db-01, were both built from the same image. This means they both have a Volume Group (VG) with the exact same name, likely something generic like vg_system or VolGroup00.

When you attach the disks from the dead server, your recovery host sees two different Volume Groups with the exact same name and UUID. LVM, in its infinite wisdom, gets confused and, to prevent catastrophic data corruption, it simply refuses to activate the “new” one. It’s a feature, not a bug, but it sure feels like a bug when you’re under pressure.

Pro Tip: This is a classic “gotcha” during Disaster Recovery tests. If you’re cloning VMs or restoring full-disk backups to a new host, you will almost certainly hit this issue. Practice this fix before you’re in an actual emergency.

The Fixes: From Quick & Dirty to Clean & Tidy

Okay, enough theory. You need that data. We have a few ways to tackle this, depending on what you need to do. I’ll walk you through three common scenarios I use.

Solution 1: The “I Need The Data Five Minutes Ago” Fix

This is the temporary, get-it-done approach. We’re going to tell LVM to activate the VG, but we’re not going to make any permanent changes. This is perfect for a quick data recovery operation where the disk will be removed shortly after.

First, scan for all physical volumes to make sure the system sees the new disk’s LVM metadata.

# pvs
  WARNING: Found duplicate PV S8fKGe...: using /dev/sdb2 not /dev/sda2
  WARNING: Found duplicate VG vg_system: using new VG ID ...
  PV         VG        Fmt  Attr PSize   PFree
  /dev/sda2  vg_system lvm2 a--  <19.51g    0
  /dev/sdb2  vg_system lvm2 a--  <99.51g <10.00g

See those warnings? That’s the smoking gun. LVM sees the duplicate. Now, find the VG you want to activate (it will likely be listed as NOT active). You can use vgs or vgdisplay.

To temporarily activate it, you can sometimes get away with just running:

# vgchange -ay vg_system

If LVM is still being difficult, you might need to force a partial activation. But for our common use case, the real solution is to rename it.

Solution 2: The “Permanent Guest” Fix (My Go-To Method)

This is my preferred method 90% of the time. We’re going to rename the Volume Group from the old server. This solves the name conflict permanently, allowing both the host’s VG and the new VG to coexist peacefully. It’s safe, clean, and easy to understand.

Step 1: Find the UUID of the VG you want to rename.

Since they both have the same name, we need a unique identifier. The UUID is perfect for this. Run vgs to see the VGs and their UUIDs.

# vgs
  WARNING: Found duplicate VG vg_system: using new VG ID lvm_vg_uuid_2
  VG        #PV #LV #SN Attr   VSize   VFree
  vg_system   1   2   0 wz--n- <19.51g    0
  vg_system   1   1   0 wz--n- <99.51g <10.00g

The output is a bit confusing. A better way is to use vgdisplay, which often gives you a clearer picture. Or, you can use the UUID of the physical volume (disk) to identify the right VG.

# pvscan
  PV /dev/sda2   VG vg_system   lvm2 [<19.51 GiB / 0    free]
  PV /dev/sdb2   VG vg_system   lvm2 [<99.51 GiB / 10.00 GiB free]
  ...

# vgdisplay vg_system
  --- Volume group ---
  VG Name               vg_system
  ...
  VG UUID               Abcdef-1234-5678-....  <-- This is the active, local one

  --- Volume group ---
  VG Name               vg_system
  ...
  VG UUID               Ghijkl-9876-5432-....  <-- This is the inactive, new one

Step 2: Rename the VG using its UUID.

Let’s say the UUID of the VG from our dead server’s disk (/dev/sdb2) is Ghijkl-9876-5432-..... We’ll rename it to something descriptive, like vg_recovered_data.

# vgrename Ghijkl-9876-5432-.... vg_recovered_data
  Volume group "vg_system" successfully renamed to "vg_recovered_data"

Step 3: Activate the newly named VG.

Now that the conflict is resolved, we can activate it without any complaints.

# vgchange -ay vg_recovered_data
  1 logical volume(s) in volume group "vg_recovered_data" now active

That’s it! Your logical volumes inside vg_recovered_data are now available under /dev/vg_recovered_data/ and you can mount them to access your files.

Solution 3: The “By The Book” Nuclear Option

If you’re planning a proper, scheduled migration of disks, the `vgexport` and `vgimport` commands are your friends. This is the cleanest way, designed for moving VGs between systems. `vgexport` makes a VG inactive and removes it from the host’s knowledge, and `vgimport` does the reverse on the new host.

Warning: In our emergency scenario, the original server is dead, so we can’t run `vgexport` on it. We can simulate this on the recovery host, but it’s a bit more involved and I usually just stick with `vgrename` in a crisis.

Here’s how it would work:

Step 1: On the *new* host, export the conflicting VG.

This command essentially tells the local LVM to “forget” about this VG, making it safe to import.

# vgexport vg_system  // BE CAREFUL - use the UUID to target the correct one if needed!
  Volume group "vg_system" successfully exported

Step 2: Import the VG, giving it a new name if you wish.

Now, we bring it back into the system’s control. You can import it with its original name if the conflicting VG is gone, or give it a new name right here.

# vgimport vg_system // or to rename on import: vgimport -n new_name old_name
  Volume group "vg_system" successfully imported

This method is robust, but for a simple data recovery job, `vgrename` is often faster and less nerve-wracking.

Wrapping Up

So there you have it. That “missing” LVM volume isn’t gone, it’s just hidden behind a safety feature. The next time you attach a disk from another machine and it doesn’t show up, don’t panic. Check for duplicate VG names with pvs and vgs, and use vgrename with the VG’s UUID to solve the conflict. It’s a skill that will turn a 2 AM panic into a 2:15 AM “problem solved”.

---

🤖 Frequently Asked Questions