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 , ш ',
]

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

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

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

• Смонтируйте гостевые файловые системы с хост-ОС . Я могу выполнить монтирование только для чтения любой гостевой файловой системы в любое время, даже когда гость работает. Это имеет побочное преимущество, позволяя my создавать снимки LVM любого существующего тома во время работы гостя. Таким образом, я могу централизованно создавать резервные копии всех моих гостей во время работы с хоста.

• Изменение громкости онлайн . Поскольку тома содержат стандартные файловые системы Linux, я могу использовать комбинацию lvextend и resize2fs для расширения моих гостевых файловых систем, когда они находятся в сети.

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

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

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

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

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

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

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

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

1. qemu-kvm может использовать LV как виртуальные диски вместо файлов. это довольно распространенный случай использования.
2. libguestfs (и просто ищите набор virt-*инструментов) может обеспечить доступ к гостевым файловым системам более чистым способом, чем все, что вы перемонтируете непосредственно на хост, хотя оба варианта возможны.
3. Изменение размера FS в сети - это не функция 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>

Еще одна мысль (не относится к вашему вопросу, но она может помочь): если вы можете, убедитесь, что вы используете «паравиртуализированные» сетевые, блочные, случайные, тактовые и т. Д. Драйверы - они значительно быстрее, чем полностью виртуализированные. Это материал "модель = 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.