| 1 |
On Wed, Mar 30, 2011 at 8:21 PM, Einux <einuxnet@×××××.com> wrote: |
| 2 |
|
| 3 |
> thank you guys, you've been helpful :) |
| 4 |
> |
| 5 |
> On Wed, Mar 30, 2011 at 3:31 PM, Joost Roeleveld <joost@××××××××.org>wrote: |
| 6 |
> |
| 7 |
>> On Wednesday 30 March 2011 07:28:40 Florian Philipp wrote: |
| 8 |
>> > Am 30.03.2011 05:02, schrieb Einux: |
| 9 |
>> > > Hi, |
| 10 |
>> > > |
| 11 |
>> > > I bought a new 1T harddrive which is exactly the same as my previous |
| 12 |
>> > > harddrive. So I'm planning to make a Raid-1 layout(for security |
| 13 |
>> > > reasons). But here's the problem: I've already setup LVM2 on the |
| 14 |
>> > > existing harddrive and I don't want to destroy the existing LVM volume |
| 15 |
>> > > groups. I tried to google it, but I'm not sure which is the right |
| 16 |
>> > > keyword. Could you guys help me out? |
| 17 |
>> > > |
| 18 |
>> > > Thanks in advance:) |
| 19 |
>> > |
| 20 |
>> > 1. Create a degenerated RAID1 with your new disk |
| 21 |
>> > mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb |
| 22 |
>> > |
| 23 |
>> > 2. Partition the raid device |
| 24 |
>> > |
| 25 |
>> > 3. Add one of the partitions to your LVM volume group. |
| 26 |
>> > pvcreate /dev/sdb2 |
| 27 |
>> > vgextend volume_group /dev/sdb2 |
| 28 |
>> > |
| 29 |
>> > 4. Move everything from the old physical volumes to the new pv. |
| 30 |
>> > pvmove /dev/sda3 /dev/sdb2 |
| 31 |
>> > |
| 32 |
>> > 5. Remove the old and now empty physical volume |
| 33 |
>> > vgreduce volume_group /dev/sda3 |
| 34 |
>> > |
| 35 |
>> > 6. Move everything else which is not on LVM to your new raid. Guess you |
| 36 |
>> > need to go to single user mode to do this safely. |
| 37 |
>> > |
| 38 |
>> > 7. Grow your raid to also contain the old disk. |
| 39 |
>> > mdadm /dev/md0 -a /dev/sda |
| 40 |
>> > |
| 41 |
>> > No, I have not tested this and you should double-check everything. No |
| 42 |
>> > guarantees, etc. |
| 43 |
>> > |
| 44 |
>> > One warning, though: pvmove is known to create problems from time to |
| 45 |
>> > time. Leaking memory, bogging systems with infinite system load and so |
| 46 |
>> > on. If it gives you trouble, you can abort it with `pvmove --abort` and |
| 47 |
>> > try it again later by calling `pvmove volume_group` (without physical |
| 48 |
>> > device specified) to resume it. It SHOULD survive system crashes. |
| 49 |
>> > Trying another kernel version sometimes helps when pvmove gives you |
| 50 |
>> trouble. |
| 51 |
>> |
| 52 |
>> To avoid that, with "large" moves, do the following: |
| 53 |
>> # pvmove -i 600 /dev/sda3 |
| 54 |
>> |
| 55 |
>> The "-i 600" means, only report every 10 minutes. It's the "reporting" |
| 56 |
>> that |
| 57 |
>> causes the memory leak. |
| 58 |
>> |
| 59 |
>> Also, when just wanting to "empty" one physical volume, it is not |
| 60 |
>> necessary to |
| 61 |
>> specify the "target". |
| 62 |
>> It's a good idea to mark the PVs on the existing drive "non-allocatable". |
| 63 |
>> Then |
| 64 |
>> LVM won't try to move anything to that PV: |
| 65 |
>> # pvchange -xn /dev/sda3 |
| 66 |
>> |
| 67 |
>> The rest of the steps read correct. It's how I did a similar operation, |
| 68 |
>> but |
| 69 |
>> still double-check all the parameters and when in doubt, read the manual |
| 70 |
>> and/or ask on the list. |
| 71 |
>> |
| 72 |
>> -- |
| 73 |
>> Joost Roeleveld |
| 74 |
>> |
| 75 |
>> |
| 76 |
>> |
| 77 |
> |
| 78 |
> |
| 79 |
> -- |
| 80 |
> Best Regards, |
| 81 |
> Einux |
| 82 |
> |
| 83 |
> I starred this in Gmail in case I ever need to do something like this. |
| 84 |
Thanks guys! |
Archives