Лучшие практики виртуальных машин и RAW против QCOW2
Tl/Dr: восстановление виртуальных машин после сбоя ОС SSD. Ищите советы по передовому опыту, чтобы узнать, что я что-то упустил, и чтобы убедиться, что RAW против QCOW2 имеют различия в производительности, и могут ли они быть настроены с помощью одной и той же команды или нужны другие команды для их настройки. Я не очень хорошо разбираюсь в Linux, поэтому мне нужно немало времени, чтобы расшифровать рекомендации, хотя заранее спасибо!
Привет всем, я очень зеленый пользователь с сервером Ubuntu, даже после его использования в течение нескольких лет, в комплекте это забыть. У меня был сбой сервера из-за сбоя ОС SSD, используемого для ОС, и я никогда не удосужился сделать его резервную копию. Я снова включил и запустил систему, но сейчас я готовлюсь к тому, чтобы восстановить виртуальные машины. Раньше я был на 14.04 LTS, но сейчас я на 18.04 LTS. Код ниже в основном то, что я использую для раскрутки виртуальных машин, и он работал довольно хорошо. Я смотрю, чтобы увидеть, есть ли что-то, что я пропускаю, насколько лучшие практики идут с этим.
Мне НУЖНО добавить доступ к консоли, поскольку сбой SSD начался с виртуальной машины, которая не запускалась после перезагрузки, и именно тогда она вышла из-под контроля. Виртуальная машина "запускается" и может быть проверена, но отказывается от SSH-соединений, поэтому не ПОЛНОСТЬЮ запускается. Мне все еще нужно научиться настраивать консоль, и я буду работать с этим на этой неделе, но мне интересно, есть ли что-то еще, что я пропускаю здесь.
sudo ubuntu-vm-builder kvm xenial \
--dest /mnt/Chaos.raw \
--hostname Chaos \
--arch amd64 \
--mem 4096 \
--cpus 4 \
--user admin \
--pass password \
--bridge br0 \
--ip 172.16.5.21 \
--mask 255.255.255.0 \
--net 172.16.5.0 \
--bcast 172.16.5.255 \
--gw 172.16.5.1 \
--dns 172.16.5.2 \
--components main,universe \
--addpkg acpid \
--addpkg openssh-server \
--addpkg nfs-common \
--addpkg linux-image-generic \
--addpkg postfix \
--addpkg mailutils \
--addpkg libsasl2-2 \
--addpkg ca-certificates \
--addpkg libsasl2-modules \
--addpkg htop \
--rootsize=100000 \
--libvirt qemu:///system ;
Мне было предложено на Reddit, что использование RAW вместо QCOW2 позволит ВМ работать быстрее и иметь лучшую производительность. Я хотел получить отзыв об этом. Я попробовал другой метод создания виртуальной машины, как показано ниже, и он работал, но я не могу понять, как его использовать. Как, черт возьми, я подключаюсь к нему, я понятия не имею, также я не знаю, как настроить информацию о сети при настройке, я пробовал несколько способов с MANPAGE, но я получал ошибки.
virt-install \
--connect qemu:///system \
--name Chaos \
--memory 4096 \
--vcpus cpuset=1-4 \
--disk=path=/mnt/Chaos/Chaos.raw,size=100,bus=virtio,format=raw,cache=none \
--os-variant ubuntu16.04 \
--location http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/ \
--network bridge=virbr0,model=virtio, \
--virt-type kvm \
--hvm \
1 ответ
Вы объединили несколько вопросов, позвольте мне попытаться ответить на них один за другим. Гость использует сеть по умолчанию и dhcp там с вашей последней командой. Я предполагаю, что вы установили пользователя при установке. Самый простой способ узнать, как подключиться, будет virsh domifaddr
лайк:
$ virsh domifaddr xenial-kvm
Name MAC address Protocol Address
-------------------------------------------------------------------------------
vnet0 52:54:00:fe:2c:1f ipv4 192.168.122.232/24
Примечание: я лично всегда предпочел бы намного более гладкий (без установки, но с использованием облачных образов) uvtool-libvirt
- посмотрите эту информацию, если вы заинтересованы
Тогда для старого доброго raw
против qcow2
обсуждение. Я работал на KVM уже несколько лет - есть ли различия, да. Но ответ не так прост. Вы торгуете довольно qcow2
для этого (редкое распределение, снимки,...).
И если вы действительно обеспокоены производительностью, то raw тоже не то, что вы хотите использовать - по крайней мере освободите раздел или лучше полное устройство и передайте (type='block' device='disk', driver type='raw'отличается от.raw type='file') того устройства для гостя - оно пропускает гораздо больше стека хостов и позволяет обнаруживать характеристики устройства в гостевой системе, что обычно оказывается намного быстрее.
Вы можете развить эту мысль дальше в зависимости от ваших настроек, ИМХО одним из лучших решений для несколько нормальных настроек (всегда есть какая-то альтернатива для предприятия>10 000 $, давайте игнорируем это) для оптимизации скорости на данный момент - это дополнительный контроллер PCIe nvme, который вы PCI-пропуск к гостю - но для этого требуется аппаратное обеспечение.
Так что вопрос ИМХО никогда не бывает "raw file vs qcow2 file"
, это "qcow2 for features, or some pass-through for speed"
- raw files
находятся где-то посередине и редко полезны для любого из вышеупомянутых компромиссных решений.