The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Создание виртуальных машин с помощью Qemu KVM
В статье опишу мой опыт про подготовку и запуск виртуальных машин (ВМ) с
помощью открытых и бесплатных средств виртуализации в Linux - Qemu KVM.

В качестве среды для выполнения виртуальных машин будет использоваться Fedora
Linux 36, аналогично ВМ можно запускать в Centos 8 и выше.

Для запуска ВМ понадобятся пакеты:

  • qemu-kvm (qemu-system-x86) - эмулятор
  • qemu-img - средство создания и управления виртуальными дисками
  • edk2-ovmf - образы прошивки UEFI Будет рассмотрено три типа виртуальных машин:
  • Виртуальная машина с BIOS
  • Виртуальная машина с UEFI
  • Кластер виртуальных машин с общим диском Подготовка виртуальной сети В Qemu я использую два режима подключения сети в гостевую ВМ - user networking и с использованием устройств tap. Первый режим проще, не требует root прав, но у него меньше производительность, в таком режиме не работает протокол ICMP и он не позволяет обратится к ВМ из физической сети. Второй режим предоставляет большее быстродействие при работе с сетью, его можно гибко настраивать, но он требует root права. Пользовательская виртуальная сеть Простейшую ВМ с пользовательской сетью можно запустить так: qemu-kvm \ -m 1G \ -device virtio-net-pci,netdev=lan \ -netdev user,id=lan \ -drive file=/tmp/livecd.iso,media=cdrom Ключевым параметром, который включает пользовательский режим сети это -netdev user. Такая команда запустит LiveCD внутри ВМ c 1024 МБ ОЗУ, в качестве сетевой карты будет использовано устройство Virtio. Виртуальная машина автоматически получит ip-адрес из подсети 10.0.2.0/24, шлюз - 10.0.2.2, dns-сервер - 10.0.2.3. К физическому хосту можно обратиться по адресу 10.0.2.2. ICMP пакеты через такой тип сети не проходят. Виртуальная сеть с использованием tap-устройств В данном режиме при запуске ВМ в физической системе будет создано виртуальное сетевое tap-устройство, что потребует root прав sudo qemu-kvm \ -m 1G \ -device virtio-net-pci,netdev=lan \ -netdev tap,id=lan,ifname=tap0 \ -drive file=/tmp/livecd.iso,media=cdrom При таких настройках машина запустится, но не будет иметь доступа к физической сети. Для предоставления доступа необходимо создать сетевой мост, добавить в него физический сетевой адаптер хоста и настроить скрипты добавления виртуального сетевого tap-устройства в сетевой мост. Предположим, что физический хост подключен к сети через адаптер enp3s0 и имеет адрес 192.168.1.50/24, шлюз 192.168.1.1. Удалим все сетевые настройки у адаптера enp3s0 и создадим сетевой мост с помощью Network Manager: root# nmcli connection show root# nmcli connection delete <имя подключения enp3s0> root# nmcli connection add type bridge ifname br0 con-name bridge bridge.stp false ipv4.method manual ipv4.addresses "192.168.1.50/24" ipv4.gateway 192.168.1.1 ipv6.method disabled Добавляем физический адаптер хоста в сетевой мост: nmcli con add type bridge-slave ifname enp3s0 con-name nicHost master br0 Настраиваем скрипт добавления виртуального сетевого tap-устройства к мосту - /etc/qemu-ifup: #!/bin/sh /usr/sbin/brctl addif br0 $1 /usr/sbin/ip link set dev $1 up Скрипт удаления tap-устройства из моста /etc/qemu-ifdown: #!/bin/sh /usr/sbin/ip link set dev $1 down /usr/sbin/brctl delif br0 $1 В скриптах $1 указывает на имя виртуального сетевого адаптера (tap0, tap1 и т.п.). Если потребуется разместить скрипты по другому пути, то их месторасположение можно указать в свойствах виртуального сетевого устройства с помощью директив script и downscript: sudo qemu-kvm \ -m 1G \ -device virtio-net-pci,netdev=lan \ -netdev tap,id=lan,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ -drive file=/tmp/livecd.iso,media=cdrom Запускаем виртуальную машину и проверяем сеть. ВМ получила адрес от DHCP сервера локальной сети. Проверяем состав сетевого моста на физическом хосте с помощью команды brctl show: В хост-системе появилось устройство tap0, и оно автоматически добавилось в сетевой мост. По-умолчанию, все виртуальные сетевые адаптеры получают MAC адрес 52:54:00:12:34:56, если потребуется запустить несколько виртуальных машин на хосте, то необходимо указать разные адреса с помощью параметра mac: sudo qemu-kvm \ -m 1G \ -device virtio-net-pci,mac=52:54:00:00:00:01,netdev=lan \ -netdev tap,id=lan,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ -drive file=/tmp/livecd.iso,media=cdrom Подготовка виртуальных дисков Ранее мы запускали ВМ с LiveCD. Для того чтобы установить операционную систему в виртуальную машину нам понадобится создать виртуальные диски для хранения данных. Создание виртуальных дисков qemu-img create -f qcow2 vmpath/disk.qcow2 20G Данная команда создаст "тонкий" диск в формате qcow2, объёмом 20 Гб. Если потребуется создать кластерный диск, то необходимо для него всё место выделить заранее и использовать тип диска raw: qemu-img create -f raw -o preallocation=falloc shared/shared.raw 10G Использование снимков состояния дисков Формат дисков qcow2 позволяет создавать и удалять внутри диска снимки состояний (снапшоты):
  • создание снимка: qemu-img snapshot -c snapshotName vmpath/disk.qcow2
  • список снимков: qemu-img snapshot -l vmpath/disk.qcow2
  • применить снимок (вернуть диск в состояние на момент снимка): qemu-img snapshot -a snapshotName vmpath/disk.qcow2
  • удалить снимок: qemu-img snapshot -d snapshotName vmpath/disk.qcow2 Вся работа со снимками будет производится внутри одного образа, что может потребовать времени. Другим способом создания снимков состояний является создание промежуточного файла (backing file) - при создании такого файла вся запись будет вестись в него вместо базового образа: qemu-img create -f qcow2 -F qcow2 -b vmpath/disk.qcow2 vmpath/backingDisk.qcow2 При запуске ВМ указываем в качестве диска промежуточный файл: qemu-kvm -m 1G -drive file=vmpath/backingDisk.qcow2,media=disk Чтобы откатить снапшот, достаточно перенастроить запуск на изначальный образ диска и удалить снапшот. qemu-kvm -m 1G -drive file=vmpath/disk.qcow2 ,media=disk rm vmpath/backingDisk.qcow2 Изменение первоначального образа приведёт к повреждению снапшота, поэтому после запуска ВМ с оригинальным диском все снапшоты станут бесполезными. Подключение разделов виртуального диска к хост-системе Если возникнет необходимость обратиться к файлам на виртуальном диске напрямую с хост-системы, то необходимо сначала смонтировать образ. Для того, чтобы смонтировать разделы виртуального диска к хост-системе необходимо воспользоваться утилитой qemu-nbd. 1. Загружаем модуль ядра nbd root# modprobe nbd max_part=8 2. Подключаем образ виртуального диска как сетевое блочное устройство: root# qemu-nbd --connect=/dev/nbd0 vmpath/disk.qcow2 3. Выполняем нужные нам операции с устройством: root# fdisk /dev/nbd0 -l root# mount /dev/nbd0p1 /mnt/volume/ root# umount /dev/nbd0p1 4. Отключаем устройство root# qemu-nbd --disconnect /dev/nbd0 root# rmmod nbd Запуск виртуальной машины с BIOS в Qemu KVM По-умолчанию Qemu KVM запускает виртуальные машины с BIOS, поэтому особых настроек не требуется. Готовим диск для гостевой системы: qemu-img create -f qcow2 /mnt/virtual/bios/bios.qcow2 20G Запускаем ВМ: sudo qemu-kvm \ -machine pc \ -smbios type=1,manufacturer=oVirt,product=RHEL,version=1 \ -cpu host \ -accel kvm \ -smp cpus=2,sockets=1,cores=2 \ -m 1G \ -k en-us \ -vga qxl \ -rtc base=localtime \ -netdev tap,id=lan,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ -device virtio-net-pci,mac=52:54:00:00:00:01,netdev=lan \ -drive file=/mnt/virtual/bios/bios.qcow2,if=virtio,media=disk,index=0 \ -drive file=/mnt/shared/linuxos.iso,media=cdrom,index=1 Параметры:
  • machine - свойства чипсета, основные это pc (совместимый со многими и ОС) и q35 (поддерживает новые устройства)
  • smbios - описание BIOS
  • cpu - тип эмулируемого ЦП, host указывает использовать как в физической системе
  • accel - тип ускорение виртуализации
  • smp - описываем кол-во виртуальных ядер ЦП и их распределение по сокетам
  • m - объём ОЗУ
  • k - раскладка клавиатуры консоли
  • vga - тип виртуального видеоадаптера
  • rtc base - настройки часов RTC
  • netdev/device и drive - описание сетевой карты и виртуальных дисков Загружаемся с CD-ROM и устанавливаем ОС. Запуск виртуальной машины с UEFI в Qemu KVM Для запуска виртуальной машины с UEFI нам потребуются прошивки из пакета edk2-ovmf. Готовим виртуальный диск для гостевой системы: qemu-img create -f qcow2 /mnt/virtual/uefi/uefi.qcow2 20G Из пакета edk2-ovmf копируем образы UEFI и NVRAM: cp /usr/share/edk2/ovmf/OVMF_CODE.fd /mnt/virtual/uefi cp /usr/share/edk2/ovmf/OVMF_VARS.fd /mnt/virtual/uefi Запускаем ВМ: sudo qemu-kvm \ -machine q35 \ -smbios type=1,manufacturer=oVirt,product=RHEL,version=1 \ -cpu host \ -accel kvm \ -smp cpus=4,sockets=1,cores=4 \ -m 4G \ -k en-us \ -vga qxl \ -device virtio-net-pci,mac=52:54:00:00:00:02,netdev=lan \ -netdev tap,id=lan,ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ -drive if=pflash,format=raw,readonly=on,file=/mnt/virtual/uefi/OVMF_CODE.fd \ -drive if=pflash,format=raw,file=/mnt/virtual/uefi/OVMF_VARS.fd \ -drive file=/mnt/virtual/uefi/uefi.qcow2,if=virtio,media=disk \ -drive file=/mnt/shared/linuxos.iso,media=cdrom Подключаем прошивку UEFI для чтения с помощью drive if=pflash с указанием readonly=on, а также файл для хранения NVRAM, но уже в режиме записи. Загружаемся с CD-ROM и устанавливаем ОС. Запуск виртуальных машин с UEFI с общим кластерным диском в Qemu KVM Рассмотрим пример запуска двух машин, где у каждой будет свой индивидуальный диск для ОС и один общий диск для кластера. Подключать диски будем с помощью устройства -device virtio-blk-pci, оно позволяет включить совместную запись на диск с нескольких виртуальных машин c помощью параметра share-rw=on. Готовим диски для гостевых систем: qemu-img create -f qcow2 /mnt/virtual/cluster/vm1-system.qcow2 20G qemu-img create -f qcow2 /mnt/virtual/cluster/vm2-system.qcow2 20G Для кластерного диска используем формат raw и заранее резервируем место. qemu-img create -f raw -o preallocation=falloc /mnt/virtual/cluster/shared.raw 10G Копируем образы прошивки UEFI и NVRAM: cp /usr/share/edk2/ovmf/OVMF_CODE.fd /mnt/virtual/cluster cp /usr/share/edk2/ovmf/OVMF_VARS.fd /mnt/virtual/cluster/OVMF_VARS_VM1.fd cp /usr/share/edk2/ovmf/OVMF_VARS.fd /mnt/virtual/cluster/OVMF_VARS_VM2.fd Запускаем ВМ 1: sudo qemu-kvm \ -machine q35 \ -smbios type=1,manufacturer=oVirt,product=RHEL,version=1 \ -cpu host \ -accel kvm \ -smp cpus=2,sockets=1,cores=2 \ -m 2G \ -k en-us \ -vga qxl \ -device virtio-net-pci,netdev=lan,mac=52:54:00:00:00:11 \ -netdev tap,id=lan,ifname=tap11 \ -drive if=pflash,format=raw,readonly=on,file=/mnt/virtual/cluster/OVMF_CODE.fd \ -drive if=pflash,format=raw,file=/mnt/virtual/cluster/OVMF_VARS_VM1.fd \ -device virtio-blk-pci,drive=drive0,share-rw=off \ -drive file=/mnt/virtual/cluster/vm1-system.qcow2,id=drive0,format=qcow2,if=none \ -device virtio-blk-pci,drive=drive1,share-rw=on \ -drive file=/mnt/virtual/cluster/shared.raw,id=drive1,format=raw,if=none \ -drive file=/mnt/shared/linuxos.iso,media=cdrom Запускаем ВМ 2: sudo qemu-kvm \ -machine q35 \ -smbios type=1,manufacturer=oVirt,product=RHEL,version=1 \ -cpu host \ -accel kvm \ -smp cpus=2,sockets=1,cores=2 \ -m 2G \ -k en-us \ -vga qxl \ -device virtio-net-pci,netdev=lan,mac=52:54:00:00:00:12 \ -netdev tap,id=lan,ifname=tap12 \ -drive if=pflash,format=raw,readonly=on,file=/mnt/virtual/cluster/OVMF_CODE.fd \ -drive if=pflash,format=raw,file=/mnt/virtual/cluster/OVMF_VARS_VM2.fd \ -device virtio-blk-pci,drive=drive0,share-rw=off \ -drive file=/mnt/virtual/cluster/vm2-system.qcow2,id=drive0,format=qcow2,if=none \ -device virtio-blk-pci,drive=drive1,share-rw=on \ -drive file=/mnt/virtual/cluster/shared.raw,id=drive1,format=raw,if=none \ -drive file=/mnt/shared/linuxos.iso,media=cdrom Далее нужно установить ОС внутри ВМ и настроить работу с кластерным диском.
  •  
    08.09.2022 , Автор: Slonik , Источник: https://dzen.ru/media/id/5ddabd8382...
    Ключи: qemu, kvm, virtual
    Раздел:    Корень / Безопасность / Виртуализация - Xen, OpenVZ, KVM, Qemu

    Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Аноним (-), 23:19, 10/09/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А если я не хочу едк, а например рефинд с темной темкой ?
     
  • 1.2, pavlinux (ok), 14:40, 11/09/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Запуск виртуальных машин с UEFI

    Нахрен самому себе создавать гемор?

     
     
  • 2.4, casm (ok), 17:33, 11/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    "В Fedora 37 намерены оставить только поддержку UEFI"
    https://www.opennet.ru/opennews/art.shtml?num=56974

    Думаю, что в RHEL/Centos версий 15...20 только UEFI и останется.
    Лучше заранее приготовиться ко встрече со звездой.

     
  • 2.11, Аноним (-), 12:40, 18/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это фидорист, ему по статусу положено делать ку любым бзикам редхатовских маркетологов.
     
     
  • 3.20, Аноним (20), 21:03, 23/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Убунту тоже, что-то мутит и уже с прошлого года, а может с начала этого года в виртуальную машину с BIOS, а не с EFI установка проходит с ошибкой. Я так вижу, устанавливал.
     
     
  • 4.21, Аноним (20), 21:05, 23/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Но работает. Только не понятно правильно или нет. Видимых проблем после такой установки не видел.
     
  • 4.22, Аноним (20), 21:11, 23/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Точнее так: Canonical Ltd в Ubuntu тоже что-то мутит и уже с прошлого года, а может с начала этого года в виртуальную машину с BIOS, а не с EFI установка проходит с ошибкой. Я так вижу, устанавливал.
     
  • 2.18, Аноним (18), 08:34, 20/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Т.к. проприетарные иначе не могут. Сабж у бренда из первой 10-тки работает по разному в обоих вариантах. А тестировать надо.

    Тем самым - чтобы меньше использовать проприетарное.

     

  • 1.3, pavlik (?), 16:21, 11/09/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Посмотрите в сторону cloud-images, постоянно ставить оси на новые виртуалки это лениво.
    Пришёл в своё время к vagrant c vitrualbox на ноуте когда надо вот прямо щас, или libvirt с cloud-images, если необходимо чтобы виртуалки крутились круглосуточно на сервере.
    https://sumit-ghosh.com/articles/create-vm-using-libvirt-cloud-images-cloud-in тут примерный рецепт, можно завернуть в шелл скрипт и прекрасно работает. Конечно нужен готовый cloud-image, но у большинства популярных дистрибутивов такой должен быть.
     
     
  • 2.6, ыпр (?), 13:08, 15/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    еще vagrant бы нормально работал с ru ip
     
     
  • 3.8, pavlik (ok), 21:09, 15/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да, боксы приходится вручную таскать или использовать tsocks/vpn.
     
  • 2.19, Аноним (18), 08:37, 20/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > постоянно ставить оси на новые виртуалки это лениво

    Это делает скрипт. Настраивает ровно то, в чём есть нужда. Тема отдельной статьи.

     

  • 1.5, vasiukoff (?), 16:15, 13/09/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень годно написано. Обязательно продолжайте Вашу светлую миссию и не слушайте никого.
     
  • 1.7, commiethebeastie (ok), 19:57, 15/09/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Надо virtio-scsi использовать, а не просто virtio. SCSI поддерживает trim к примеру.
     
     
  • 2.10, casm (ok), 06:46, 17/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    У меня если указать virtio-scsi в -drive, то ВМ не запускается, пишет неизвестная шина.
    Смотрел как это сделано в oVirt, там для virtio-scsi используют -device virtio-scsi-pci и -device scsi-hd. А trim прописывают в blockdev.
    Как по-простому сделать не разобрался.
     

  • 1.9, Аноним (9), 23:18, 15/09/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня винт вот так подключён (запускаю из bash портянки):

    # PCIE CONTROLLER
    -device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1

    # SCSI CONTROLLER
    -object iothread,id=iothread0
    -device virtio-scsi-pci,iothread=iothread0,id=scsi0,bus=pci.2,addr=0x0

    # SSD1
    -blockdev node-name=ssd1-storage,driver=file,cache.direct=on,cache.no-flush=off,auto-read-only=on,discard=unmap,filename=/dev/mapper/vhdd1
    -blockdev node-name=ssd1-format,driver=raw,read-only=off,discard=unmap,detect-zeroes=unmap,cache.direct=on,cache.no-flush=off,file=ssd1-storage
    -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=ssd1-format,id=scsi0-0-0-0,write-cache=on,bootindex=1

     
     
  • 2.12, Аноним (-), 12:41, 18/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем виртуалке свой винч? Чтобы ее менеджить неудобнее потом было?
     
     
  • 3.13, Аноним (-), 10:13, 19/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Для накопителя используется выделенный логический том LVM (/dev/mapper/vhdd1), физически расположенный на SSD накопителе.
    Доступ гостевой ОС к нему осуществляется напрямую (driver=raw), без дополнительных слоёв абстракций (вроде LVM -> ext4 -> qcow2), что повышает производительность.

    Не совсем понятно, в чём неудобство заключается?
    Бекап делается автоматически через кастомный скрипт сразу как виртуалка выключается (на уровне файлов, там их немного), а что ещё надо?

     

  • 1.16, Аноним (16), 20:24, 19/09/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Свой скрипт для моста нужен был когда-то давно, когда не было qemu-bridge-helper.
    Для -netdev bridge используется этот helper и права root не нужны.
     
     
  • 2.17, Аноним (17), 21:02, 19/09/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё необходимо добавмит мост в /etc/qemu/bridge.conf
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру