Новый сервер, новый Xen

Строю тут новый небольшой домашний сервер. Действительно небольшой – машинка в формате MiniITX, в корпусе Chieftec Compact IX-01B (IX-01B-OP), который я уже раньше использовал при построении криптоноды. Внутри – Gigabyte J4005N D2P с интегрированным Celeron J4005 с пассивным охлаждением. Хотелось компактную современную замену используемым у меня ранее материнкам Asus на AMD C60.

И замена вышла весьма неплохой. Техпроцесс на несколько поколений новее, чем у C60 (14 нм против 40), радиатор практически холодный. На материнке есть слот m.2 с M-key – там отлично заработал родной диск с моего ноута. Хотя оставлять его тут не буду – поставлю в потихоньку собираемый десктоп.

Есть 2 слота под память и изначально планировал поставить тут 16 ГБ (чтобы хватило для хостов с linuxoid.in), но тут вышел казус: машинка не захотела работать с двумя однорядными планками Team TED48G2400C1601. Не захотела материнка запускаться и с парой 4+8 (обе однорядные). В общем, пришлось оставить 8, хотя бы на пока.

Диски – традиционная парочка Hitachi Travelstar 7K1000 в зеркале.

Питание – picoPSU и внешний блок питания на 12В. PicoPSU был с весьма габаритными разъемами, которые перекрывали соседний слот памяти на материнской плате, но в целом пользоваться было можно, если сначала установить память, а потом уже picoPSU. Проблемы начались, когда начал закреплять планку с жесткими дисками – один из них упирался в эти разъемы. Пришлось модифицировать picoPSU, перепаяв разъемы на другую сторону платы – в этом случае они начинали смотреть в сторону лицевой панели корпуса и ничему не мешали.

При перепайке убился один из управляющих транзисторов в цепи включения +12В 🙁 – заменил на КТ3107.

У материнки есть одна неприятная особенность при использовании режима автовключения при подаче питания: при включении и перезагрузке машина сначала включается на несколько секунд, потом гасит питание и потом включается уже нормально. Ладно бы еще сама машина дергается, но это бьет по жестким дискам. Хотя на сервере такие ситуации не должны быть частыми, но все же…

По софту – развернул на машинке Debian 9. Как обычно, экспертный режим, raid, lvm. Железо новое, решил использовать EFI-раздел, но поставил GRUB. Загрузился в систему, поставил xen, перезагрузился (при этом почему-то xen не стал первым пунктом, несмотря на все необходимые приготовления – да и раньше как-то установка xen подразумевала, что xen’ом будут пользоваться и надо грузить его) и тут возникла проблема – машина мертво вешалась после загрузки initrd. В какой-то момент машина вообще перестала запускаться – пришлось сбрасывать BIOS.

Итог поисков в интернете – отказаться от GRUB и грузить xen напрямую, средствами EFI. Скопировал /boot/xen-4.8-amd64.efi в /boot/efi/EFI/xen/xen.efi, создал конфиг /boot/efi/EFI/xen/xen.cfg вида

[global]
default=debian9

[debian9]
options=console=vga,com1 com1=115200 loglvl=all dom0_mem=1024M:1536M cpufreq=xen
kernel=vmlinuz root=/dev/mapper/mls-root ro quiet net.ifnames=0 biosdevname=0 bootdegraded=true memtest=17
ramdisk=initrd.img

Не знаю, нужно ли мне было описание консоли и tty – просто скопировал с мануала, где как раз была подобная проблема. cpufreq=xen прилетело с работающего сейчас сервера. Остальное, в принципе, понятно. В тот же каталог нужно скопировать ядро и initrd под указанными в конфиге именами, а на будущее, чтобы новые ядра копировались из /boot туда автоматом – создаем скриптик /etc/kernel/postinst.d/zz-update-efistub:

#!/bin/bash
cp /vmlinuz /boot/efi/EFI/xen/vmlinuz
cp /initrd.img /boot/efi/EFI/xen/initrd.img

Ну и делаем исполняемым. Все, дальше все работало. Можно снести GRUB целиком.

На пока вроде все.

4 мысли о “Новый сервер, новый Xen”

  1. Первое дополнение: xendomains обламываются запуститься на той конфигурации, что у меня используется сейчас на старом сервере. Причина: на старом сервере у меня в interfaces описано несколько vlan’ов и бриджей, на которые подключаются domU (независимые сети для различных групп сервисов). Тут сделал так же, но – у xendomains.service в зависимостях нет networking.service и, в итоге, когда нужно поднять сохраненные домены (и подключить их к соответствующим сетевым интерфейсам) – нужных сетевых интерфейсов еще не существует. Фиксим:
    # systemctl edit xendomains.service
    там пишем
    [Unit]
    Requires=networking.service
    Все

  2. Подобное поведение стоит держать в памяти и для других сервисов. Только что столкнулся с тем, что NUT поднимается не на всех интерфейсах, а только на локалхосте. Перезапуск решает проблему. Похоже, нужные интерфейсы еще не поднимаются в то время, когда стартует nut-server.

  3. Из нового, что забыл упомянуть – иное поведение мостов (bridge) на свежих ядрах. Почему-то теперь трафик через них по-дефолту обрабатывается в iptables – непонятно зачем, если есть ebtables и вообще это другой уровень. Лечится так:

    sysctl net.bridge.bridge-nf-filter-pppoe-tagged=0
    sysctl net.bridge.bridge-nf-filter-vlan-tagged=0
    sysctl net.bridge.bridge-nf-call-ip6tables=0
    sysctl net.bridge.bridge-nf-call-iptables=0
    sysctl net.bridge.bridge-nf-call-arptables=0

    Ну, как минимум, последними call’ами. После этого бридж становится снова обычным прозрачным “свичом” для воткнутых в него интерфейсов.

Добавить комментарий