creating DD copies of disks

I want to ask again:

What is the proper procedure when duplicating a disk with DD?

- after duplication you cannot update a PV with pvchange -u because it will supersede your duplicate with the original and not do anything

So to do that you need to boot off a different system, deactivate loaded vgs (if any) and then pvchange -u the duplicate PV.

- my experience indicates that pvchange -ay on a PV that contains a duplicate VG, even if it has a different UUID, but with an identical name, creates problems.

I mean that anytime you load a VG with the same name you get issues. VG names are often standardized between installs, so that Ubuntu might have "ubuntu-vg" as the name and kubuntu might have "kubuntu-vg" as the name.

So if you then load two of those disks in the same system, you instantly have issues.

If the system were to auto- or temporary-rename an offending 2nd VG it wouldn't be so bad. But usually you have to vgrename rename your current VG in advance of loading a second disk.

Which isn't exactly as intended, because now you are changing your local name to make room for a second system, when it should really be the other way around.

In the end I feel I have to do:

pvchange -u
vgchange -u
vgrename

To get something that will at least not bug me when both systems are loaded at the same time.

This then renders it impossible to use it as a backup because any other disk referencing the PV will not find it because the UUID has changed.

Now you would first have to reverse these operations (particularly the vgrename and pvchange -u) towards the data of the first disk (the original) to be able to use the device again.

All of that is not very resilient. Now both PV UUIDs and VG names have to be unique.

Particularly I wonder how easy it is to point an existing VG to a disk that has a new (duplicate) PV and tell it: use that one from now on.

I mean: how can I add a disk that has a duplicate PV with a different UUID and add it to the VG in such a way that it replaces the references that VG has for the old PV?

But also: what ought you to do if creating a mirror copy? (duplicate copy).

depends on what you define as "proper", what the desired outcome is supposed to look like.

What exactly are you trying to do?

If you intend to "clone" PVs of some LVM2 VG, and want to be able to activate that on the same system without first deactivating the "original",
I suggest:

1) create consistent snapshot(s) or clone(s) of all PVs
2) import them with "vgimportclone",
which is a shell script usually in /sbin/vgimportclone, that will do all the neccessary magic for you, creating new "uuid"s and renaming the vg(s).

You don't say...

: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support

DRBD� and LINBIT� are registered trademarks of LINBIT

Lars Ellenberg schreef op 17-09-2016 15:49:

Right so that would mean first duplicating partition tables etc.

I will check that out some day. At this point it is already done, mostly. I didn't yet know you could do that, or what a "clone" would be, so thank you.

I do say but this is very common and you can run into it without realizing, e.g. as you open some loopback image of some other system and you hadn't realized it would contain an identically named VG as your own system.

The issue is not that the problem happens, the issue is that you can't recover from it.

After both VGs are activated, in my experience, you are screwed. You may not be able to rename the 2nd PV, or even the first. I mean the VG sitting in that PV.

Sometimes it means having to reboot the system and then doing it again while renaming your own VG prior to loading the alien one.

This "you need foresight" situation is not very good.

Perhaps you can deactivate the new VG and close the PV and clear it from the cache; I'm not sure, back then my "skill" was not as great.

The problem really is that LVM will activate a second VG with the same name *just fine* without renaming it internally or even in display.

However, once it is activated, you are at a loss. So it will happily, without you being able to know about it in advance, create a difficult to reverse situation for you.

What if you *are* doing forensics (or recovery) as the Matthew person indicated? Are you now to give your own VGS completely unique names? Just so you can prevent any conflicts? Not a good situation.

LVM should really auto-rename conflicting VGS that get loaded after activation of the original ones, however it is hard to pick which one that should be, perhaps.

At least, maybe it should bolt before activating a duplicate and then require manual intervention.

Or, just make it easier to recover from the situation. It is just extremely common if you ever open an image of another disk (particularly if it's your own) or if you are doing anything with default "ubuntu-vg" or "kubuntu-vg" systems, in that sense.

I had a habit of calling my main VGs "Linux". Not any longer.

I now try to specify the system they are from, no matter how ugly.

Regards.

No. You check that out *now*.
It does not matter how you create your "duplicates" "clones" "snapshots" whatever you name them. If you want, use dd. No one really cares. What matters is that they are consistent.

Then, if you want to attach them, both original and "duplicate", you need to change uuids of PV and VG, and the VG name.

And vgimportclone is a script that does all necessary steps for you.

So no, you don't have to write scripts,
or figure out the necessary steps.

Someone else did that for you already.
Just use it.

: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support

DRBD� and LINBIT� are registered trademarks of LINBIT

Dne 17.9.2016 v 20:02 Lars Ellenberg napsal(a):

Hi

It might be worth to mention here - lvm2 is your LEAST problem when you have duplicate device in your system.

Udevd nor systemd can cope with those device AT ALL. (you will actually hardly find tool which can handle them).

So once a duplicated identifier appears in your system - all related symlinks
in /dev/by* or related attached systemd services becomes just a random unpredictable 'garbage'.

In general user-space tools are unprepared to deal with 'identical' devices. So IMHO lvm2 is still 'lighting years' ahead here.

You could prepare device filters to actually make your 'duplicate' device invisible to lvm2 (as I always HIGHLY recommend to use 'white-list' filter and let lvm2 process only 'expected' device).
Recent version of lvm2 also do try to 'smartly' guess which one of duplicated device is actually in use to further increase protection of a user...

However lvmetad is yet not fully equipped for this - but at least it will automatically turn itself off now...

Regards

Zdenek