Назад | Перейти на главную страницу

KVM / qemu - использовать тома LVM напрямую без файла изображения?

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

На моем (старом) хосте Xen я могу представить файловые системы LVM напрямую каждому гостю. Эти файловые системы фактически создаются и форматируются на хосте и передаются напрямую. Например, для одного из моих хостов, использующих отдельные разделы tmp и swap, я определяю хранилище следующим образом:

диск = [
'phy: / dev / vg1 / guest1-swap, sda1, w',
'phy: / dev / vg1 / guest1-disk, sda2, w',
'phy: / dev / vg1 / guest1-tmp, sda3, w',
]

Итак, guest1-swap отформатирован как раздел подкачки, guest1-disk и guest1-tmp отформатированы с помощью ext4, и с точки зрения гостя он просто видит их как три отформатированных раздела в / dev / sda.

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

Это дает некоторые действительно полезные возможности, две из которых мне особенно интересно выяснить для KVM:

В настоящее время я настраиваю хост KVM, который заменит хост Xen. Подобно настройке Xen, я использую LVM для обеспечения прямого доступа к файловой системе, но KVM / qemu ведет себя иначе в том смысле, что всегда создает файл изображения для гостей даже на томе LVM. С точки зрения гостя, он видит это как неразмеченный диск, и гость должен применить метку раздела, а затем создать разделы и файловые системы.

С точки зрения гостя это нормально, но с точки зрения сервера / управления это кажется гораздо менее гибким, чем описанная мною установка Xen. Я все еще новичок в KVM, поэтому я могу (надеюсь) что-то упустить.

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

Итак, вот мои вопросы:

  1. Есть ли способ заставить kvm / qemu использовать файловые системы томов LVM напрямую, как я описал для моей установки Xen? Я использую libvirt для управления, если это имеет значение.

  2. Если нет, что я могу сделать, чтобы получить аналогичные функции монтирования / резервного копирования под KVM? Я видел дискуссии об использовании для этого libguestfs w / FUSE, но действительно ли это лучший вариант? Я бы предпочел придерживаться монтирования собственной файловой системы, если это вообще возможно.

  3. Также, если нет, можно ли изменить размер файловой системы онлайн под KVM? Я нашел несколько обсуждений / советов по этому поводу, но ответы, кажется, повсюду, без четких и определенно простых решений.

Извините за длинный пост, просто хотел убедиться, что он понятен. Пожалуйста, дайте мне знать, могу ли я предоставить любую другую информацию, которая была бы полезна. Жду обсуждения. :-)

  1. qemu-kvm может использовать LV как виртуальные диски вместо файлов. на самом деле это довольно распространенный вариант использования.
  2. libguestfs (и просто поищите набор virt-* tools) может обеспечить доступ к гостевым файловым системам более чистым способом, чем все, что вы перемонтируете на хост напрямую, хотя оба варианта возможны.
  3. Изменение размера файловой системы онлайн не является функцией kvm, но гостевая ОС должна быть способна. resize2fs будет работать на виртуальной машине так же, как и на физическом оборудовании, единственная проблема заключается в том, что гость повторно определяет изменения размера. Пытаться virt-resize как стандартный инструмент, но lvresize и qemu-img также можно легко использовать (хотя и в автономном режиме, обычно требующем гостевой перезагрузки).

думаю lvresize с участием resize2fs действительно будет работать без гостевого перезапуска, но я еще не пробовал

Я использую qemu-kvm + libvirt именно с той конфигурацией, о которой вы спрашиваете, по причинам, которые вы указали, но дополнительно потому, что я получаю много лучшая производительность без уровня файловой системы хоста KVM в области видимости. Если вы добавите VG в качестве «пула хранения» в virt-manager, вы можете создать такие виртуальные машины с помощью его удобного мастера. (Но в наши дни я просто пишу XML вручную, используя существующую виртуальную машину в качестве шаблона).

Вот очищенный вывод virsh dumpxml для одного из моих гостей:

<domain type='kvm'>
  <name>somevm</name>
  <uuid>f173d3b5-704c-909e-b597-c5a823ad48c9</uuid>
  <description>Windows Server 2008 R2</description>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-1.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>Nehalem</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='tm2'/>
    <feature policy='require' name='est'/>
    <feature policy='require' name='monitor'/>
    <feature policy='require' name='smx'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='dtes64'/>
    <feature policy='require' name='rdtscp'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='ds'/>
    <feature policy='require' name='pbe'/>
    <feature policy='require' name='tm'/>
    <feature policy='require' name='pdcm'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='ds_cpl'/>
    <feature policy='require' name='xtpr'/>
    <feature policy='require' name='acpi'/>
  </cpu>
  <clock offset='localtime'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/vg1/somevm'/>
      <target dev='hda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <interface type='bridge'>
      <mac address='00:00:00:00:00:00'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <video>
      <model type='vga' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='none' model='none'/>
</domain>

Еще одна мысль (не относящаяся к вашему вопросу, но это может помочь): если можете, убедитесь, что вы используете паравиртуализированные сетевые, блочные, случайные, тактовые драйверы и т. Д. - они значительно быстрее, чем полностью виртуализированные. Это "model = virtio" выше. Вам необходимо загрузить модули драйверов в ядро ​​хоста, такие как virtio_net.

Вот вывод команды virsh pool-dumpxml vg1:

<pool type='logical'>
  <name>vg1</name>
  <uuid>9e26648e-64bc-9221-835f-140f6def0556</uuid>
  <capacity unit='bytes'>3000613470208</capacity>
  <allocation unit='bytes'>1824287358976</allocation>
  <available unit='bytes'>1176326111232</available>
  <source>
    <device path='/dev/md1'/>
    <name>vg1</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/vg1</path>
    <permissions>
      <mode>0700</mode>
    </permissions>
  </target>
</pool>

Я не знаю, как точно воспроизвести описанное вами поведение Xen. Однако вы можете использовать kpartx чтобы предоставить разделы в LV, который содержит образ всего диска, как блочные устройства на хосте, которые затем можно смонтировать и т. д.

Смотрите мой ответ на мой вопрос по этому поводу на KVM загрузка ядра без образа и существующего раздела. Короче говоря, получить virt-install для создания конфигурации для этого довольно просто, учитывая небольшую модификацию гостя / etc / fstab.