• FrequentlyAskedQuestions

Frequently Asked Questions

Please add questions here.

1. Do I need a special lvm2 kernel module?

2. I get errors about /dev/mapper/control when I try to use the LVM 2 tools. What's going on?

3. Is pvmove reasonably atomic? If the system goes down mid-pvmove, is my data hosed or do I just need to restart and try again?

4. I think I found a bug. What information should I gather and how should I report it?

5. Is there a way to activate/mount a copy of a volume group taken with a disk-array based point-in-time copy on the same host? The problem I have occurs because the disk-array copy contains all information on the disk, including PVID/VGID's, which is confusing for Linux's LVM.

6. I am using LVM2 in a shared SAN environment, and would like to restrict access to a single server, and periodically switch the access of the volume groups from one host to another. Under vxvm, "vxdg <import

Can I use pvmove on root volume ? What's special with it ?

• Problem is that move will suspend (and lock) root volume and executables resides on this volume.

  So the system can deadlock (-> waiting for read/write finish (waiting for volume resuming) - but resume can be processed *after* data are succesfuly accessed). This happens when part of lvm binaries tries to access file on suspended device (lockfile, write to syslog, shared library loading, some action caused by dm events (update of inode for /dev/) etc...) LVM2 tools solve most of known problems but still some weird situation can happen - basically it is not supported configuration yet.

To perform pvmove of root device you can

1. Boot from differrent device (live cd) and perform move from here.

2. If not possible: prepare environment and avoid some locking issues

3. - obviously, backup data on the volume you are trying to move

4. - try to avoid moving swap (deactivate it)

5. - use statically linked binaries lvm.static (and dmsetup.static) (use lvm.static pvmove <pars> instead of pvmove)

6. - move these binaries to ramdisk or volume not included in root (moving) volume (keep in mind that shell runs from moving volume too !)
7. - you can try disable locking: if you will process only one action with volume you can switch off locking (dangerous ! you can seriously corrupt metadata if you will enter more commands during move) (in lvm.conf set locking_type = 0)
8. - run pvmove

9. - you can use pvmove --abort to abandon it or pvmove [or with same source pv as before] to retry.

   • If it fails (or stucks)
     • - if you reset machine, pvmove will restart automatically.

     • - (dangerous): you can wake up suspended device (which caused deadlock) by running dmsetup resume <suspended device>

• Note if you are trying to do some debugging: What you're looking for is anything that attempts to access the device being moved (e.g /dev /var /etc) while it's suspended - that process will block, and if it happens to be holding on to any resource that pvmove needs before unsuspending the device, things will lock up when pvmove tries to get that resource. It helps to get several backtraces from the deadlock situations - need to include *every* process - and look for things that they have in common.

  See if you can get it working in simpler environments first - e.g. disable locking in the config file; try with /etc, /dev, /var etc. in ram filesystems.

How can I debug problem myself ?

• For reporting debug information use lvm_dump (see question above)
• Common debug practices
  • get version of all subsystsems (LVM/dm library/kernel driver) {{{lvm version

uname -a}}}

• reproducing problem with debug messages enabled set in lvm.conf {{{ log { ...

activation = 1 }}}

• and run command with debug switches

  {{{<command> -vvvv

}}}

• Get info about device mapper state {{{dmsetup info -c [--noopencount]

dmsetup table dmsetup status}}}

• Sometimes adding --noopencount avoids the hang of dmsetup

• Provide process and memory information from kernel

  {{{echo t > /proc/sysrq-trigger

echo m > /proc/sysrq-trigger list ls -R /sys/block/dm*}}}

I see "reload ioctl failed", what's wrong ?

• If you get {{{device-mapper: reload ioctl failed: Invalid argument

}}}

• .. and you recently updated kernel/lvm/device-mapper Check for versions (and update all components)

  • kernel

  • device-mapper package

  • lvm2 package

  Also search syslog for detailed error message.

I cannot create more than X (usually 32) snapshots...

• Known problem - will be partially solved by new DM-IO interface.
• But anyway, current snapshot implementation is not properly designed for such type of operation (many snapshots will significantly slow down all IO).