Удобное распределение ресурсов для виртуальных машин

А также насколько логично выделять под корень такой большой обьем ).

Никогда так не делай. В корне необходимый минимум. В зависимости от ОСи, 5..20 Гб. Остальное монтируй туда, где собираешься это использовать.

в итоге раздел попортился не совпало кол-во блоков

Уменьшай с запасом, после действий с lv растянешь ФС обратно. Проблема в том, что ты размер указывал в гигабайтах, а не в блоках и экстентах. Одни считают, что 1k = 1024, другие - что 1k = 1000. Вот тут твои данные и аннигилируются. Всегда указывай размер для resize2fs в блоках, а lvresize - в экстентах, и внимательно считай.

Никогда так не делай. В корне необходимый минимум. В зависимости от ОСи, 5..20 Гб. Остальное монтируй туда, где собираешься это использовать.

здесь понял , а по поводу

Уменьшай с запасом, после действий с lv растянешь ФС обратно.

можно по порядку порядок действий или какой то пример ?

2 . Каким образом лучше всего распределять место под разделы виртуалок (какой минимальный размер под раздел / или какие идеальные размеры разделов / /var /home /usr ).

Как минимум, разделяют /, /boot и раздел, на котором будут лежать данные ( /home или /opt или /var/lib/mysql или /u2 . Завипсит от того, для чего будет использоваться ВМ)

Если будешь готовиться к pci dss, или просто знаешь что у тебя есть дополнительные требования к безопасности ( и ты можешь их реализовать ), то дополнительно отделяй /tmp, /var, /home

можно по порядку порядок действий или какой то пример ?

resize2fs /dev/sdc5 400G # уменьшаем с запасом
lvresize -L 500G /dev/sdc5 
resize2fs /dev/sdc5 # увеличиваем на всё доступное пространство

спасибо буду пробовать ! а получается я мог вернуть данные на диске путем

# resize2fs /dev/sdc5 500G # зашел в recovery mode на виртальной машине , изменил раздел с 1ТБ на 500ГБ
# lvreduce -L  600G /dev/virtual_volumes/vm1-var # изменил на хост машине размер или даже lvextend -L 600G /dev/virtual_volumes/vm1-var
# resize2fs /dev/sdc5

а получается я мог вернуть данные на диске путем

Ты мог их так не потерять ;)

И еще , я могу отдельно выделить lvm разделы под /var/lib/mysql /var/www такая практика есть ? Это не извращение ?

Или так:

1. Смотрим текущий размер ФС

   root@rhea:~# resize2fs /dev/mapper/vgrhea-lvroot
   resize2fs 1.42.5 (29-Jul-2012)
   The filesystem is already 5185536 blocks long.  Nothing to do!
   
   root@rhea:~# tune2fs -l /dev/mapper/vgrhea-lvroot | grep '^Block.size'
   Block size:               4096
   
   root@rhea:~# fdisk -l /dev/mapper/vgrhea-lvroot
   
   Disk /dev/mapper/vgrhea-lvroot: 21.2 GB, 21239955456 bytes
   255 heads, 63 sectors/track, 2582 cylinders, total 41484288 sectors
   Units = sectors of 1 * 512 = 512 bytes
   Sector size (logical/physical): 512 bytes / 512 bytes
   I/O size (minimum/optimal): 512 bytes / 512 bytes
   Disk identifier: 0x00000000
   
   Disk /dev/mapper/vgrhea-lvroot doesn't contain a valid partition table
   

   Т.е.

   /dev/mapper/vgrhea-lvroot
   размер раздела в байтах: 21239955456
   размер ФС в блоках: 5185536
   размер блока ФС: 4096
   

   можно проверить:

   root@rhea:~# echo '21239955456 - 5185536 * 4096' | bc -l
   0
   

2. смотрим текущий размер LV

   root@rhea:~# vgdisplay vgrhea | grep 'PE.Size'
     PE Size               32,00 MiB
   root@rhea:~# lvdisplay vgrhea/lvroot
     --- Logical volume ---
   [...]
     LV Size                19,78 GiB
     Current LE             633
   

3. Уменьшаем LV до 10 Gb

   # 3.1
   # вроде мы всё правильно посчитали, и размер точный. можно было бы уменьшить так
   # resize2fs vgrhea/lvroot $(( 10 * 1024 * 1024 * 1024 / 4096 )) # 
   # но если есть запас, я всегда перестраховываюсь, и уменьшаю с запасом в несколько гигов
   resize2fs vgrhea/lvroot $(( 8 * 1024 * 1024 * 1024 / 4096 )) # 9 Гб
   # resize2fs скажет размер в блоках после уменьшения. запомним его
   
   # 3.2
   lvresize -l $(( 10 * ( 1024 / 32 )) vgrhea/lvroot # 10 Гб
   
   # 3.3
   resize2fs vgrhea/lvroot # растягиваем ФС на весь LV, т.е. до 10 Гб. Убеждаемся, что новый размер в блоках больше, чем тот что получили в п.3.1
   

И еще , я могу отдельно выделить lvm разделы под /var/lib/mysql /var/www такая практика есть ?

Да, это нормальная практика. Если всё же выдали одним куском, можно смонтировать его например в /u2 и сделать символические ссылки /var/lib/mysql -> /u2/mysql и /var/www -> /u2/www

Вопросы к виртуализации не имеют никакого отношения.

Никогда так не делай.

Почему бы и нет? Особенно для виртуалок.

Если fsck найдёт ошибки в /, он выкинет приглашение ввсести рутовый пароль и починить вручную. Если fsck найдёт ошибку на разделе с данными, он спокойно загрузит ОСь и дальше ты будешь решать проблему не с физической консоли, а по удобному ssh.

man fstab

Извиняюсь )) , еще вопрос! мне в наследство достался похожий сервер , в нем отдельно выделены разделы /(sda1) /swap(sda2) /var/www(/dev/vda),корневой раздел на хост машине /dev/sysvg/machine1-root . А /dev/vda на хосте /dev/sysvg/machine1-data . Интересно почему {V}da(и не vda1) , не sd{a,b,c}3

Насколько логично выделять 1.3 террабайта

«Террабайты» не выделяй. Выделяй терабайты.

Сразу какой-то размер под все виртуалки выделять не надо. Выделяй отдельный раздел каждой виртуальное машине. Не знаю, как в KVM, а в LXC для этого даже ручной работы не надо, у lxc-create можно указать параметр, что rootfs надо создавать на новом LVM-разделе заданного размера. Выделяй по минимуму, под текущие потребности (ОС/софт/расчётный объём логов + расчётный объём данных + процентов 30..50 запаса, в зависимости от реального размера и интенсивности расширения), расширить потом можно всегда по мере надобности.

Насолько гибко и надежно действует lvresize

Расширять можно произвольно и безопасно. За последние 6 лет на полуджине машин расширял многие десятки раз.

На счёт гибкости — зависит от FS. Скажем, под популчрными ext4/xfs можно только увеличивать раздел, уменьшать — нельзя.

изменил раздел с 1ТБ на 500ГБ

Какая FS? Судя по resize2fs — ext4? Если она научилась уменьшать размер, то я про это не слышал. Соответственно, ничего сказать не могу. Ну и, вообще, уменьшение никогда не практиковал. Действительно, потенциально небезопасная операция.

в итоге раздел попортился не совпало кол-во блоков

resize2fs и lvresize размер в гигабайтах могут считать по-разному. И lvresize мог обрезать конец живого раздела, если по его расчётам «500G» чуть меньше. С увеличением проще, там цифра фигурирует только в lvresize, а resize2fs без параметров расширяет автоматом на весь доступный размер.

Уменьшай с запасом, после действий с lv растянешь ФС обратно.

О! Действительно, мысль.

Так что, resize2fs для ext4 научилась уменьшать размер?

я могу отдельно выделить lvm разделы под /var/lib/mysql /var/www такая практика есть ? Это не извращение ?

Я такое обычно и практикую.

Интересно почему {V}da(и не vda1)

На диске создавать раздел в принципе не обязательно. Это делать желательно, чтобы потом не принять диск за пустой. Особенно актуально, если диск доступен одновременно винде и линуксу. Но для виртуалки это не является необходимым

Отсутствие таблицы разделов удобнее, особенно если таблица разделов - msdos. Т.к. размер раздела на лету не изменишь.

почему {V}da(и не vda1) , не sd{a,b,c}3

Почему vda, а не sdb ?

Потому что диски отданы виртуальной машине разными способами. sda отдан как scsi ( или ide ), vda - как паравиртуальный диск ( pvscsi ). В случае паравиртуального диска, host системе не нужно эмулировать scsi ( ide ) устройства, меньше накладные расходы на виртуализацию

Не на лету, увы

Ок смотрите и поправьте если увидите ошибку .

lvcreate -n vm1-swap -L 8G virt_vol
lvcreate -n vm1-boot -L 512M virt_vol
lvcreate -n vm1-root -L 35G virt_vol
lvcreate -n vm1-home -L 200G virt_vol
lvcreate -n vm1-var-www -L 200G virt_vol
lvcreate -n vm1-var-lib-mysql -L 200G
virt-install -n vm2 -r 8192 --arch=x86_64 --vcpus=6 --os-type linux --boot cdrom,hd,menu=on --file=/dev/virt_vol/vm1-boot --file=/dev/virt_vol/vm1-swap --file=/dev/virt_vol/vm1-root --file=/dev/virt_vol/vm1-home --file=/dev/virt_vol/vm1-var-www --file=/dev/virt_vol/vm1-var-lib-mysql --network=network:default --graphics vnc --noautoconsole --autostart -c /var/iso/ubuntu-12.04.4-64bit.iso #Хочется добавить так же vda и vdc - соответственно vm1-var-www  vm1-var-lib-mysql 

мой опыт

1) по поводу 1,3Tb под корень. Я выделяю под корень 1.5-20Гб в зависимости от задач, только под ОС, под данные отдельное устройство. Обычно я выделяю порядка 2Гб под веб сервер. хватает более чем.

2) по поводу раздела для данных. тут есть пара моментов. первый момент - я делаю раздел с данными непосредственно на устройстве (т.е. устройство не размечаю). т.е подключаю его как то так

hardware-server:~# virsh attach-disk mymachine /dev/storage/mymachine-storage vdb --sourcetype block --persistent

а потом создаю фс на всём разделе

virtual-server:~# mkfs.ext4 /dev/vdb

в этом случае очень легко увеличивать фс. выключаем виртуалку, увеличиваем раздел с помощью lvm, а затем запускаем виртуалку и внутри виртуалки запускаем resize2fs /dev/vdb

к сожалению без перезагрузки не получается (виртуалка не видит что размер устройства увеличился даже после echo 1 > /sys/bus/pci/rescan ).

Второй момент - соответсвенно размер выбираю минимальный разумный. потому тчо увеличить легко. Cамо увеличение идёт в он-лайне, кстати. Перезагрузка виртуалки нужна только чтобы внутри виртуалки стал виден новый размер устройства.

я бы не использовал file=, я бы использовал disk= вроде как оно для этого, а файл больше для файлов.

я бы не использовал file=, я бы использовал disk= вроде как оно для этого, а файл больше для файлов.

UPD. А, прошу прощения, оно одно и то же делает, но файл деприкейтед. Только --disk актуален. из мана.

да, если использовать /dev/vdb1 (т.е. размечать разделы) то с увеличением начинаются проблемы, получается не всё так просто как если использовать устройство целиком, поэтому советую целиком и брать минимум. увеличить довольно легко, как я уже описал.

Огромное спасибо ! А подключение диска осуществляется только к уже существующей машине ?

наверное можно и во время установки, но я не знаю как его заставить неразмечать устройство, это надо пробовать (я обычно кикстарт использую для установки сентос, поэтому у вас с убунту могут быть другие ньюансы). В общем если делать так (подключать к существующей машине) - то точно работает. Чтобы подключить при создании надо либо доки читать, либо просто попробовать..

Не на лету, увы

Печально. А не на лету, на отмонтированном разделе — научилось теперь? Хоть и реже, но тоже могло бы пригодиться :)

ext4? Если она научилась уменьшать размер

Всегда умела. но только оффлайн

к сожалению без перезагрузки не получается

В госте тоже надо использовать LVM, добавляешь гостю еще один диск, диск в VG — все просто.

Странно. Я по её выходу читал, что только на увеличение. Ну, гут.

янп, что будет таки без перезагрузки определять что размер устройства изменился?

просто поясню на всякий - сейчас после того как я на хосте делаю lvresize и иду на гостя, то там размер /dev/vdb не меняется до перезагрузки. как лвм поможет? ведь сам лвм будет над /dev/vdb. по идее он точно так же среагирует (т.е. надо будет перезагрузить).

Насколько логично выделять 1.3 террабайта на 1 виртуальную машину

используйте kvm on zfs, вместо lvm и raid и таких проблем не будет

Каким образом лучше всего распределять место под разделы виртуалок

zfs

lvm в госте, добавлять pv, а не увеличивать вирт. диск

проблемы/сложности в госте, а не в хосте. так как zfs тут поможет?

к сожалению без перезагрузки не получается (виртуалка не видит что размер устройства увеличился даже после echo 1 > /sys/bus/pci/rescan ).

не надо выключать виртуалку, достаточно передернуть диск средствами virsh:

virsh detach-disk testbox --target vdc --config

virsh attach-disk testbox /dev/vmdisk/test-2disk vdc --sourcetype block --persistent

логично, но как то кривовато. но работать должно, если деваться некуда - то вполне выход. спасибо.

любопытно.

я так понимаю в этот момент диск на виртуалке потеряется, т.е. сайты (к примеру) уйдут в даун?

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

чтобы уйти от проблем с размерами дисков нужно перейти с lvm на zfs, эта фс позволяет увеличивать фактический размер диска по мере его заполнения данными, а благодаря встроенным квотам zfs, можно рулить доступным для виртуального диска местом, ну и огромнейший плюс это мгновенные снапшоты виртуалок на ходу, без потерь производительности.