LVM

Делается это все так: 1. Размонтируем файловую систему: umount /dev/fileserver/samba 2. Уменьшаем размер файловой системы. Для этого сначала сделаем проверку самой файловой системы. Утилита resize2fs не даст изменить размер до выполнения проверки. Конечно, у нее есть ключ -f, который заставит ее это сделать, но лучше перестраховаться и все-таки выполнить проверку:

e2fsck -f /dev/VolGroup00/LogVol00

resize2fs /dev/VolGroup00/LogVol00 9G

Только после корректного выполнения двух предыдущих шагов уменьшаем размер логического тома:

lvreduce -L 9G /dev/VolGroup00/LogVol00

После этого монтируем файловую систему и смотрим что поменялось:

mount /dev/VolGroup00/LogVol00 /mnt/disk
df -h

Большинство таких инструментов разметки обычно по умолчанию создают новые разделы с идентификатором раздела 0×83 (Linux). Вы можете использовать установки по умолчанию, но лучше изменить их на 0x8e (Linux LVM).

#fdisk -l /dev/sdb

Изменим тип раздела на 0x8e (Linux LVM).

fdisk /dev/sdb
 Command (m for help): t
 Selected partition 1
 Hex code (type L to list codes): 8e
 Changed system type of partition 1 to 8e (Linux LVM)
 Command (m for help): w

Теперь инициализируем каждый раздел с помощью pvcreate:

pvcreate /dev/hda2

Физические тома и группы томов создаются за один шаг: vgcreate:

vgcreate test-volume /dev/hda2

Команда создает логический том с именем test-volume, используя в качестве исходных физических томов /dev/hda2.

После создания группы томов test-volume ведите команду vgdisplay для просмотра общей информации о вновь созданной группе томов.

Создание новых логических томов (разделов)

lvcreate -L 5G -n data test-volume

Создается логический том размером 5 ГБ с именем data.

Создадим новый логический том nfs-121 заняв все свододное место (-l 100%FREE)

lvcreate -l 100%FREE -n nfs-121 test-volume

После создания тома data вы можете проверить наличие узла этого устройства:

root@klausk:/# ls -l /dev/mapper/test--volume-data
brw-rw---- 1 root disk 253, 4 2006-11-28 17:48 /dev/mapper/test--volume-data
root@klausk:/# ls -l /dev/test-volume/data
lrwxrwxrwx 1 root root 29 2006-11-28 17:48 /dev/test-volume/data ->
/dev/mapper/test--volume-data

Вы также можете просмотреть свойства логического тома с помощью команды lvdisplay

Монтирование логического тома

root@klausk:~# mkfs.ext4 /dev/test-volume/data
root@klausk:~# mkdir /data
root@klausk:~# mount -t ext4 /dev/test-volume/data /data/
root@klausk:~# df -h /data
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/test--volume-data
                      5.0G   33M  5.0G   1% /data

Вам также может потребоваться изменить файл fstab(5) для автоматического монтирования файловой системы во время загрузки:

mount Logical Volume 'data' under /data
/dev/test-volume/data   /data   ext4        defaults        0 2

Удалить физический том из группы томов

 vgreduce nfs /dev/sdb1

Данная утилита позволяет решить задачу переноса виртуальной машины с одного сервера KVM на другой, с минимальным простоем виртуальной машины, без использования общего хранилища (non-shared storadge).
Передавать мы будем весь раздел LVM, на который установлена виртуальная машина. Ну а уменьшить время простоя нам поможет магия работы LVM snapshot, информацию о которой вы с легкостью можете найти в интернете.

Вот как выглядит перенос виртуальной машины в кратком виде:

1. Делаем снимок LVM раздела.
2. Передаем основной LVM раздел по сети, не останавливая нашу VM.
3. Когда закончится передача основного раздела, останавливаем VM.
4. Запускаем lvmsync для передачи снимка по сети. Передается не весь снимок, а только измененные блоки.
5. Подготавливаем и запускаем VM на новом сервере.

В результате, при использовании lvmsync время простоя виртуальной машины будет равно времени передачи измененных блоков в снимке основного раздела.

Подробнее о работе lvmsync, и дополнительных плюшках вы можете почитать на [urlspan]страничке проекта[/urlspan].

Далее предполагается что у нас есть права sudo в системе, ssh доступ настроен по ключам, а вход под рутом запрещен.

Приступим к переносу VM:

Установка:

Для работы lvmsync нам потребуется Ruby 1.8 (or later), ssh, и dmsetup.
Скачиваем lvmsync на локальный компьютер:

wget https://github.com/mpalmer/lvmsync.git

Копируем lvmsync в root PATH, например в /usr/bin/

Подготовка удаленного сервера (server2):

1) Скачиваем и устанавливаем lvmsync.
2) Создаем LVM раздел для копируемой VM.

server2# lvcreate vg -n new-virtual  -L 16G

Размер раздела должен быть равен исходному разделу (в принципе он может быть и больше исходного, но этот вариант мной не тестировался).

Подготовка локального сервера и перенос VM.

Далее все команды необходимо выполнять на сервере, с которого мы хотим переместить виртуальную машину (server1).

1) Создаем definition xml:

server1# virsh dumpxml virtual > virtual.xml

2) Делаем снимок раздела:

server1# lvcreate --snapshot -L10G -n virtual-snap /dev/vg/virtual

3) Не останавливая VM, переносим основной раздел с помощью dd:

server1# dd if=/dev/vg/virtual bs=1M | gzip -c | pv -ptrb | ssh me@server2 "gunzip -c | sudo dd of=/dev/vg/new-virtual"

Здесь добавлено сжатие передаваемых данных гзипом, и отображение хода передачи данных с помощью pv.

4) Когда перенос будет закончен, останавливаем виртуальную машину:

server1# virsh shutdown virtual

5) И после полной остановки машины запускаем lvmsync для переноса снимка:

server1# lvmsync --stdout /dev/vg/virtual-snap | ssh me@server2 sudo lvmsync --apply - /dev/vg/new-virtual

Эта операция не только перенесет снимок на новый сервер, но и смержит его сразу с основным разделом LVM.

6) Копируем definition xml на удаленный сервер:

server1# scp virtual.xml me@server2:/home/me/new-virtual.xml

Подготовка и запуск виртуальной машины на новом сервере:

1) Изменяем definition xml, если необходимо.

2) Создаем виртуальную машину на основе xml:

server2# virsh define new-virtual.xml

3) Запускаем нашу виртуальную машину, и прописываем ее в автостарт:

server2# virsh start new-virtual
server2# virsh autostart new-virtual

Вот и все, перенос виртуальной машины закончен!

Примечания

Утилита тестировалась на Centos 6.4. Про временя переноса сказать что-либо затрудняюсь, т.к. все зависит от интенсивности работы с виртуальной машиной во время ее переноса, и, соответственно, размера снапшота.

[urlspan]http://www.pvsm.ru/linux/37753[/urlspan]

Смотрим размер в байтах

lvs --units=B

Создаем такой же

lvcreate -n lvm_name -L ....B vps

Если случайно был удален том lvm (или специально, но потом понадобилось восстановление) — механизм резервного копирования метаданных vloume group может спасти ситуацию.
Настройка архивирования находится в /etc/lvm/lvm.conf в секции backup.
По умолчанию (в debian) архивирование включено, папка для архивов — /etc/lvm/archive и содержит архивы изменения vg за 30 дней.
Посмотреть чего менялось можно командой vgcfgrestore -l VG

#vgcfgrestore -l VG..... skipped .....
  File:         /etc/lvm/archive/VG_00390.vg
  VG name:      VG
  Description:  Created*before* executing 'lvremove /dev/VG/lv_name_1'
  BackupTime:  MonOct1516:22:502012

  File:         /etc/lvm/archive/VG_00391.vg
  VG name:      VG
  Description:  Created*before* executing 'lvremove /dev/VG/lv_name_2'
  BackupTime:  MonOct1516:22:552012

  File:         /etc/lvm/archive/VG_00392.vg
  VG name:      VG
  Description:  Created*before* executing 'lvremove /dev/VG/lv_name_3'
  BackupTime:  MonOct1516:23:182012

  File:         /etc/lvm/archive/VG_00393.vg
  VG name:      VG
  Description:  Created*before* executing 'lvremove /dev/VG/lv_name_4'
  BackupTime:  MonOct1516:23:202012
  File:         /etc/lvm/archive/VG_00394.vg
  VG name:      VG
  Description:  Created*before* executing 'lvcreate -L20g -nsome_new_lv VG'
  BackupTime:  TueOct1600:32:402012

Здесь видно имя файла архива и команда, перед (или иногда после) которой архивирование метаданных VG было выполнено.
В данном случае были удалены некоторые LV и после них создан новый.
Чтобы узнать, попал новый LV поверх старых (тогда естественно данные будут перезаписаны, зависит от количества записей в новый LV) надо посмотреть в архиве до удаления параметры extent_count и stripes нужного LV. stripes это номер начала блока на PV, extent_count — количество.
LV может состоять из нескольких сегментов, в каждом будет свой набор extent_count и stripes.
Потом посмотреть эти же параметры нового LV, но в архиве поcле создания нового LV.
Если эти регионы не пересеклись — значит новый LV создался в другом месте, чем удаленные LV.
Восстановить метаданные просто —

vgcfgrestore -f /etc/lvm/backup/VG_00390.vg VG

это откатит все изменения с текущего момента до нужного архива, предшествующего указанной в vgcfgrestore -l команде.
Дальше остается только активировать восстановленные LV командой

lvchange -a y /dev/VG/lv_name