Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
[root@*** ~]# pvdisplay
--- Physical volume ---
PV Name /dev/sda2
VG Name vg_os
PV Size 19.00 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 4863
Free PE 0
Allocated PE 4863
PV UUID zqVTrS-8ICw-QXOI-mKln-H6n7-CeVA-Y8rYJ0
--- Physical volume ---
PV Name /dev/sdb
VG Name vg_data
PV Size 500.00 MiB / not usable 4.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 124
Free PE 0
Allocated PE 124
PV UUID H2oVWy-6PlL-q3Ms-LHG8-6kRe-r6SE-lhUzlw
--- Physical volume ---
PV Name /dev/sdc
VG Name vg_data
PV Size 500.00 MiB / not usable 4.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 124
Free PE 124
Allocated PE 0
PV UUID IOHa5Z-Njay-Tz5L-ogqM-m5Le-c0Mq-x8SnnD
- Doing vgdisplay:
[root@*** ~]# vgdisplay
--- Volume group ---
VG Name vg_os
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 19.00 GiB
PE Size 4.00 MiB
Total PE 4863
Alloc PE / Size 4863 / 19.00 GiB
Free PE / Size 0 / 0
VG UUID Cfnul0-QX1E-XyKw-PFOf-IBRE-R52P-rlrpjV
--- Volume group ---
VG Name vg_data
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size 992.00 MiB
PE Size 4.00 MiB
Total PE 248
Alloc PE / Size 124 / 496.00 MiB
Free PE / Size 124 / 496.00 MiB
VG UUID ycDX1O-3Iw1-xLCO-j8lw-JStG-EPr2-aO9uIr
- Doing lvdisplay:
[root@*** ~]# lvdisplay
--- Logical volume ---
LV Path /dev/vg_os/lv_root
LV Name lv_root
VG Name vg_os
LV UUID j7ZRCr-zlgA-BYyb-1LZQ-IdxI-DK58-faFRS4
LV Write Access read/write
LV Creation host, time idcsrv611.intrum.net, 2017-04-12 10:52:18 +0200
LV Status available
# open 1
LV Size 15.00 GiB
Current LE 3839
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 251:0
--- Logical volume ---
LV Path /dev/vg_os/lv_swap
LV Name lv_swap
VG Name vg_os
LV UUID ykd86n-cuLx-XfLr-4Zh1-KEx5-Tfil-gOOZcd
LV Write Access read/write
LV Creation host, time idcsrv611.intrum.net, 2017-04-12 10:52:18 +0200
LV Status available
# open 2
LV Size 4.00 GiB
Current LE 1024
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 251:1
--- Logical volume ---
LV Path /dev/vg_data/lv_data
LV Name lv_data
VG Name vg_data
LV UUID VICxUM-S5vx-mKSU-8lqH-0SxG-yXFv-q5fH9F
LV Write Access read/write
LV Creation host, time idcsrv611, 2017-04-14 12:28:35 +0200
LV Status available
# open 1
LV Size 496.00 MiB
Current LE 124
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 251:2
My idea is to mirror lv_data which the volume group is with /dev/sdb and /dev/sdc.
/dev/sdc will be the disk which I want to use for mirroring /dev/sdb.
After having the disks in the same volume group and logical volume I run:
[root@*** ~]# lvconvert --type mirror –m1 /dev/vg_data/lv_data /dev/sdc
Please specify a logical volume path.
Run `lvconvert --help' for more information.
Or
[root@*** ~]# lvconvert --type mirror –m1 vg_data/lv_data /dev/sdc
Please specify a logical volume path.
Run `lvconvert --help' for more information.
I get the same error messages.
I will appreciate a lot your help in this case. Thank you so much.
A couple of things when I did a bunch of these over the past few months:
1) I had separated the "-m1" as "-m 1" which is what the man page shows.
2) I had created a separate device for mirror log and specified that along with the mirror on the command line.
So my command line was:
lvconvert -m 1 -b <vgname>/<lvname> /dev/mapper/<new mirror> /dev/mapper/<mirror log disk>
The -b makes it background which you might want to do for large disks as the conversion can take quite a while.
In my case I was using multipath devices in /dev/mapper but the syntax would work for sd devices in /dev itself. Also in my case I was using this to make mirrors to migrate from one disk array to another so I was able to eliminate the mirror log device by removing the original device mirror after I was done. If you're making it a permanent mirror you need to decided where to do logging:
From the man page:
Quote:
--mirrorlog {disk|core|mirrored}
Specifies the type of log to use. The default is disk, which is
persistent and requires a small amount of storage space, usually
on a separate device from the data being mirrored. Core may be
useful for short-lived mirrors: It means the mirror is regener-
ated by copying the data from the first device again every time
the device is activated - perhaps, for example, after every
reboot. Using mirrored will create a persistent log that is
itself mirrored.
As it notes default is disk so it simply used the second disk I provided on command line without me having to specify --mirroring.
Also note you do have to have as many free PE in the target disk as are used in the original. I ran into more than one where I was missing a single PE on the target and it failed to start. You also have to have PEs for the logging if using disk.
Last edited by MensaWater; 05-02-2017 at 08:22 AM.
A couple of things when I did a bunch of these over the past few months:
1) I had separated the "-m1" as "-m 1" which is what the man page shows.
2) I had created a separate device for mirror log and specified that along with the mirror on the command line.
So my command line was:
lvconvert -m 1 -b <vgname>/<lvname> /dev/mapper/<new mirror> /dev/mapper/<mirror log disk>
The -b makes it background which you might want to do for large disks as the conversion can take quite a while.
In my case I was using multipath devices in /dev/mapper but the syntax would work for sd devices in /dev itself. Also in my case I was using this to make mirrors to migrate from one disk array to another so I was able to eliminate the mirror log device by removing the original device mirror after I was done. If you're making it a permanent mirror you need to decided where to do logging:
From the man page:
As it notes default is disk so it simply used the second disk I provided on command line without me having to specify --mirroring.
Also note you do have to have as many free PE in the target disk as are used in the original. I ran into more than one where I was missing a single PE on the target and it failed to start. You also have to have PEs for the logging if using disk.
Thank you very much MensaWater for your reply.
Right now I am testing the mirroring process but I plan to do this on physical servers which then I will have to use /dev/mapper for multipath devices. The idea is once the data is mirrored, remove the old disk which will be replaced by the new one.
I extended /dev/sdc and now is slightly bigger (125 PE) which should allow to perform the mirroring and still I get the same error message:
[root@*** /]# lvconvert –m 1 vg_data/lv_data /dev/sdc --mirrorlog mirrored
Please specify a logical volume path.
Run `lvconvert --help' for more information.
I even tried providing the path like dev/vg_data/lv_data and still is not working and showing the same error message.
Sorry - I focused on the command line you posted and forgot to mention you do need to vgextend to add the new device to your VG before you can mirror to it (this would also be true if you added a mirror log device as well):
vgextend vg_data /dev/sdc
NB: Established procedure was to do a pvcreate /dev/sdc before adding to a VG but I've found that vgcreate and vgextend will both do the pvcreate automatically if the device isn't already a PV so I usually skip the pvcreate. Older versions of lvm might still require it.
I plan to do this on physical servers which then I will have to use /dev/mapper for multipath devices. The idea is once the data is mirrored, remove the old disk which will be replaced by the new one.
That is exactly what I was doing at the end of 2016 and start of 2017. Moving from one disk array to another. The beauty of this approach is that you can do everything online without taking anything down. The downside is establishing the mirrors is time consuming and there is no apparent rhyme or reason to the time it takes and no way to tell it to speed up.
Note that after you do the mirror you can remove the old device by doing lvconvert -m 0 but you MUST specify the old device you are removing on that command line. You can then run vgremove against the old device to remove it from the VG.
I found out much to my chagrin that a typo in lvconvert for the old device name made it default to remove the new mirror device I'd just added rather than the old device. Moreover, an immediate restart of the lvconvert -m 1... to the new device did not run any faster than the original lvconvert I'd done. I'd have thought since all the extents had already been copied to the new device the redo lvconvert would have found the data and run more quickly but found it doesn't work that way.
Sorry - I focused on the command line you posted and forgot to mention you do need to vgextend to add the new device to your VG before you can mirror to it (this would also be true if you added a mirror log device as well):
vgextend vg_data /dev/sdc
NB: Established procedure was to do a pvcreate /dev/sdc before adding to a VG but I've found that vgcreate and vgextend will both do the pvcreate automatically if the device isn't already a PV so I usually skip the pvcreate. Older versions of lvm might still require it.
Thank you very much MensaWater again for your time and help.
Actually the disk already belongs to the volume group
[root@*** /]# vgdisplay -v vg_data
--- Volume group ---
VG Name vg_data
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size 996.00 MiB
PE Size 4.00 MiB
Total PE 249
Alloc PE / Size 124 / 496.00 MiB
Free PE / Size 125 / 500.00 MiB
VG UUID ycDX1O-3Iw1-xLCO-j8lw-JStG-EPr2-aO9uIr
--- Logical volume ---
LV Path /dev/vg_data/lv_data
LV Name lv_data
VG Name vg_data
LV UUID VICxUM-S5vx-mKSU-8lqH-0SxG-yXFv-q5fH9F
LV Write Access read/write
LV Creation host, time idcsrv611, 2017-04-14 12:28:35 +0200
LV Status available
# open 1
LV Size 496.00 MiB
Current LE 124
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 251:2
--- Physical volumes ---
PV Name /dev/sdb
PV UUID H2oVWy-6PlL-q3Ms-LHG8-6kRe-r6SE-lhUzlw
PV Status allocatable
Total PE / Free PE 124 / 0
PV Name /dev/sdc
PV UUID IOHa5Z-Njay-Tz5L-ogqM-m5Le-c0Mq-x8SnnD
PV Status allocatable
Total PE / Free PE 125 / 125
[root@*** /]# lvdisplay -v vg_data/lv_data
--- Logical volume ---
LV Path /dev/vg_data/lv_data
LV Name lv_data
VG Name vg_data
LV UUID VICxUM-S5vx-mKSU-8lqH-0SxG-yXFv-q5fH9F
LV Write Access read/write
LV Creation host, time idcsrv611, 2017-04-14 12:28:35 +0200
LV Status available
# open 1
LV Size 496.00 MiB
Current LE 124
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 251:2
On all examples I've seen, the command that I mentioned should work but for some reason is not working as I am specifying the logical volume path but is complaining about the logical volume path. I tried with /dev/vg_data/lv_data and vg_data/lv_data and specifying /dev/sdc as the mirror disk
I suspect you don't have enough PEs for both the mirror copy and the log. You show for each disk:
PV Name /dev/sdb
PV UUID H2oVWy-6PlL-q3Ms-LHG8-6kRe-r6SE-lhUzlw
PV Status allocatable
Total PE / Free PE 124 / 0
PV Name /dev/sdc
PV UUID IOHa5Z-Njay-Tz5L-ogqM-m5Le-c0Mq-x8SnnD
PV Status allocatable
Total PE / Free PE 125 / 125
You also show your LEs for the LV on sdb are all 124 extents allowed as PEs:
Current LE 124
In your other output I see the extent sizes are 4 MiB each. This means you're only allowing 4 MiB for the mirror log.
When I was creating a separate mirror log device it was 40 MB. You'd need to have 10 extents free for that size. (Though truthfully I don't know it required 40 MB - that may have been the smallest LUN I could create on the new disk array.)
This link suggests that if you don't specify a separate mirror log device it is actually trying to write the mirror to both the original and the new devices.
It may be that only occurs if you do as you did and specified mirrored rather than letting it default to disk as I did.
Since you don't have any free extents on sdb you wouldn't be able to have it write the log to both disks.
I'd try increasing extents on sdc as mentioned in my last post then letting it default to disk rather than mirrored on your command line. Failing that, I'd suggest creating a separate 40 MB LUN for the mirror log. (You'd of course need to vgextend to add that LUN to the VG.)
So in the end I did reinstall the server test and then it worked. Seems I had a bug or something as when I was going to /dev/mapper it wasn't showing the volume group but it seems it was create somewhere else.
The command I used in the end was:
lvconvert -m 1 --type mirror /dev/mapper/vg_test-lv_test /dev/sdb --mirrorlog disk /dev/sdd
Thank you so much MensaWater for your time and dedication to help me. I appreciate it a lot.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
