to post messages and comments.

Проксмокс — лучшее, что я использовал в качестве гипервизоров. Скорость снапшоттинга и работы KVMовых виртуалок просто на высоте. А еще там есть вебморда, и я могу даже с мобилки управлять виртуалками ^_^ А ZFS охрененна сама по себе.

О каком Ынтерпрайзе может идти речь, если оно из коробки не умеет софтовый mdamd RAID? Нет конечно можно через пляски с бубнами накатить debian на raid, потом туда добавить proxmox, потом чидеть копаться в логах в попытках понят что за нафиг, почему не работает и может оно в итоге заведется...

lvm это конечно забавно, но если мне надо диски в гипервизоре заменить, то каким путелм лучше пойти? Пока приходит на ум только забекапить диски vm-ок и восстановить на новой инсталляции.

Прикручиваем новый винч в lvm на примере Proxmox. Записки на память...

Есть два полутерабайтника, на одном(sda) прокс, на другом(sdb) остатки венды. Расширять будем /dev/mapper/pve-data, который монтируется к /var/lib/vz. Потому что чего-то другое расширять нахрен не надо.

Для начала кромсаем sdb посредством parted:
:~# parted /dev/sdb
(parted) mklabel gpt
(parted) mkpart primary ext3 1 -1
(parted) set 1 lvm on
(parted) print
Model: ATA WDC WD5000AAKX-0 (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 500GB 500GB ntfs primary lvm

Номер Начало Конец Размер Файловая система Имя Флаги
1 1049kB 2000GB 2000GB primary lvm

(parted) quit

Запиливаем sdb1 и добавляем его в группу pve:
:~# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created
:~# vgextend pve /dev/sdb1

Расширяем логический диск '/dev/pve/data' на все деньги:
:~# lvextend -l +100%FREE /dev/mapper/pve-data
Extending logical volume data to 808.02 GiB
Logical volume data successfully resized

Меняем размер раздела, на всякий случай отмонтировав:
:~# umount /dev/mapper/pve-data
:~# resize2fs /dev/mapper/pve-data
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mapper/pve-data to 211816448 (4k) blocks.
The filesystem on /dev/mapper/pve-data is now 211816448 blocks long.

Процесс выше займёт некоторое время, а так же не обращаем внимание на название команды. Оно любое ext умеет ресайзить. Можно было и не отмонтировать(см. второй источник), но сыкотно как-то.

Затем монтируем на место и проверяем:
:~# mount /dev/mapper/pve-data
:~# df -h /dev/mapper/pve-data
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pve-data 796G 197M 796G 1% /var/lib/vz

Источники:
o-nix.com
raid.wiki.kernel.org

Надо уходить с ProxmoxVE... Сегодня на одной ноде кластера по непонятной причине отключились rgmanager и cman/corosync, что привело к переводу /etc/pve в режим "только чтение". Машины мигрировать нельзя, кластер HA не работает. Пришлось гасить ноду, причем, процесс rgmanager пришлось убивать жестко. В логах — тишина: "rgmanager #67: Shutting down uncleanly" и "fenced found uncontrolled entry /sys/kernel/dlm/rgmanager". На форумах в качестве решения — ребут. Что-то сгнило в Датском королевстве...

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

Собственно вариантов много, но из них мне нравятся только 2:
1. Каждой виртуалке по одному LVM разделу
2. Все виртуальные машины расположить на одном LVM разделе

1-й вариант мне кажется более гибким, но например, в случае изменения размера образа,
нужно будет сначала увеличить размер раздела для виртуалки, затем ресайзнуть файловую систему на этом разделе(в моем случае ext4 можно ресайзнуть без размонтирования),
затем создать новый образ, потом только пробросить его в виртуалку, и там уже добавить в виртуальную группу

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

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

жуй, расскажи на пальцах в чём разница в тегах? я читаю-читаю статьи, но нефига так и не понел. у нас есть старый сервер с proxmox, на нем каша из openvz и kvm. чую что скоро надо будет переносить на новый сервер. хотелось бы все привести к одному виду.

Обновился до 2.0, впечатления от новой веб морды крайне положительные, хотя меня и огорчило отсутствие возможности добавлять опции для нфс хранилища.
тем кто соберется обновляться совет один — не запускайте './pve-upgrade-1.9-to-2.0 --purge' --- этот адов скрит просто удалил большую часть моих системных пакетов "за ненадобностью", mdadm в том числе.
Если бы не было бэкапов то тут бы и начался адов треш и угар.

Любовь к proxmox и kvm угасла. жутко маленькая скорость сети из гостя во внешку(хоть даже до хоста, на котором kvm и запущена). 140-260 Mbits/sec! Это провал. virtio дрова не спасают. Для сравнения, скорость host-host 952 Mbits/sec. но выхода у меня уже нет. т.е. нет времени и со следующей недели надо переводить людей на новую систему.

Не знал как настроить подсеть выданную Hetzner'ом для сервера. Учитывая, что Proxmox из коробки не может этого, кто-то писал, что надо настроить routed-конфигурацию, кто-то кидал через файрвол (OMG!). Внезапно в голову пришла спонтанная мысль простая в реализации. Сделал и оно заработало.
Такое замечательное чувство. Придумал что-то сам и оно работает >.<
Правда, у этой конфигурации есть минус, но в моем случае он не имеет значения. Если дойдут руки — накидаю на skobkin.ru пост о ней.

НИКОДА НИКОГДА не создавайте в proxmox кластере машины с одинаковыми VMID. При удалении повтора proxmox к хренам собачьим удаляет lv hdd обеих машин. даже если они на разных стораджах. Как же здорово, что у меня есть бэкапы недельной давности

не пойму, как она определяет дискИО.
на работающей виртуалке график поазывает стабильно 300к на чтение. Не пойму кто и что там читается.

*cluster Я влюбился в proxmox. Зафигачил на нем кластер из 3х серверов (2 сервера — HP 2xL5420 xeon + 12Gb оперативы; 1 сервер — старенький IBM xSeries 346 Dual Xeon 2x3,4Ghz/4Gb). Скоро замутим второе внешнее хранилище iscsi и заживем :) Половину серваков перетащил на этот кластер

Сегодня словил кернел паник на продакш виртуал сервере о 4х виртуалках, две из них критические(самба и лдап).

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

Поскольку linux увы не windows, эффективно админисрировать которую можно кнопкой reset, то все это хозяйство имело такой нехуевый шанс упасть и не отжаться.
Тем не менее, после резета, fsck быстро пофиксил ошибки на рейдах и все бы ничего, но лдап в kvm`е тупа вис на загрузке. Собственно, тут меня и спас утренний бэкап, который я легко востановил через qmrestore.

Собственно, всегда делайте бэкапы. // С любовью К.О.

Hetzner'овский Proxmox VE с дефолтным конфигом из-под Rescue-системы установился очень весело. В конце установки возникли проблемы с openssh-server и proxmox-ve-2.6.35, однако установщик сказал, что все ок, система установлена. Интересно, почем я ему не верю?

ВНЕЗАПНО оказалось, что через Rescue-систему и installimage на Hetzner'овских серверах доступен Proxmox VE на ядре 2.6.35. А теперь внимание вопрос: почему, если даже официальный релиз на 2.6.32? Очередной Hetzner'овский мод как и с CentOS?

Чтобы можно было примонтировать nfs-шару внутри контейнера OpenVZ (в Promox'е, например), чтобы она не ругалась "mount.nfs: No such device" — надо на серваке для контейнера разрешить (пля, кто это только придумал) этот самый нфс!

vzctl set 101 --features "nfs:on" --save