Увеличить размер диска виртуальной машины xenserver
Пришло время апргейда железа. И оказалось, что гипервизор VMware 3.5 не работает с новыми боксами (мы взяли ProLiant BL465c G7, а с ними работает только VMware4). Фришная лицензия от VMware vSphere 4 тоже не подошла - там держатся только 2 физических CPU максимум по 6 core и не более 4х виртуальных CPU.
И серьезно стал вопрос о выборе нового гипервизора. Реально имеем две альтернативы - Xen (Citrix и XCP) и RHEV (KVM). Свое мнение про них и сравнительный анализ я напишу позже, когда все эксперименты закончатся и будет сделан выбор.
Пока в данной статье я опишу "кусочек" экспериментов. Мне понадобилось изменить размер shared SAN partition на Citrix Xen 5.6 FP1 - на раздел не помещаются снапшоты, а без снапшотов нормально бекап не провести - нужно останавливать виртуалку, что неприемлемо.
Разумеется, изменение размера нужно делать "на лету". Забегая немного вперед, отмечу, что мне удалось сделать это, даже не останавливая виртуалку, запущенную на этом томе!. Честно говоря, дисковой активности в виртуалке не было, т.е. эксперимент не совсем "чистый". И Citrix честно предупреждают, что рекомендуют все-таки виртуалку останавливать "во избежании". Полагаю, что все-таки можно производить ресайз раздела и без остановки, если активность диска низкая. Как-нибудь при возможности попробую провести эксперимент.
Но вернемся к задаче.
Итак, формулировка: Есть shared storage, расположенный на SAN. К стораджу, разумеется, подключаемся двумя адаптерами и multipath включен (мы же все-таки enterprise ;) ). Имеем два XenServer'а в пуле. На разделе расположена виртуальная машина (запущенная). Задача - увеличить размер раздела без перезагрузки Xen-серверов (и желательно без остановки виртуалки). 100% рабочего алгоритма, как обычно, в инете я не нашел. Пришлось компилить из разных источников :)
Disk /dev/sda: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Все получилось! Теперь на всех серверах пула повторяем процедуру, за исключением ресайза тома на SAN и ресайза LVM. Очевидно, что серверам нужно сообщить об изменениях, но повторно ресайзить не нужно.
Теперь запускаем XenCenter и проверяем, что SR виден нового размера. Если виден старого размера, нужно выбрать SR в дереве слева, перейти на закладку Storage и нажать Rescan.
Все, задача выполнена. Дальнейшее увеличение размера и/или добавление диска(ов) для виртуалки внутри Xen - тривиальная задача, особенно с помощью XenCenter.
Возможно ли создавать в XenServer диски объёмом более 2 Тб. Работаю с XenServer впервые раньше пользовался ESXi решил перейти на XenServer 7 из за того что у ESXi ограничение на 1 виртуалку 8 ядер. Здесь же столкнулся с тем что нельзя создать виртуальный диск объёмом больше 2 Тб. Если это ограничение можно обойти то как это можно сделать?
- Вопрос задан более трёх лет назад
- 1001 просмотр
Можно. Надо только использовать командную строку консоли. Немного по другому поводу, но это обсуждалось здесь: Подключить диск объёмом > 2ТБ к XenServer 7.0?
Ну и в случае с Hardware HBA таких проблем вроде не существует
Не могли бы про Hardware HBA написать по подробнее. Так как после добавления RAID масива таким образом XenServer так и не разрешил на нем создавать виртуальные диски размером более 2ТБ. И я нашел решение разбив рейд на 2 разных. Один из которых прикрепил как Hardware HBA для VM не требующих большого обьема HDD а второй большого обьема для VM где нужно 8 Тб и пробросил его в VM по инструкции с хабрахабр через символьные ссылки. Но через 2 недели эксплуатации выяснилось что из за этого у xenservera 7 возникают ошибки вызывающие полное зависание гипервизора и решить это можно только полной перезагрузкой физической тачки.
Mihnovich_AE: Storage Repository объёмом равным объёму физического диска должно создаваться автоматически - вне зависимости просто ли это диск или RAID-массив, или подключение к SAN через Hardware HBA.
После того как репозитарий создан, на нём можно создавать виртуальные диски. До 2 ТБ можно использовать XenCenter. Чтобы получить > 2 ТБ, необходимо использовать консоль сервера как описано по ссылке.
А вот пробрасывать символьные ссылки внутрь VM - очень плохая и потенциально опасная практика, как вы, собственно, и убедились
pred8or: Спасибо шас пользуюсь вашим вариантом описанным по ссылке. Вореде покачто полет нормальный выделил 5 ТБ памяти. все устраивает. Подскажите как в данном варианте со стабильностью?
Да никаких проблем не возникало. Возможно, в течение недели-двух получу новое хранилище, попробую снять бенчмарки, посмотреть нет ли какого-то влияния на производительность
В порядке подготовки к лету в сервере был заменён системный диск, ну и туда до кучи установлен свежий XenServer 7.0. А дальше была сделана фатальная ошибка: одной командой xe sr-create вместо xe sr-introduce содержимое диска было отправлено в лучший мир. К счастью, ничего такого, чего жалко было бы потерять.
Но вот все мои попытки создать такой диск заново ни к чему не приводят. Что я делаю:
0. В этой версии XenServer почему-то в /etc/lvm/lvm.conf параметр global / metadata_read_only почему-то установлен в 1. В предыдущей версии там был 0. Соответственно, с LVM ничего не сделать, не установив в 0. Возможно, у них к этому были какие-то причины, так что я перед любой операцией над LVM ставлю это в 0, а потом возвращаю в 1.
1. Удалить всё что на диске существует. PBD отсоединяется и уничтожается, SR уничтожается и забывается, после чего SR пропадает из XenServer-а.
2. Создать пустую GPT ( gdisk /dev/sdc )
3. Найти ид диска ( ll /dev/disk/by-id/ | grep sdc ) и создать SR (). SR появляется в XenCenter, объём - 2.7 ТБ, занято 4 МБ.
4. В соответствии с инструкцией по ссылке создать том максимального размера:
5. Опять же, в соответствии с той же инструкцией, сканируем SR:
6. Удаляем созданный том, создаём новый, скажем, объёмом в 1000ГБ. Сканируем. Та же самая ошибка.
7. Удаляем этот том. Сканируем - всё нормально. Идём в XenCenter. В строке Size видим следующее:
4 MB used of 2794.5 GB total (0 B allocated)
8. В XenCenter создаём диск объёмом 1000 ГБ. Параметр Size показывает следующее:
9. При помощи lvs находим нужный том, меняем ему размер:
10. При помощи lvs убеждаемся что так и есть. Запускаем xe sr-scan , после чего возвращаемся в XenCenter. Там видим следующее:
На закладке Storage объём диска тоже составляет 1000ГБ, если этот диск подключить к какой-нибудь виртуалке, то та тоже покажет ту же самую 1000ГБ.
И xe vdi-list params=all говорит что:
Конечно же, я пробовал и vdi-resize :
Те же самые злополучные 2 ТБ.
Как мне удалось это проделать 2 года тому назад? Что я пропускаю сейчас? Или они в этой версии решили закрыть все лазейки?
P.S. На обсуждение темы "всем достаточно 640 Кб" предлагаю время не тратить. Нарезать большой диск на мелкие тома, а потом в виртуалке склеивать их в один большой считаю дурацкой затеей.
In this mini post, I’ll show you how to resize/increase the size of the virtual hard disk used in a Xen DomU virtual machine “guest”. One of the challenges that comes with managing Xen domU instances is dealing with virtual machines that run out of disk space. If the initial setup was not done carefully, you may find that resizing the virtual machine is a bit more involved than it sounds, especially if the domU is backed by a disk image or single physical partition.
Scenario: In the Dom0 (Host) you have an LVM Logical Volume that you export to the DomU (Guest) and it appears as an entire hard drive which you want to make larger. We’ll do this task in three steps, Let’s start.
Step 3: Checking the new DomU disk size
To check the new disk size, simply we run df command:
The new root size is 30 GB, we also may use fdisk command as follow:
Perfect, the disk increased now,
Note the difference in the disk naming in Dom0 and DomU. Again this last step NEEDED ONLY IF THE DISK SIZE NOT INCREASED AFTER DOMU STARTS.
Step 2: Performing the resizing operation from the Dom0 “the xen host”
Now, after we powered off the guest, login to the host “Dom0” and find the disk your DomU is using “found in it’s config file in /etc/xen directory“. For our example here’s our two partitions our VM is using:
We want to increase the disk to be 30 GB, for more details we run lvdisplay against our disk as follow:
Now comes the important steps “the resizing steps”. To resize our disk we use lvextend command as follow:
Very Good, it successfully increased without errors. Note that we used the option --size with the new size “30GB”.
Now, we run lvdisplay again to see the new disk details:
Now, we do a filesystem check, run the following command:
As you see, the appeared errors are fixed.
Finally, we resize the filesystem using resize2fs command, run the following:
We finished our work on the Dom0 “xen host”, now start the DomU guest and check on the new disk size.
Summary
In this article, we have explained how to increase the disk size of DomU guest VM from the Dom0 host. We used commands with details to show you the different cases we can perform this task.
I hope this article is good enough for you.
See you in other articles.
Иногда бывает виртуальный сервер, виртуализованный с помощью Xen, и его диск является простым файлом в файловой системе хост-машины. И иногда внезапно его бывает надо поширить. Чтобы потом увеличить файловую систему внутри него. Тонкость в том, что нельзя затереть ни байта из уже имеющегося файла – надо добавить нулей строго после конца файла до необходимого размера.
Предположим, что у нас есть образ диска виртуалки System.img размером 10 миллионов байт (специально, чтобы двоично некругло было) и его надо увеличить до 200 мегабайт (двоичных). Для проверки посчитаем от него (точнее, от его дампа od) md5-сумму, чтобы потом сравнить с первыми 10 миллионами байт увеличенного файла, чтобы быть уверенными, что ничего не перезаписано. Также посмотрим на байты в его конце. Также посмотрим сколько блоков файл реально занимает на диске командой stat (она показывает, сколько блоков занимает сам файл плюс блоки его inode).
Наконец, начинаем ширить. Виртуальный сервер перед этим, естественно, останавливаем. Я не знаю способ заставить ядро Linux перечитать размер физического устройства, если это не physical volume от LVM. А в случае с диском с корневым разделом это не LVM, поскольку /boot не в LVM-е.
Простой способ – записать блок размером в мегабайт в конец файла на смещении «размер результата в мегабайтах минус один»:
В результате получим разрежённый (sparse) файл, в котором между старым содержимым и последним мегабайтом нулей, записанных с помощью dd – «дырка». Тепрь посмотрим на размер файла. Посмотрим на md5-сумму первых 10 миллионов байт, чтобы убедится, что исходные данные не тронуты. Посмотрим на сами байты. Посмотрим, сколько блоков теперь реально занимает файл:
Видим, что результирующий файл размером ровно 200 (двоичных) мегабайт и md5-сумма его (точнее, его od дампа) первых 10 миллионов байт не изменилась – т.е. исходные данные не затёрлись. Сами последние байты также совпадают, дальше идут нули. И, наконец, сам файл (вместе с блоками inode) занимает всего 21624 блока по 512 байт – это всего 10.55 мегабайт реального дискового пространства, т.е. файл действительно разрежённый.
К сожалению, sparse-файл – очень плохое решение для образа виртуальной машины. Она очень ловко встанет колом с неизвестными последствиями, когда на диске хост-машины закончится место и sparse-файлу неоткуда будет брать новые блоки. Поэтому выделяем всё нужное место для файла образа виртуалки заранее.
Здесь проблема в том, чтобы не перезаписать старые данные. Т.е. надо дописать в конец файла ровно «новый размер минус старый размер» нулей со смещения «старый размер». Если работать с байтовой точностью (т.е. bs=1), то файл будет дописываться ооочень долго. Поэтому будем считать в 512-байтных блоках, используя несколько математики. Итак (200 – размер в мегабайтах, который мы хотим получить в результате):
Записали в переменные исходный и конечный размер в байтах. Теперь, собственно, увеличение:
Проверяем, что размер теперь ровно 200 мегабайт, первые 10 миллионов байт не изменились и сколько блоков занимает сейчас файл на диске:
410008 дисковых блоков – ровно столько занимает неразрежённый файл размером 200 мегабайт на диске. Double-check:
410008 == 410008, совпадает. Итак, теперь у нас есть увеличенный до нужного размера протяжённый (не sparse) файл образа виртуальной машины с нетронутыми старыми данными, что и требовалось.
Подобного результата можно также добиться используя опции dd conv=notrunk oflag=append size = «новый размер минус старый размер», но не все версии dd умеют опцию oflag=append.
Все знают как смонтировать файловую систему из файла с её образом. Ну, там «mount -o loop …» и всё такое. Что делать если в образе разделы MBR и только внутри них файловые системы? Использовать kpartx:
Сейчас у нас есть блочное устройство /dev/loop0, представляющее собой весь диск и устройства /dev/mapper/loop0p1 и /dev/mapper/loop0p2 – разделы этого диска. Далее стандартно:
Ч0рт, второй раздел действительно своп, его нельзя смонтировать. Но с этими устройствами можно работать как с просто диском. Например, fdisk-ом увеличить размер первого раздела и поширить файловую систему на нём с помощью resize2fs.
Step 1: Checking the disk’s size of the DomU guest
In this step, we’ll do some checks from the guest VM itself. First we’ll show you the current disk size, run the following commands:
lsblk command lists block devices, as you see, we’ve two partitions / and swap.
As you see, our disk is 15 GB and We need to make it 30 GB.
Now power off your DomU guest VM by running the following command:
Читайте также: