Virtuozzo Storage: Реальный опыт эксплуатации, советы по оптимизации и решению проблем07.11.2017 12:03

Данная статья посвящена реальному опыту эксплуатации кластеров на базе Virtuozzo Storage.
За год активного внедрения и использования платформы на серверах нашего хостинга, а также при создании кластеров для наших клиентов, у нас собралось достаточно много советов, замечаний и рекомендаций. Если вы задумались о внедрении этой платформы, вы сможете учесть наш опыт при проектировании своего кластера.

Быть или не быть? За и против Virtuozzo

Если коротко, то быть. Вот список плюсов и минусов, которые мы обнаружили при использовании Virtuozzo: плюсы:

• Кластер — это удобно. Вы можете выключить виртуальную машину на одном сервере и тут же включить ее на другом, никакого копирования данных или времени на перенос. Если сервер упал, то можно сразу же поднять все виртуальные машины с упавшего сервера на одном из свободных.
• Больше не существует понятия свободного места на конкретно взятом сервере. Все сервера могут использовать общее пространство, ограниченное лишь числом дисков в кластере и вашей лицензией.
• Техническая поддержка существует и реагирует очень оперативно по телефону и электронной почте.
• В Российской Федерации есть прямой и единственный дилер, так что вы можете приобретать лицензии на юридическое лицо в рублях.
• Виртуальные машины на базе vz работают достаточно производительно и даже намного эффективнее, чем, например, на Proxmox
• Есть удобный инструмент мониторинга, который позволяет получить все необходимые сведения о работе кластера наглядно и информативно. Можно свободно распарсить данные для Zabbix, Monin или Nagios.
• Благодаря readykernel, большинство 0-day уязвимостей в ядре устраняются день в день и без перезагрузок гипервизора.
• Технология pfcache позволяет экономить оперативную память на гипервизоре (об этом ниже).
• Как ни крути, а Virtuozzo Storage — это сетевая файловая система, и ее работа сильно зависит от производительности сети. Но в Virtuozzo можно использовать локальный ssd-кеш данных для быстрого чтения и локальный ssd-журнал для записи. Плюс к тому, Virtuozzo Storage пытается перенести данные, ассоциированные с конкретной виртуальной машиной, на гипервизор, где эта виртуальная машина запущена.
• Вы можете иметь несколько типов дисков в кластере (ssd, hdd+ssd-кеш и hdd), при этом можно свободно перемещать виртуальные машины между ними. В том случае, если закончились быстрые диски, ваши машины начнут автоматически использовать диски другого типа до тех пор, пока не появится место на быстрых.
• Строго противопоказано держать диски в локальном рейде. Главный плюс для нас — это то, что копии данных хранятся не на одном сервере, а сразу на нескольких, что гораздо надежней, чем Raid.

К сожалению, минусы тоже есть (:

• Это достаточно дорого (по сравнению с ceph+kvm), особенно на больших проектах и объемах данных.
• Раз или два в месяц один из гипервизоров может зависнуть без видимых на то причин.
• Для физического освобождения места в кластере от удаленных данных внутри виртуальных машин приходится запускать очень тяжелую процедуру pcompact (об этом можно прочитать ниже).
• Поддержка очень пытается, но не может решить по-настоящему сложные вопросы. Обычно такие проблемы решаются в следующем обновлении. А пока вам предложат обновиться и перезагрузиться (в лучших традициях The IT Crowd).
• Живая миграция есть, но если в контейнере используются полуоткрытые сокеты, она отваливается с ошибкой (т.е. ее нет).
• Автоматическая миграция и запуск виртуальных машин с упавшего гипервизора есть, но минимальное количество серверов в кластере должно быть 5, уровень репликации 3:2 (т.е. 3 копии одного и того же блока данных в кластере). Автоматика не спасает, если виртуальная машина имеет статус запущенной, но зависла.
• Компоненты Virtuozzo Storage совершенно не могут нормально работать в условиях небольшого количества полностью свободной оперативной памяти. Банальный дисковый кеш Linux будет приводить к падению конкретных CS (демонов работы с дисками Virtuozzo Storage) и даже к падению виртуальных машин или гипервизора целиком.
• Панель управления Virtuozzo Automator не подходит для реального использования, скорее для просмотра статистики по ресурсам и нагрузке, а другие альтернативные панели управления не обнаружены.
• Api для автоматизации типовых операций не обнаружено. Пришлось писать свое, но и с ним не все гладко. По сути, мы выполняем типовые операции через консоль bash, но, как результат, некоторые операции могут не выполняться без видимых причин. Например, мы автоматизировали процедуру миграции виртуальной машины с гипервизора на гипервизор через серию простых действий: выключение контейнера на старом гипервизоре, миграция и собственно запуск на конечном гипервизоре. Иногда процедура запуска не срабатывает, так как может происходить слишком медленно, и наше самописное api просто отваливается. Плюс непонятно, как быть, если несколько задач будет запущено одновременно на одном гипервизоре.

Итак, с плюсами и минусами более или менее разобрались, теперь реальные рекомендации:

Установка

Если вы хотите иметь хоть какую-то возможность управлять параметрами установки, или вам нужно добавить новую ноду в старый кластер, созданный полгода назад (например, при загрузке с диска), выбираем второй пункт — установка cli.

В этом случае, правда, вы потеряете возможность получить красивую панель управления кластером.

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

Под системы swap и pfcache нужны быстрые ssd-диски. Не стоит упускать этот момент, иначе переделать будет сложно. Если со swap все более ли менее понятно, то вот что такое pfcache и с чем его есть, сходу не ясно. По сути, во всех виртуальных машинах сканируются папки по определенному пути, все библиотеки и исполняемые файлы кешируются и журнал хешей размещается в специальном локальном виртуальном диске, который, в свою очередь, хранится на системном разделе. Далее при запуске любого бинарного файла внутри виртуальной машины анализируется журнал хешей (который на диске), и в случае, если такой бинарник уже запущен, новый не запускается, а просто создается линк в памяти на существующий. Теперь представьте, что будет, если диск с журналом будет не ssd. А если там еще будет храниться swap?)

Вот как можно перенести журнал:

service pfcached stop
ploop umount /vz/pfcache.hdd/DiskDescriptor.xml
mv /vz/pfcache.hdd /mnt/ssd2/
sed '/^PFCACHE_IMAGE=/ s~.*~PFCACHE_IMAGE="/mnt/ssd2/pfcache.hdd"~' -i /etc/vz/pfcache.conf
ploop mount -m /vz/pfcache /mnt/ssd2/pfcache.hdd/DiskDescriptor.xml
service pfcached restart

В интернете полно информации, как подключить файловый swap на быстром диске и отключить старый медленный swap, дублировать не будем. Но обязательно учтите все рекомендации по дискам и сети, которые разберем ниже. А также планируйте, что серверов кластера должно быть минимум три.

Обязательно включите автоматическую синхронизацию времени на этапе установки, если не сделали, то не трудно исправить:

yum install ntp -y
systemctl stop ntpd
ntpdate  165.193.126.229 0.ru.pool.ntp.org 1.ru.pool.ntp.org 2.ru.pool.ntp.org 3.ru.pool.ntp.org
systemctl start ntpd
systemctl enable ntpd

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

echo "fs.file-max=99999999" >> /etc/sysctl.d/99-files.conf
echo "kernel.sysrq=1" >> /etc/sysctl.d/99-reboot.conf
echo "kernel.panic=1" >> /etc/sysctl.d/99-reboot.conf
sysctl -w fs.file-max=99999999
sysctl -w kernel.panic=1
sysctl -w kernel.sysrq=1

Настройки файловых лимитов, приглашения bash, опции для screen

cat > /etc/security/limits.d/nofile.conf << EOL
root      soft    nofile           1048576
root      hard    nofile           1048576
*         soft    nofile           1048576
*         hard    nofile           1048576
*         hard    core           0
EOL
cat > /etc/profile.d/bash.sh << EOL
PS1='\[\033[01;31m\]\u\[\033[01;33m\]@\[\033[01;36m\]\h \[\033[01;33m\]\w \[\033[01;35m\]\$ \[\033[00m\] '
EOL
sed -i 's/Defaults\    requiretty/#Defaults\    requiretty/g' /etc/sudoers

Очень рекомендую иметь локальный кеш данных для виртуальных машин, он должен находиться на ssd-диске. Это позволит не получать вашим виртуальным машинам данные через сеть, а брать их локально из кеша, что ускорит работу кластера и виртуальных машин во много раз.

Для этого редактируем /etc/fstab, где livelinux — имя кластера, /vz/client_cache, cachesize=50000 0 0 это путь к журналу на ssd с размером в МБ.

vstorage://livelinux /vstorage/livelinux fuse.vstorage _netdev,cache=/vz/client_cache,cachesize=50000 0 0

Сеть

Вам нужна быстрая сеть. Не стоит поднимать кластер с сетью 1 Гбит, потому что это сразу выстрел себе в ногу. Когда машин и данных станет много, у вас начнутся серьезные проблемы. Файловая система — сетевая, работа с диском происходит через сеть, балансировка и восстановление репликации тоже. Если вы забьете сеть на 100%, начнутся лавинообразные падения и тормоза. Ни в коем случае не нужно запускать кластер на 1 Гб сети, если конечно это не тестовый кластер.
Не очень хорошая, но возможная альтернатива 10 Гб оптики — сделать бондинг 2-ух гигабитных сетевых карт. Это может дать в пике до 1,5 Гб, а в очень хорошую и ясную погоду даже 2 Гб.
При этом тип бондинга желательно 802.3ad. Он, в свою очередь, требует настройки на стороне вашего сетевого оборудования. Кроме того, убедитесь, что вы выбрали xmit_hash_policy=layer3+4, так как это самый производительный вариант (по словам Virtuozzo).

Пример из /etc/sysconfig/network-scripts/ifcfg-bond0

BONDING_OPTS="miimon=1 updelay=0 downdelay=0 mode=802.3ad xmit_hash_policy=layer3+4"

При этом учтите, что бондинг будет работать только при одновременной работе сервера с двумя другими серверами. Т.е. прямой обмен между только двумя серверами будет происходить на скорости 1 Гб, а вот когда серверов уже три, вы сможете обмениваться данными уже на скорости около 1,5 Гб.

При установке первой ноды кластера сеть уже должна работать, и Virtuozzo должна иметь возможность отправлять широковещательные запросы. Другими словами, если у вас нет аплинка в сетевом интерфейсе, при финальном этапе установки Virtuozzo молча остановится и будет висеть безо всяких на то причин. На самом деле, она просто пытается послать запрос в сеть по broadcast, и если у нее это не получается, то она останавливает установку.

Ну и, конечно, крайне желательно вам иметь отдельные сетевые интерфейсы и сети для виртуальных машин и для работы кластера.

После установки Virtuozzo нужно создать сетевой мост и добавить туда реальный сетевой интерфейс. Это необходимо для работы ваших виртуальных машин с общей сетью.

prlsrvctl net add network1
prlsrvctl net set network1 -t bridged --ifname enp1s0d1 #enp1s0d1 имя реальной сетевой

Диски

Не добавляйте диски к Storage на этапе инсталляции гипервизора. Вернее, один все же придется, но после установки его нужно будет удалить и добавить снова. Все дело в том, что по умолчанию Virtuozzo все диски включала в группу tier0. Это группа дисков кластера по умолчанию, они же и самые медленные. Чтобы разделить в кластере типы дисков на ssd и не ssd, вам придется разгружать все диски, которые уже были добавлены, и добавлять их снова в нужный tier. Поменять tier диска, который уже есть в кластере, невозможно. Даже если сегодня вы не планируете иметь такое разделение, просто сделайте это сейчас. Хуже не будет, но в будущем избавитесь от многих лишних сложностей.

Еще одна проблема — это то, что при удалении дисков по инструкции остаются хвосты в виде служб, которые пытаются запустить CS для диска, которого уже нет. А если вы удалили и добавили один и тот же диск 2 раза? Тогда при любом перезапуске службы CS-диск будет пытаться стартовать дважды. Привожу простой рецепт, как правильно разгрузить и удалить CS без проблем:

cs=1071 #где цифра - номер вашего диска в кластере
cluster=livelinux #имя вашего кластера
vstorage -c $cluster rm-cs --wait $cs
systemctl stop vstorage-csd.$cluster.$cs.service
systemctl disable vstorage-csd.$cluster.$cs.service
systemctl reset-failed vstorage-csd.$cluster.*.service
systemctl | grep vstorage-csd

Чтобы добавить диск в правильный тир, вам обязательно нужно полностью пустой диск подготовить командой:

/usr/libexec/vstorage/prepare_vstorage_drive /dev/sdc --noboot

blkid #узнаем UUID диска
mkdir /vstorage/livelinux-cs4 #создаем папку для монтирования диска 

#добавляем автоматическое монтирование диска в /etc/fstab
UUID="3de71ff9-724f-483a-8984-3b78fdb3b327"  /vstorage/livelinux-cs4 ext4 defaults,lazytime   1 2

#монтируем новый диск
mount -all

#добавляем диск к кластеру livelinux (ваше имя) в тир 2 (самые быстрые диски)
vstorage -c livelinux make-cs -r /vstorage/livelinux-cs4/data -t 2

#чтобы добавить hdd-диск с локальным ssd-журналом, то команда будет такая 
#где -t 1 это тир hdd+ssd кеш, /vz/livelinux-cs6-sata-journal - путь к журналу на ssd, 
#-s 30240 это размер в мегабайтах.
vstorage -c livelinux make-cs -r /vstorage/livelinux-cs7-sata/data -t 1 -j /vz/livelinux-cs6-sata-journal -s 30240

#перезапускаем службу CS, чтобы кластер увидел ваш новый диск
systemctl restart vstorage-csd.target

Кроме того, Linux резервирует на диске некоторое место для записи журналов в папку /home
В нашем случае это бессмысленно, выключаем (в последних версиях кластера это делается при подготовке дисков, но лучше убедиться самим)

tune2fs -m 0 /dev/sdc1

Память

Представьте ситуацию: сервер является гипервизором для виртуальных машин и содержит дисковые чанки (CS) для Virtuozzo Storage. В результате, Linux все данные на физических дисках усердно помещает в дисковый кеш оперативной памяти и всячески стремится занять ее полностью, чтобы ускорить работу системы с дисками. Службы CS (диски) и MDS (распределенная файловая система) не могут быстро получить свободные страницы памяти и вынуждены всякий раз пытаться освобождать память от кеша, что долго. Плюс к тому, старые редакции Virtuozzo Cluster не могли работать с памятью, если она фрагментирована, т.е. они требовали целый блок свободной памяти в ОЗУ. Результат прост — службы чанков CS падают, в кластере образуются не реплицированные копии данных, кластер начинает их реплицировать, увеличивается интенсивность работы с дисками, CS падают еще чаще, блоков для репликации еще больше… В итоге мы имеем полностью закопанный кластер и едва живые виртуальные машины.

Начинаем разбираться и выясняется, что, кроме всего прочего, по умолчанию в Virtuozzo включен режим управления памятью, не предполагающий вообще никакой overcommit. Другими словами, виртуальные машины рассчитывают, что память будет свободна для их работы, и что никакой дисковый кеш мешать не будет. Но это еще не все. По умолчанию контейнеры могут выходить за пределы собственного дискового кеша в общий системный дисковый кеш гипервизора. При этом, как правило, системный кеш уже заполнен кешем данных CS.

Привожу ряд рекомендаций, которые нужно выполнить сразу же, еще до запуска первой виртуальной машины на кластере:

#запрещаем контейнерам выходить за пределы своей собственной оперативной памяти для размещения дискового кеша

echo "PAGECACHE_ISOLATION=\"yes\"" >> /etc/vz/vz.conf

#cами службы CS требуют память для своей работы, особенно если есть журнал для hdd-дисков, тут мы делаем ограничение, теперь службы CS могут выедать для своей работы максимум 32ГБ

cat > /etc/vz/vstorage-limits.conf << EOL
{
    "VStorage": {
        "Path": "vstorage.slice/vstorage-services.slice",
        "Limit": {
            "Max": 34359738368
            "Min": 0,
            "Share": 0.7
        },
        "Guarantee": {
            "Max": 4294967296,
            "Min": 0,
            "Share": 0.25
        },
        "Swap": {
            "Max": 0,
            "Min": 0,
            "Share": 0
        }
    }
}
EOL
service vcmmd restart

#разрешаем оверкомит памяти, иначе дисковый кеш мешает работе виртуальных машин
prlsrvctl set --vcmmd-policy density
prlsrvctl info | grep "policy"

Кроме того, можно внести некоторые изменения в настройки Linux по части работы с памятью:

touch /etc/sysctl.d/00-system.conf
echo "vm.min_free_kbytes=1048576" >> /etc/sysctl.d/00-system.conf
echo "vm.overcommit_memory=1" >> /etc/sysctl.d/00-system.conf
echo "vm.swappiness=10" >> /etc/sysctl.d/00-system.conf
echo "vm.vfs_cache_pressure=1000" >> /etc/sysctl.d/00-system.conf

sysctl -w vm.swappiness=10
sysctl -w vm.overcommit_memory=1
sysctl -w vm.min_free_kbytes=1048576
sysctl -w vm.vfs_cache_pressure=1000

И периодически сбрасывать дисковый кеш:

sync && echo 3 > /proc/sys/vm/drop_caches

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

Вот так выглядит нормальный режим работы с памятью у Virtuozzo Storage

Как можно видеть, дисковый кеш стабилен, на сервере достаточно полностью свободной памяти. Разумеется, ни о каком реальном оверкомите памяти речи идти не может. Вы должны это учитывать.

Освобождение дискового пространства, очистка мусора

Контейнеры и виртуальные машины в кластере хранятся в виде больших плоских файлов. Когда что-то удаляется внутри контейнера или виртуальной машины, фактически место не становится свободным, просто блоки данных в кластере обнуляются. Для того, чтобы решить эту проблему, разработчики Virtuozzo написали инструмент pcompact. Эта утилита запускается кроном на всех серверах одновременно в 3 часа ночи и пытается дефрагментировать образы виртуальных машин, а также удалить и очистить незанятые страницы памяти в кластере (т.е. вернуть свободное место). Сама по себе операция создает очень высокую нагрузку на сеть, на диски, а также требует дополнительной оперативной памяти для своей работы (иногда довольно много). Это может привести к падению производительности кластера на время этой операции за счет высокой утилизации сети и дисков. Также высокое потребление памяти (именно free памяти, дисковый кеш не выгружается) может привести к эффекту, описанному в пункте про память.

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

Кроме того, по умолчанию данная операция длится только 2 часа, по истечению которых автоматически прекращается. Это значит, что если у вас десяток очень крупных виртуальных машин, есть вероятность, что очистка мусора никогда не дойдет до их всех, так как не будет укладываться в двухчасовой таймаут.

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

Мониторинг

У кластера есть хорошие собственные средства мониторинга, такие как:

vstorage stat --cluster livelinux #ваше имя кластера

vstorage top --cluster livelinux #ваше имя кластера

Также есть возможность получить данные для заббикса и строить все нужные графики прямо в нем.

На примере нашего внутреннего облака компании:

Свободное место в разных тирах и общее лицензированное место кластера

Статус кластера, сколько процентов ребалансируются, сколько чанков срочно реплицируются. Пожалуй, один из важнейших графиков.

Общая сетевая нагрузка дисков всех виртуальных машин кластера и скорость репликации и ребалансинга.

Средняя и максимальная дисковая очередь в кластере.

Общая статистика по IOPS кластера.

Кроме того, не забудьте, по умолчанию фаервол на Virtuozzo запрещает работу всего, что явно не разрешено. Для zabbix-agent потребуются пара разрешающих правил фаервола:

firewall-cmd --permanent --add-port=10050/tcp
firewall-cmd --permanent --add-port=10051/tcp
firewall-cmd --permanent --add-port=5001/tcp
systemctl restart firewalld

И, в заключение, несколько полезных команд для работы с кластером

Узнать, какая виртуальная машина живет в дисковом тире:

(for i in `ls /vstorage/livelinux/private`; do grep HOSTNAME /vstorage/livelinux/private/$i/ve.conf; vstorage -c livelinux get-attr /vstorage/livelinux/private/$i|grep tier; done) | (grep "HOSTNAME\|tier" | tr '\n  ' ' ' | tr 'H' '\n' | sed 's#tier=2#SSD#g' | sed 's#tier=1#HDD#g' | sed 's#tier=2#SSD#g' | sed  's#OSTNAME=##g' | sed 's#"##g') | awk '{print $2" "$1}' | sort

Ручной запуск процесса pcompact

/usr/sbin/pcompact -v

По умолчанию Virtuozzo Storage резервирует некоторое пространство на дисках, на всякий случай. Если сильно прижало, то можно временнопонизить процент резервации:

vstorage -c livelinux set-config mds.alloc.fill_margin=1

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

fusermount -uz /vstorage/livelinux #имя вашего кластера

Узнать статистику работы локального кеша данных

watch cat /vstorage/livelinux/.vstorage.info/read_cache_info

Узнать статусы ваших лицензий

pstorage -c livelinux view-license #ваше имя кластера
vzlicupdate
vzlicview

Узнать ваш hwid

pstorage -c livelinux stat --license-hwid

Иногда случается, что размер журнала pfcache не помещается в выделенный ему виртуальный диск. Есть следующее решение

prl_disk_tool resize  resize --size 15G  --hdd /vz/pfcache.hdd/DiskDescriptor.xml

Удалить MDS-службу с сервера

vstorage -c livelinux rm-mds 11 #11-id вашего mds

Запустить службу MDS на локальном сервере

vstorage -c livelinux make-mds -a 172.17.0.254:2510 #локальный адрес на сервере -r /vz/mds/data #пусть для журналу mds, на ssd диске -b 172.17.0.255 -b 172.17.0.249 -b 172.17.0.248 -b 172.17.0.4 #адреса всех mds
systemctl restart vstorage-mdsd.target
systemctl enable vstorage-mdsd.target

Изменить количество копий данных виртуальных машин по умолчанию на серверах кластера

vstorage set-attr -R /vstorage/livelinux replicas=2

Изменить количество копий данных конкретной виртуальной машины

vstorage set-attr -R /vstorage/livelinux/private/a0327669-855d-4523-96b7-cf4d41ccff7e replicas=1

Изменить тир всех виртуальных машин, а также задать тир по умолчанию

vstorage set-attr -R /vstorage/livelinux/private tier=2
vstorage set-attr -R  /vstorage/livelinux/vmprivate tier=2

Изменить тир конкретной виртуальной машины

vstorage set-attr -R /vstorage/livelinux/private/8a4c1475-4335-40e7-8c95-0a3a782719b1 tier=2

Остановить и смигрировать все виртуальные машины на гипервизоре

hp=msk-07
for vm in `prlctl list | grep -v UUID | awk '{print $5}'`; do
prlctl stop $vm;
prlctl migrate $vm $hp;
ssh $hp -C prlctl start $vm; done

Запустить виртуальную машину принудительно на другом сервере, даже если она уже была запущена где-то, но полностью зависла или не была корректно смигрирована:

prlctl register /vz/private/20f36a7f-f64d-46fa-b0ef-85182bc41433 --preserve-uuid --force

Листинг команд для создания и настройки контейнера

prlctl create test.local --ostemplate centos-7-x86_64 --vmtype ct

prlctl set test.local  --hostname test.local  --cpus 4 --memsize 10G --swappages 512M --onboot yes
prlctl set test.local  --device-set hdd0 --size 130G
prlctl set test.local  --netif_add netif1
prlctl set test.local  --ifname netif1 --network network1
prlctl set test.local --ifname netif1 --ipadd 172.17.0.244/24
prlctl set test.local  --ifname netif1 --nameserver 172.17.0.1
prlctl set test.local  --ifname netif1 --gw 172.17.0.1

prlctl start test.local
prlctl enter test.local

Спасибо Вам большое за внимание

© Habrahabr.ru