Kvm

Всем привет. Данная статья написана для тех, кто до сих пор мечется между выбором платформ виртуализации и после прочтения статьи из серии Поставили proxmox и вообще все отлично, 6 лет аптайм не единого разрыва. Но после установки того или иного коробочного решения, возникает вопрос, а как бы тут подправить и тут, чтобы мониторинг был более понятный и вот тут, чтобы контролировать бэкапы. А потом приходит время и вы понимаете, что хочется чего то более функционального, ну или хочется чтобы внутри вашей системы стало все понятно, а не этот черный ящик или хочется использовать что- то большее чем гипервизор и куча виртуальных машин. В данной статье будет немного размышлений и практика на основе платформы Opennebula выбрал т.к. не требовательна к ресурсам и архитектура не такая сложная.

И так, как видим многие облачные провайдеры работают на kvm и делают внешнюю обвязку для управления машинами. Ясно что крупные хостеры пишут свои обвязки для облачной инфраструктуры, тот же YANDEX например. Кто то использует openstack и делает обвязку на этой основе SELECTEL, MAIL.RU. Но если у вас есть свое железо и небольшой штат специалистов, то обычно выбирают что-то из готового VMWARE, HYPER-V, есть бесплатные лицензии и платные, но сейчас не про это. Поговорим про энтузиастов это те, кто не боится предложить и попробовать новое, несмотря на то, что в компании явно дали понять Кто это потом будет после тебя обслуживать, А мы это что ли в прод потом выкатим? Страшно. Но ведь можно для начала применять данные решения в условиях тестового стенда и если всем понравится, то можно поднять вопрос о дальнейшем развитии и использовании в более серьезных средах.

Также вот ссылка на доклад www.youtube.com/watch?v=47Mht_uoX3A от активного участника развития данной платформы.

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

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

1. Повторяемость установки

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

2. Мониторинг

Будем мониторить саму ноду, kvm и opennebula. Благо уже есть готовое. Про мониторинг linux хостов есть масса вариантов, тот же заббикс или node exporter кому что больше нравится на данный момент определяю так, что мониторинг системных метрик (температура там где она может измеряться, консистентность дискового массива), через zabbix, а то что касается приложений через экспортер в прометей. По мониторингу kvm например можно взять проект github.com/zhangjianweibj/prometheus-libvirt-exporter.git и поставить запуск через systemd, вполне хорошо работает и показывает метрики kvm, также есть готовый dashboard grafana.com/grafana/dashboards/12538.

Например, вот мой файл:

/etc/systemd/system/libvirtd_exporter.service[Unit]Description=Node Exporter[Service]User=node_exporterExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"[Install]WantedBy=multi-user.target

И так у нас 1 экспортер, надо второй для мониторинга самой opennebula, использовал такой github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Можно добавить в обычный node_exporter для мониторинга системы следующее.

В файле по node_exporter меняем старт таким образом:

ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collector

Создаем директорию mkdir -p /var/lib/opennebula_exporter

bash скрипт представленный выше сначала проверяем работу через консоль, если показывает то что надо (если выдает ошибку то ставим xmlstarlet), копируем его в /usr/local/bin/opennebula_exporter.sh

Добавляем в крон задание на каждую минуту:

*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)

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



(видно что тут я сделал overcommit cpu, ram)

Для тех кто любит и использует заббикс, есть github.com/OpenNebula/addon-zabbix

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

К логированию, пока особо не приступал. Как самый простой вариант, это добавить td-agent на парсинг директории /var/lib/one с регулярными выражениями. Например, файлик sunstone.log подходит под regexp nginx и другие файлики, которые показывают историю обращений с платформой какой в этом плюс? Ну например мы можем явно отслеживать количество Error, error и быстрее отследить, где и на каком уровне есть неисправность.

3. Резервные копии

Есть также платные допиленные проекты например sep wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Тут мы должны понимать, что просто бэкапить образ машины, в данном случае совсем не то, ведь наши виртуальные машины должны работать с полной интеграцией (тот же контекст файлик, в котором описываются настройки сети, имя vm и кастомные настройки для ваших приложений). Поэтому тут определяемся что и как будем бэкапить. В некоторых случаях лучше делать копии того, что находится в самой vm. И возможно надо бэкапить только один диск от данной машины.

Например мы определились, что все машины запускаются с persistent images следовательно почитав docs.opennebula.io/5.12/operation/vm_management/img_guide.html

значит сначала с нашей vm можем выгрузить образ:

onevm disk-saveas 74 3 prom.qcow2Image ID: 77Смотрим, под каким именем он сохранилсяoneimage show 77/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8   И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.

Также в просторах сети нашел интересный доклад и есть еще такой открытый проект, но тут только под qcow2 хранилище.

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

4. Удобство использования

В данном пункте опишу те проблемы с которыми столкнулся я. Например, по образам, как мы знаем есть persistent при монтировании этого образа к vm, все данные записываются в этот образ. А если non-persistent, то копируется образ на хранилище и данные пишутся в то что скопировалось от исходного образа так работают заготовки шаблонов. Неоднократно сам себе делал проблемы тем, что забыл указать persistent и 200 гб образ копировался, проблема в том, что наверняка данную процедуру отменить нельзя, надо идти на ноду и прибивать текущий процесс cp.

Один из важных минусов это нельзя отменить действия просто используя gui. Вернее ты их отменишь и увидишь, что ничего не происходит и снова запустишь, отменишь и по факту уже будет 2 процесса cp, которые копируют образ.

И тут приходит пониманием, почему opennebula каждый новый инстанс нумерует новым id, например в том же proxmox создал vm с id 101, удалил ее, потом вновь создаешь и id 101. В opennebula такого не будет, каждый новый инстанс будет создаваться с новым id и в этом есть своя логика например, очистка старых данных или не успешных инсталляций.

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

5. Максимальная простота

Конечно тут чем дальше идешь, тем меньше становится тех, кто будет понимать тебя.

В условиях моего стенда 3 ноды с nfs хранилищем все работает в порядке. Но если проводить эксперименты на отключение энергии, то например при запуска snapshot и отключении питания ноды, у нас сохраняются настройки в БД, что есть snapshot, а по факту его нет (ну мы же все понимаем, что исходно записал в sql базу о данном действии, но сама операция прошла не успешно). Плюс в том, что при создании снимка формируется отдельный файлик и есть родитель, следовательно в случае проблем и даже если через gui не работает, мы можем забрать qcow2 файлик и восстановится отдельно docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

По сетям, к сожалению не все так просто. Ну по крайне мере проще чем в openstack, я использовал только vlan (802.1Q) вполне работает, но если вы из template network сделайте изменения в настройках, то данные настройки не применяться на уже работающих машинах т.е. надо удалить и добавить сетевую карту, тогда новые настройки применяться.

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

6. Дополнительные плагины и установки

Ведь как мы понимаем облачная платформа может управлять не только kvm, но и vmware esxi. К сожалению пула с Vcenter у меня не оказалось, если кто пробовал напишите.

В поддержке других облачных провайдеров заявлено docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Также пробовал прикрутить Vmware Cloud от селектел, но ничего не получилось в общем забил т.к. Много факторов, а писать в тех.поддержку хостинг провайдера нет смысла.

Также, сейчас в новой версии есть firecracker это запуск microvm, типа kvm обвязка над докер, что дает еще больше универсальности, безопасности и повышения производительности т.к. Не надо тратить ресурсы на эмуляцию оборудования. Я вижу только преимущество по отношению к докеру в том, что не занимает дополнительное количество процессов и нет занимаемых сокетов при использовании данной эмуляции т.е. вполне себе можно использовать как балансировщик нагрузки (но про это наверное стоит написать отдельную статью, пока не провел все тесты в полной мере).

7. Положительный опыт использования и дебаг ошибок

Хотел поделится своими наблюдениями по поводу работы, часть описал выше, хочется написать побольше. Действительно, вероятно не я один, кто сначала думает, что эта не та система и вообще тут все костыльно как с этим вообще работают? Но потом приходит понимание и что все вполне логично. Конечно всем не угодить и некоторые моменты требуют доработок.

Например, простая операция копирования образа диска с одного datastore на другой. В моем случае есть 2 ноды с nfs, отправляю образ копирование идет через frontend opennebula, хотя все мы привыкли к тому, что данные должны копироваться напрямую между хостами в той же vmware, hyper-v мы привыкли именно к этому, но тут по другому. Тут другой подход и другая идеология, и в 5.12 версии убрали кнопку migrate to datastore переносится только сама машина, но не хранилище т.к. подразумевается централизованное хранилище.

Далее популярная ошибка с разными причинами Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5 Ниже будет топ, что надо посмотреть.

• Права на образ для пользователя oneadmin;
• Права для пользователя oneadminдля запуска libvirtd;
• А правильно ли смонтирован datastore? Иди и проверь путь на самой ноде, возможно что то отвалилось;
• Неправильно сконфигурированная сеть, вернее на frontend стоит в настройках сети, что в качестве основного интерфейса для vlan стоит br0, а на ноде прописано bridge0 надо чтобы было одинаково.

system datastore хранит метаданные для вашей vm, следовательно, если вы запускаете vm с persistent image, то vm необходимо иметь доступ к изначально созданной конфигурации на том хранилище, где вы создавали vm это очень важно. Поэтому при переносе vm на другой datastore надо все перепроверить.

8. Документация, сообщество. Дальнейшее развитие

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

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

Сообщество, активное. Публикует много готовых решений, которые вы можете использовать в своих установках.

На данный момент с 5.12 изменились некоторые политики в компании forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 будет интересно узнать, как будет развиваться проект. В начале я специально указал некоторых поставщиков, которые используют свои решения и то что предлагает индустрия. Четкого ответа что использовать вам, конечно же нет. Но для небольших организаций поддержка своего маленького частного облака может обойтись не так дорого, как это кажется. Главное, точно знать, что это вам нужно.

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

Есть хороший чатик t.me/opennebula активно помогают и не отправляют искать решение проблемы в гугл. Присоединяйтесь.

Привет!

Сегодня публикуем статью о том, как написать хост KVM. Мы увидели ее в блоге Serge Zaitsev, перевели и дополнили собственными примерами на Python для тех, кто не работает с языком С++.

KVM (Kernel-based Virtual Machine) это технология виртуализации, которая поставляется с ядром Linux. Другими словами, KVM позволяет запускать несколько виртуальных машин (VM) на одном виртуальном хосте Linux. Виртуальные машины в этом случае называются гостевыми (guests). Если вы когда-нибудь использовали QEMU или VirtualBox на Linux, вы знаете, на что способен KVM.

Но как это работает под капотом?

IOCTL

KVM предоставляет API через специальный файл устройства /dev/kvm. Запуская устройство, вы обращаетесь к подсистеме KVM, а затем выполняете системные вызовы ioctl для распределения ресурсов и запуска виртуальных машин. Некоторые вызовы ioctl возвращают файловые дескрипторы, которыми также можно управлять с помощью ioctl. И так до бесконечности? На самом деле, нет. В KVM всего несколько уровней API:

• уровень /dev/kvm, используемый для управления всей подсистемой KVM и для создания новых виртуальных машин,
• уровень VM, используемый для управления отдельной виртуальной машиной,
• уровень VCPU, используемый для управления работой одного виртуального процессора (одна виртуальная машина может работать на нескольких виртуальных процессорах) VCPU.

Кроме того, существуют API для устройств ввода-вывода.

Посмотрим, как это выглядит на практике.

// KVM layerint kvm_fd = open("/dev/kvm", O_RDWR);int version = ioctl(kvm_fd, KVM_GET_API_VERSION, 0);printf("KVM version: %d\n", version);// Create VMint vm_fd = ioctl(kvm_fd, KVM_CREATE_VM, 0);// Create VM Memory#define RAM_SIZE 0x10000void *mem = mmap(NULL, RAM_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0);struct kvm_userspace_memory_region mem = {.slot = 0,.guest_phys_addr = 0,.memory_size = RAM_SIZE,.userspace_addr = (uintptr_t) mem,};ioctl(vm_fd, KVM_SET_USER_MEMORY_REGION, &mem);// Create VCPUint vcpu_fd = ioctl(vm_fd, KVM_CREATE_VCPU, 0);

Пример на Python:

with open('/dev/kvm', 'wb+') as kvm_fd:    # KVM layer    version = ioctl(kvm_fd, KVM_GET_API_VERSION, 0)    if version != 12:        print(f'Unsupported version: {version}')        sys.exit(1)    # Create VM    vm_fd = ioctl(kvm_fd, KVM_CREATE_VM, 0)    # Create VM Memory    mem = mmap(-1, RAM_SIZE, MAP_PRIVATE | MAP_ANONYMOUS, PROT_READ | PROT_WRITE)    pmem = ctypes.c_uint.from_buffer(mem)    mem_region = UserspaceMemoryRegion(slot=0, flags=0,                                       guest_phys_addr=0, memory_size=RAM_SIZE,                                       userspace_addr=ctypes.addressof(pmem))    ioctl(vm_fd, KVM_SET_USER_MEMORY_REGION, mem_region)    # Create VCPU    vcpu_fd = ioctl(vm_fd, KVM_CREATE_VCPU, 0);

На этом этапе мы создали новую виртуальную машину, выделили для нее память и назначили один виртуальный ЦП. Чтобы наша виртуальная машина действительно запускала что-то, нам нужно загрузить образ виртуальной машины и правильно настроить регистры процессора.

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

Это достаточно легко! Просто прочтите файл и скопируйте его содержимое в память виртуальной машины. Конечно, mmap тоже неплохой вариант.

int bin_fd = open("guest.bin", O_RDONLY);if (bin_fd < 0) {fprintf(stderr, "can not open binary file: %d\n", errno);return 1;}char *p = (char *)ram_start;for (;;) {int r = read(bin_fd, p, 4096);if (r <= 0) {break;}p += r;}close(bin_fd);

Пример на Python:

    # Read guest.bin    guest_bin = load_guestbin('guest.bin')    mem[:len(guest_bin)] = guest_bin

Предполагается, что guest.bin содержит валидный байт-код для текущей архитектуры ЦП, потому что KVM не интерпретирует инструкции ЦП одну за другой, как это делали старые виртуальные машины. KVM отдает вычисления настоящему ЦП и только перехватывает ввод-вывод. Вот почему современные виртуальные машины работают с высокой производительностью, близкой к голому железу, если только вы не выполняете операции с большим количеством ввода-вывода (I/O heavy operations).

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

#
# Build it:
#
# as -32 guest.S -o guest.o
# ld -m elf_i386 --oformat binary -N -e _start -Ttext 0x10000 -o guest guest.o
#
.globl _start
.code16
_start:
xorw %ax, %ax
loop:
out %ax, $0x10
inc %ax
jmp loop

Если вы не знакомы с ассемблером, то пример выше это крошечный 16-разрядный исполняемый файл, который увеличивает регистр в цикле и выводит значение в порт 0x10.

Мы сознательно скомпилировали его как архаичное 16-битное приложение, потому что запускаемый виртуальный процессор KVM может работать в нескольких режимах, как настоящий процессор x86. Самый простой режим это реальный режим (real mode), который использовался для запуска 16-битного кода с прошлого века. Реальный режим отличается адресацией памяти, она прямая вместо использования дескрипторных таблиц было бы проще инициализировать наш регистр для реального режима:

struct kvm_sregs sregs;ioctl(vcpu_fd, KVM_GET_SREGS, &sregs);// Initialize selector and base with zerossregs.cs.selector = sregs.cs.base = sregs.ss.selector = sregs.ss.base = sregs.ds.selector = sregs.ds.base = sregs.es.selector = sregs.es.base = sregs.fs.selector = sregs.fs.base = sregs.gs.selector = 0;// Save special registersioctl(vcpu_fd, KVM_SET_SREGS, &sregs);// Initialize and save normal registersstruct kvm_regs regs;regs.rflags = 2; // bit 1 must always be set to 1 in EFLAGS and RFLAGSregs.rip = 0; // our code runs from address 0ioctl(vcpu_fd, KVM_SET_REGS, &regs);

Пример на Python:

    sregs = Sregs()    ioctl(vcpu_fd, KVM_GET_SREGS, sregs)    # Initialize selector and base with zeros    sregs.cs.selector = sregs.cs.base = sregs.ss.selector = sregs.ss.base = sregs.ds.selector = sregs.ds.base = sregs.es.selector = sregs.es.base = sregs.fs.selector = sregs.fs.base = sregs.gs.selector = 0    # Save special registers    ioctl(vcpu_fd, KVM_SET_SREGS, sregs)    # Initialize and save normal registers    regs = Regs()    regs.rflags = 2  # bit 1 must always be set to 1 in EFLAGS and RFLAGS    regs.rip = 0  # our code runs from address 0    ioctl(vcpu_fd, KVM_SET_REGS, regs)

Запуск

Код загружен, регистры готовы. Приступим? Чтобы запустить виртуальную машину, нам нужно получить указатель на состояние выполнения (run state) для каждого виртуального ЦП, а затем войти в цикл, в котором виртуальная машина будет работать до тех пор, пока она не будет прервана операциями ввода-вывода или другими операциями, где управление будет передано обратно хосту.

int runsz = ioctl(kvm_fd, KVM_GET_VCPU_MMAP_SIZE, 0);struct kvm_run *run = (struct kvm_run *) mmap(NULL, runsz, PROT_READ | PROT_WRITE, MAP_SHARED, vcpu_fd, 0);for (;;) {ioctl(vcpu_fd, KVM_RUN, 0);switch (run->exit_reason) {case KVM_EXIT_IO:printf("IO port: %x, data: %x\n", run->io.port, *(int *)((char *)(run) + run->io.data_offset));break;case KVM_EXIT_SHUTDOWN:return;}}

Пример на Python:

    runsz = ioctl(kvm_fd, KVM_GET_VCPU_MMAP_SIZE, 0)    run_buf = mmap(vcpu_fd, runsz, MAP_SHARED, PROT_READ | PROT_WRITE)    run = Run.from_buffer(run_buf)    try:        while True:            ret = ioctl(vcpu_fd, KVM_RUN, 0)            if ret < 0:                print('KVM_RUN failed')                return             if run.exit_reason == KVM_EXIT_IO:                print(f'IO port: {run.io.port}, data: {run_buf[run.io.data_offset]}')             elif run.exit_reason == KVM_EXIT_SHUTDOWN:                return              time.sleep(1)    except KeyboardInterrupt:        pass

Теперь, если мы запустим приложение, мы увидим:

IO port: 10, data: 0
IO port: 10, data: 1
IO port: 10, data: 2
IO port: 10, data: 3
IO port: 10, data: 4
...

Работает! Полные исходные коды доступны по следующему адресу (если вы заметили ошибку, комментарии приветствуются!).

Вы называете это ядром?

Скорее всего, всё это не очень впечатляет. Как насчет того, чтобы вместо этого запустить ядро Linux?

Начало будет таким же: откройте /dev/kvm, создайте виртуальную машину и т. д. Однако нам понадобится еще несколько вызовов ioctl на уровне виртуальной машины, чтобы добавить периодический интервальный таймер, инициализировать TSS (требуется для чипов Intel) и добавить контроллер прерываний:

ioctl(vm_fd, KVM_SET_TSS_ADDR, 0xffffd000);uint64_t map_addr = 0xffffc000;ioctl(vm_fd, KVM_SET_IDENTITY_MAP_ADDR, &map_addr);ioctl(vm_fd, KVM_CREATE_IRQCHIP, 0);struct kvm_pit_config pit = { .flags = 0 };ioctl(vm_fd, KVM_CREATE_PIT2, &pit);

Также нам нужно будет изменить способ инициализации регистров. Ядру Linux требуется защищенный режим, поэтому мы включаем его во флагах регистра и инициализируем базу, селектор, степень детализации для каждого специального регистра:

sregs.cs.base = 0;sregs.cs.limit = ~0;sregs.cs.g = 1;sregs.ds.base = 0;sregs.ds.limit = ~0;sregs.ds.g = 1;sregs.fs.base = 0;sregs.fs.limit = ~0;sregs.fs.g = 1;sregs.gs.base = 0;sregs.gs.limit = ~0;sregs.gs.g = 1;sregs.es.base = 0;sregs.es.limit = ~0;sregs.es.g = 1;sregs.ss.base = 0;sregs.ss.limit = ~0;sregs.ss.g = 1;sregs.cs.db = 1;sregs.ss.db = 1;sregs.cr0 |= 1; // enable protected moderegs.rflags = 2;regs.rip = 0x100000; // This is where our kernel code startsregs.rsi = 0x10000; // This is where our boot parameters start

Каковы параметры загрузки и почему нельзя просто загрузить ядро по нулевому адресу? Пришло время узнать больше о формате bzImage.

Образ ядра следует специальному протоколу загрузки, где есть фиксированный заголовок с параметрами загрузки, за которым следует фактический байт-код ядра. Здесь описан формат загрузочного заголовка.

Загрузка образа ядра

Чтобы правильно загрузить образ ядра в виртуальную машину, нам нужно сначала прочитать весь файл bzImage. Мы смотрим на смещение 0x1f1 и получаем оттуда количество секторов настройки. Мы пропустим их, чтобы узнать, где начинается код ядра. Кроме того, мы скопируем параметры загрузки из начала bzImage в область памяти для параметров загрузки виртуальной машины (0x10000).

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

Наше ядро должно выводить логи на ttyS0, чтобы мы могли перехватить ввод-вывод и наш виртуальный компьютер распечатал его на stdout. Для этого нам нужно добавить console = ttyS0 в командную строку ядра.

Но даже после этого мы не получим никакого результата. Мне пришлось установить поддельный идентификатор процессора для нашего ядра (http://personeltest.ru/aways/www.kernel.org/doc/Documentation/virtual/kvm/cpuid.txt). Скорее всего, ядро, которое я собрал, полагалось на эту информацию, чтобы определить, работает ли оно внутри гипервизора или на голом железе.

Я использовал ядро, скомпилированное с крошечной конфигурацией, и настроил несколько флагов конфигурации для поддержки терминала и virtio (фреймворк виртуализации ввода-вывода для Linux).

Полный код модифицированного хоста KVM и тестового образа ядра доступны здесь.

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

Если мы скомпилируем его и запустим, мы получим следующий результат:

Linux version 5.4.39 (serge@melete) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~16.04~ppa1)) #12 Fri May 8 16:04:00 CEST 2020Command line: console=ttyS0Intel Spectre v2 broken microcode detected; disabling Speculation ControlDisabled fast string operationsx86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.BIOS-provided physical RAM map:BIOS-88: [mem 0x0000000000000000-0x000000000009efff] usableBIOS-88: [mem 0x0000000000100000-0x00000000030fffff] usableNX (Execute Disable) protection: activetsc: Fast TSC calibration using PITtsc: Detected 2594.055 MHz processorlast_pfn = 0x3100 max_arch_pfn = 0x400000000x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UCUsing GB pages for direct mappingZone ranges:  DMA32    [mem 0x0000000000001000-0x00000000030fffff]  Normal   emptyMovable zone start for each nodeEarly memory node ranges  node   0: [mem 0x0000000000001000-0x000000000009efff]  node   0: [mem 0x0000000000100000-0x00000000030fffff]Zeroed struct page in unavailable ranges: 20322 pagesInitmem setup node 0 [mem 0x0000000000001000-0x00000000030fffff][mem 0x03100000-0xffffffff] available for PCI devicesclocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 nsBuilt 1 zonelists, mobility grouping on.  Total pages: 12253Kernel command line: console=ttyS0Dentry cache hash table entries: 8192 (order: 4, 65536 bytes, linear)Inode-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)mem auto-init: stack:off, heap alloc:off, heap free:offMemory: 37216K/49784K available (4097K kernel code, 292K rwdata, 244K rodata, 832K init, 916K bss, 12568K reserved, 0K cma-reserved)Kernel/User page tables isolation: enabledNR_IRQS: 4352, nr_irqs: 24, preallocated irqs: 16Console: colour VGA+ 142x228printk: console [ttyS0] enabledAPIC: ACPI MADT or MP tables are not detectedAPIC: Switch to virtual wire mode setup with no configurationNot enabling interrupt remapping due to skipped IO-APIC setupclocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x25644bd94a2, max_idle_ns: 440795207645 nsCalibrating delay loop (skipped), value calculated using timer frequency.. 5188.11 BogoMIPS (lpj=10376220)pid_max: default: 4096 minimum: 301Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)Disabled fast string operationsLast level iTLB entries: 4KB 64, 2MB 8, 4MB 8Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4CPU: Intel 06/3d (family: 0x6, model: 0x3d, stepping: 0x4)Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitizationSpectre V2 : Spectre mitigation: kernel not compiled with retpoline; no mitigation available!Speculative Store Bypass: VulnerableTAA: Mitigation: Clear CPU buffersMDS: Mitigation: Clear CPU buffersPerformance Events: Broadwell events, 16-deep LBR, Intel PMU driver....

Очевидно, это по-прежнему довольно бесполезный результат: нет initrd или корневого раздела, нет реальных приложений, которые могли бы работать в этом ядре, но все же это доказывает, что KVM не такой уж страшный и довольно мощный инструмент.

Вывод

Чтобы запустить полноценный Linux, хост виртуальной машины должен быть намного более продвинутым нам нужно смоделировать несколько драйверов ввода-вывода для дисков, клавиатуры, графики. Но общий подход останется прежним, например, нам потребуется настроить параметры командной строки для initrd аналогичным образом. Для дисков нужно будет перехватывать ввод-вывод и отвечать должным образом.

Однако никто не заставляет вас использовать KVM напрямую. Существует libvirt, приятная дружественная библиотека для технологий низкоуровневой виртуализации, таких как KVM или BHyve.

Если вам интересно узнать больше о KVM, я предлагаю посмотреть исходники kvmtool. Их намного легче читать, чем QEMU, а весь проект намного меньше и проще.

Надеюсь, вам понравилась статья.

Вы можете следить за новостями на Github, в Twitter или подписываться через rss.

Ссылки на GitHub Gist с примерами на Python от эксперта Timeweb: (1) и (2).

Перевод статьи подготовлен в преддверии старта курса Администратор Linux. Виртуализация и кластеризация

---

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

Что такое виртуализация серверов?

Создание виртуальной или изолированной формы IT-среды называется виртуализацией. Обычно серверы могут запускать только одно приложение или операционную систему в один момент времени, что приводит к неэффективному использованию ресурсов. Когда серверы виртуализированы, это означает, что на одном сервере могут работать несколько приложений и операционных систем одновременно. Это повышает как общую эффективность, так и экономическую целесообразность. Программное обеспечение для виртуализации серверов обычно называется гипервизором.

Лучшее программное обеспечение/инструменты и поставщики для виртуализации серверов Hyper-V vs KVM vs vSphere vs XenServer

Citrix XenServer, Microsoft Hyper-V, Red Hat KVM и VMware vSphere являются крупнейшими игроками на рынке виртуализации серверов. Зачастую предприятия испытывают затруднения в принятии решения, какой гипервизор лучше всего подойдет их бизнесу.

Сравнение лучшего программного обеспечения для виртуализации серверов на основе функционала и требований к оборудованию облегчит IT-специалистам и конечным пользователям выбор наиболее подходящего для них гипервизора.

Примечание: Инструменты расположены в алфавитном порядке по их названиям.

1. Hyper-V

Запущенный в 2008 году Microsoft Hyper-V помогает в расширении или создании приватной облачной среды. Он способствует эффективному использованию оборудования, улучшает непрерывность бизнес-процессов, а также повышает эффективность разработки и тестирования.

Функционал Microsoft Hyper-V для Windows Server 2019:

• Поддержка постоянной памяти.
• Обновления экранированных VM.
• Простые двухузловые кластеры.
• Дедупликация ReFS.
• Оптимизация локальных дисковых пространств (Storage Spaces Direct)
• Центр администрирования Windows.
• Зашифрованные подсети.

Подробнее о виртуализации серверов с Microsoft вы можете прочитать в этом PDF.

2. KVM

KVM (Kernel-based Virtual Machine), входящая в состав Red Hat Virtualization Suite, представляет собой комплексное решение для инфраструктуры виртуализации. KVM превращает ядро Linux в гипервизор. Он был введен в основную ветку ядра Linux с версии ядра 2.6.20.

Функционал Red Hat KVM:

• Поддержка контейнеров
• Масштабируемость
• Overcommit ресурсов
• Disk I/O throttling
• Горячая замена виртуальных ресурсов
• Недорогое решение для виртуализации
• Red Hat Enterprise Virtualization программирование и API
• Живая миграция и миграция хранилища
• Назначение любых PCI устройств виртуальным машинам
• Интеграция Red Hat Satellite
• Поддержка восстановления после сбоя (Disaster Recovery)

Для получения более подробной информации прочтите это руководство по функционалу KVM.

3. vSphere

vSphere, платформа серверной виртуализации от VMware, представляет собой набор продуктов, который включает в себя не только виртуализацию, но и уровни управления и интерфейсов.

Она предоставляет ряд ключевых компонентов, включая инфраструктурные сервисы (vCompute, vStorage и vNetwork), сервисы приложений, vCenter Server, vSphere Client и т. д.

Функционал VMware vSphere:

• vCenter Server: инструмент централизованного управления, используемый для настройки, предоставления и управления виртуальными IT средами.
• vSphere Clien: vSphere 6.7 имеет финальную версию vSphere Web Client на основе Flash. Новые рабочие процессы в обновленном выпуске vSphere Client включают vSphere Update Manager, библиотеку контента, vSAN, политики хранения, профили хостов, схему топологии VMware vSphere Distributed Switch и лицензирование.
• vSphere SDK: предоставляет интерфейсы для сторонних решений для доступа к vSphere.
• VM File System: кластерная файловая система для VM.
• Virtual SMP: позволяет одной виртуальной машине одновременно использовать несколько физических процессоров.
• vMotion: активная миграция с целостностью транзакций.
• Storage vMotion: обеспечивает миграцию файлов виртуальных машин из одного места в другое без прерывания обслуживания.
• Высокая доступность: в случае сбоя одного сервера виртуальная машина перемещается на другой сервер с резервной емкостью для обеспечения непрерывности бизнес-процессов.
  Планировщик распределенных ресурсов (DRS): автоматически назначает и балансирует вычисления по аппаратным ресурсам, доступным для виртуальных машин.
• Отказоустойчивость: создает копию основной виртуальной машины, чтобы обеспечить ее постоянную доступность.
• Распределенный коммутатор (VDS): охватывает несколько хостов ESXi и позволяет значительно сократить объем работ по обслуживанию сети.

Для получения дополнительной информации о виртуализации серверов с помощью VMware прочтите этот PDF-файл.

4. XenServer

Основанный на Xen Project Hypervisor, XenServer является платформой виртуализации серверов с открытым исходным кодом для платформ без операционной системы. Он состоит из функций корпоративного уровня, которые помогают предприятиям легко справляться с рабочими нагрузками, комбинированными ОС и сетевыми конфигурациями.

XenServer обеспечивает улучшенную виртуализированную графику с NIVIDA и Intel и позволяет запускать несколько компьютерных операционных систем на одном оборудовании.

Функционал Citrix XenServer:

• Восстановление узла
• Защита хоста от сбоев
• Мультисерверное управление
• Управление динамической памятью
• Интеграция Active Directory
• Администрирование и контроль на основе ролей (RBAC)
• Пулы смешанных ресурсов с маскированием ЦП
• Контроллер распределенного виртуального коммутатора
• Встроенное в память кэширование операций чтения
• Живая миграция виртуальных машин и хранилище XenMotion
• Если вас интересуют подробности, вы можете прочитать этот PDF.

Сводка по vSphere, XenServer, Hyper-V и KVM

Помогите нам улучшить эту статью. Поделитесь своим мнением с нами в комментариях ниже!

Дисклеймер: последний раз эта статья была обновлена 11 января 2020 года информацией, доступной на веб-сайтах поставщиков и ресурсов в открытом доступе. Целью данной статьи является предоставление информации о гипервизорах разных поставщиков только в общих информационных целях. Поставщики могут время от времени менять характеристики своего продукта. Хотя мы прилагаем все усилия, чтобы информация была точной и актуальной, мы не можем гарантировать ее 100% точность или актуальность.

---

Узнать подробнее о курсе Администратор Linux. Виртуализация и кластеризация

---

Вам когда-нибудь доводилось уменьшать размер qcow2 образа диска, используемого в виртуальных машинах KVM-QEMU? Как известно, процесс увеличения размера образа довольно прост и быстр, а как обстоят дела с уменьшением?

В данной статье я расскажу про ситуацию, когда нужно уменьшить qcow2 образ виртуальной машины KVM в максимально быстрые сроки.


Формат блочных устройств qcow2
Но, тем не менее, эту схему можно проделать и с raw образами, достаточно сконвертировать его в qcow2. В общем-то, инструкция будет актуальна для всего, что конвертируется в qcow2.

Простой способ уменьшения диска на KVM заключается в следующих этапах:

1. Сжатие блочного устройства qcow2 (диска VM)
2. Создание диска меньшего размера
3. Подключение gparted образа, старого и нового диска
4. Подготовка к загрузке ОС
5. Характеристики VM и хост машины:

Хост: CentOS 7 + QEMU 2.12 + LIBVIRT 4.5.0 + Kernel UEK5 v. 4.14
VM: CentOS 7 + 80GB HDD + Kernel std v. 3.10
В качестве донора будет выступать виртуальная машина CentOS 7 с образом жесткого диска размером 80GB, фактически занимаемыми 20GB и физически 80GB. Уменьшать будем до 40GB.

В чем разница между размером образа, фактическим и физическим объемом?
Допустим, qcow2 image создан размером 80гб и мы об этом знаем. В процессе эксплуатации образ забивался данными, какие-то данные удалялись. Если в общих словах в связи с особенностями процесса записи-удаления данных, для ОС удаленные данные как бы не существуют, а в образе остаются записанными, пока не будут перезаписаны другими данными. Соответственно хоть в ОС Вы будете видеть 20GB фактически занимаемых данных, то хост KVM покажет такую замечательную картину (используем утилиту qemu-img для получения информации):

qemu-img info qcow2_image.img
image: qcow2_image.img
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 80G
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16

Можно заметить что virtual size = disk size, а так же du -sh образа покажет что он занимает реальные 80G:

du -sh qcow2_image.img
80G qcow2_image.img

И так как нам нужно уменьшить размер образа до 40GB, приступаем к процессу.

Этап 1 Сжатие блочного устройства (образа)

Перед началом процедуры уменьшения диска надо убедиться, что занимаемое пространство внутри ОС меньше объема, до которого диск будет так или иначе уменьшен.

df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda2 80G 18G 63G 22% /

Как мы видим, занято 18GB, что меньше 40GB. Выключаем VM командой

shutdown -h now
И переходим на хост машину, проверяем:

• сколько занимает образ физически
• сколько фактически

# qemu-img info qcow_shrink
image: qcow_shrink
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 80G
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16
# virt-df -h qcow_shrink
du -sh Filesystem Size Used Available Use%
qcow_shrink:/dev/sda1 488M 101M 351M 21%
qcow_shrink:/dev/sda2 79G 17G 62G 22%
# du -sh qcow_shrink
80G qcow_shrink

Для сжатия образа нам понадобится простая утилита virt-sparsify. Убедимся что VM не работает и выполним команду в директории вместе с образом диска (Важное замечание: перед началом virt-sparsify, убедитесь, что в /tmp и в хранилище образа достаточно свободного пространства для выполнения операции)

virt-sparsify qcow_shrink qcow_shrink-new

Результатом успешного завершения операции будет следующий вывод:

[ 0.0] Create overlay file in /tmp to protect source disk
[ 0.1] Examine source disk
[ 1.2] Fill free space in /dev/sda1 with zero
[ 1.5] Fill free space in /dev/sda2 with zero
100% 00:00
[ 72.5] Copy to destination and make sparse
[ 81.9] Sparsify operation completed with no errors.
virt-sparsify: Before deleting the old disk, carefully check that the
target disk boots and works correctly.

Затем делаем подмену диска (перемещаем qcow_shrink куда-нибудь в сторону, например qcow_shrink-old, а qcow_shrink-new на его место qcow_shrink)

mv qcow_shrink qcow_shrink-old && mv qcow_shrink-new qcow_shrink

Запускаем VM. Если всё запустилось, гасим VM и продолжаем работы.

Этап 2 Создание диска меньшего размера

Простая процедура включающая в себя всего одну команду:

qemu-img create -f qcow2 -o preallocation=metadata qcow_shrinked 40G

qcow_shrinked имя нового образа
40G новый размер

Этап 3 подключение gparted

Так как иногда админы предпочитают более легкие пути решения вопроса, бубен откладывается в сторону (kpartx) и на его место приходит ISO и VNC. К счастью, в KVM подключить его не очень сложно.

Что мы делаем:

• Подключаем образ ISO GParted
• Подключаем qcow2_shrinked к VM
• Запускаем VM, загружаемся с ISO

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



Запускаем VM и видим загрузочный экран GParted:



Выбираем первый пункт и следуем инструкциям на экране. Я обычно нажимаю enter до конца.



Увидев сам GParted, приступаем к действу. Быстренько проверяем какая у /dev/vda таблица разделов msdos или gpt. Это важно:



Переключаемся на второй диск /dev/vdb и создадим таблицу разделов:




При создании таблицы выбираем тип msdos как мы узнали ранее.

Затем переключаемся обратно на /dev/vda и последовательно, с первых дисков начинаем копировать разделы переключаясь между vda и vdb:



Конечным результатом будет:



Нажимаем Apply и ждем завершения результата:



В результате:



Что уже похоже на правду. Но так как мы сделали некоторые манипуляции, которые приведут к изменению UUID дисков, мы потенциально не загрузимся в ОС. Почему? CentOS 7 использует в fstab UUID дисков, Grub2 использует UUID дисков, поэтому прыгаем в консоль и занимаемся черной магией.

Gparted работает изначально под пользователем, поэтому прыгаем под root командой sudo su root:



Сделаем blkid чтобы убедится, что UUID разделов поменялся



Видно, что UUID vda1 = vdb1, а у vdb2 он поменялся. Ничего страшного жить с этим можно.

Монтируем vdb полностью, вместе с /boot разделом, а также смонтируем некоторые разделы для нашего удобства.

mkdir vdb2
mount /dev/vdb2 vdb2
mount /dev/vdb1 vdb2/boot
cd vdb2
mount --bind /dev dev
mount --bind /sys sys
mount --bind /proc proc
chroot .

Начнем с fstab так как в VNC набирать UUID не очень удобно, заменим его на привычное название устройства.



Заменяем строку с UUID= на, внимание:

указываем /dev/vdb2, если старый диск не планируется отключать
указываем /dev/vda2, если старый диск будет отключен

Так как мы старый диск отключаем перед загрузкой ОС, то пишем /dev/vda2

Далее изменим загрузчик, приведем его в порядок. Предположим, что всё лежит штатно в /boot/grub2, grub.cfg там же, а efi нет (msdos table, какой efi :) ):

grub2-install /dev/vdb
cd /boot/grub2
grub2-mkconfig -o grub.cfg

На этом можно порадоваться за себя и отключив gparted, загрузиться в ОС.

Этап 4 загрузка ОС

Перед загрузкой ОС я всё же рекомендую отключить старый диск от сервера. Поэтому на предыдущем этапе в fstab нужно было прописать vda2, но если Вы внимательный пользователь ПК и ничего не отключали, то проблем возникнуть не должно. Со старым диском велика вероятность загрузиться именно с него.

В процессе загрузки никаких проблем не возникло, сервер загрузился как положено. Проверим это:

[root@shrink ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 484M 0 484M 0% /dev
tmpfs 496M 0 496M 0% /dev/shm
tmpfs 496M 6.7M 489M 2% /run
tmpfs 496M 0 496M 0% /sys/fs/cgroup
/dev/vdb2 40G 18G 23G 44% /
/dev/vdb1 488M 101M 352M 23% /boot
tmpfs 100M 0 100M 0% /run/user/0

[root@shrink ~]# blkid
/dev/vda1: UUID="ea505196-32fb-4df6-8bed-0a0ab2d0b726" TYPE="ext4"
/dev/vda2: UUID="30ec1bc6-658f-4611-8708-5e3b7ebaa467" TYPE="xfs"
/dev/vdb1: UUID="ea505196-32fb-4df6-8bed-0a0ab2d0b726" TYPE="ext4"
/dev/vdb2: UUID="c8548834-272b-4331-a9bf-aa99fb41a434" TYPE="xfs"
/dev/sr0: UUID="2019-03-21-13-42-32-00" LABEL="GParted-live" TYPE="iso9660" PTTYPE="dos"

Мы видим, что /boot и / нужные, размер 40GB, ОС работает. Счастье, не иначе!

Бонус

То, с чем придется столкнуться в некоторых ситуациях.

1. Если VM на Windows, то вместо virt-sparsify можно использовать сжатие тома внутри ОС. Технически весь процесс одинаковый, однако известно, что метки тома меняются (мы это видели ранее в blkid), а значит Windows надо знать, что есть что в новой реальности. Для этого загружаемся в режим восстановления (после всех операций) и делаем fixmbr + rebuildbcd. Что именно и как да поможет вам man
2. Великая проблема с xfs напороться на Superblock has unknown read-only compatible features (0x4) enabled. После загрузки ОС она будет работать в режиме read-only, а всё будет смонтировано как надо. Решение до безумия простое:

Скорее всего, когда всё делалось в gparted или ином окружении, версия ядра этого окружения была слишком новой, в котором xfs немного изменен, а именно отличаются метаданные и их версия. В результате xfs сделанный в новом ядре, превращается в тыкву на старом. Что делаем загружаемся обратно в rescue gparted, поднимаем в этом rescue окружении сеть и ставим максимально свежее ядро в ОС. Я ставил 5.х на CentOS 7, возможно подойдет и 4.х, не проверял, но в итоге всё работало. Причем, без особых проблем.

На этом всё!

Как видите, ничего сложного в этом нет. Конечно, можно использовать LVM, resize2fs и прочие штуки, но всё-таки qcow2 где-то ещё используется и кому-то даже нужен.

Если вы знаете способ ещё более простой напишите о нём в комментариях.