KVM / qemu: ¿utiliza volúmenes LVM directamente sin archivo de imagen?

No estoy muy seguro de cómo formular esta pregunta (de ahí el título pobre), así que permítanme dar un ejemplo de lo que estoy tratando de hacer.

En mi (antiguo) host Xen, puedo presentar sistemas de archivos LVM directamente a cada invitado. Estos sistemas de archivos se crean y formatean en el host, y se pasan directamente a través de ellos. Por ejemplo, para uno de mis hosts que usa particiones tmp e swap separadas, defino el almacenamiento de esta manera:

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

Entonces, guest1-swap está formateado como una partición de intercambio, guest1-disk y guest1-tmp están formateados con ext4, y desde la perspectiva del invitado simplemente los ve como tres particiones formateadas en / dev / sda.

(Esto puede parecer mucho trabajo, pero hay scripts de aprovisionamiento, como las increíbles herramientas xen , que automatizan casi todo).

Esto proporciona algunas capacidades realmente útiles, dos de las cuales estoy especialmente interesado en descubrir para KVM:

• Monte los sistemas de archivos invitados desde el sistema operativo host . Puedo hacer un montaje de solo lectura de cualquier sistema de archivos invitado en cualquier momento, incluso mientras el invitado se está ejecutando. Esto tiene el beneficio adicional de permitirme crear instantáneas LVM de cualquier volumen existente mientras el invitado se está ejecutando. De esta manera, puedo hacer una copia de seguridad centralizada de todos mis invitados, mientras se ejecuta, desde el host.

• Volumen en línea de cambio de tamaño . Debido a que los volúmenes contienen sistemas de archivos Linux estándar, puedo usar una combinación de lvextend y resize2fs para hacer crecer mis sistemas de archivos invitados, nuevamente mientras están en línea.

Actualmente estoy configurando un host KVM que reemplazará al host Xen. Similar a la configuración de Xen, estoy aprovechando LVM para proporcionar acceso directo al sistema de archivos, pero KVM / qemu se comporta de manera diferente, ya que siempre crea un archivo de imagen para los invitados, incluso en el volumen LVM. Desde la perspectiva del invitado, ve esto como un disco sin particiones, y depende del invitado aplicar una etiqueta de partición y luego crear las particiones y los sistemas de archivos.

Desde la perspectiva del huésped, está bien, pero desde la perspectiva del servidor / administración parece ser mucho menos flexible que la configuración de Xen que describí. Todavía soy nuevo en KVM, por lo que es posible que (con suerte) me falte algo.

Me encontré con este problema al intentar volver a implementar mi solución de copia de seguridad anterior en el host KVM y el comando de montaje se bloqueó cuando intenté montar uno de los sistemas de archivos del invitado. Entonces, abordar esa es mi preocupación actual, pero también me hizo preocuparme por el cambio de tamaño, porque estoy seguro de que ese problema también surgirá en algún momento.

Asi que aqui están mis preguntas:

1. ¿Hay alguna forma de hacer que kvm / qemu use los sistemas de archivos de volumen LVM directamente como lo describí para mi configuración de Xen? Uso libvirt para la administración si eso hace la diferencia.

2. Si no, ¿qué puedo hacer para obtener una funcionalidad de montaje / copia de seguridad similar en KVM? He visto discusiones sobre el uso de libguestfs con FUSE para hacer esto, pero ¿es realmente la mejor opción? Prefiero seguir con un montaje de sistema de archivos nativo si es posible.

3. Además, si no, ¿es posible cambiar el tamaño de un sistema de archivos en línea con KVM? Encontré varias discusiones / procedimientos sobre esto, pero las respuestas parecen estar por todas partes sin soluciones claras y definitivamente claras.

Perdón por la larga publicación, solo quería asegurarme de que estaba clara. Avíseme si puedo proporcionar otra información que pueda ser útil. Esperamos con interés la discusión. :-)

1. qemu-kvm puede usar LV como discos virtuales en lugar de archivos. Este es un caso de uso bastante común en realidad.
2. libguestfs (y solo busque un conjunto de virt-*herramientas) puede proporcionar acceso a los sistemas de archivos invitados de una manera más limpia que cualquier cosa que vuelva a montar directamente en el host, aunque ambos son posibles.
3. El cambio de tamaño de FS en línea no es una característica de kvm, sino algo que el SO huésped debería ser capaz de hacer. resize2fsfuncionará tanto en una máquina virtual como en el hardware físico, el único problema es que el invitado vuelve a detectar los cambios de tamaño. Trate virt-resizecomo la herramienta estándar, pero lvresizey qemu-imgtambién puede ser fácilmente utilizado (aunque en modo fuera de línea, lo que requiere un reinicio de invitados por lo general).

Creo que lvresizecon resize2fsrealmente funcionará sin un reinicio de invitado, pero aún no lo he probado

Utilizo qemu-kvm + libvirt con exactamente la configuración que está preguntando, por las razones que enumeró, pero además porque obtengo un rendimiento mucho mejor sin la capa del sistema de archivos del host KVM en su alcance. Si agrega el VG como un 'grupo de almacenamiento' en virt-manager, puede crear tales máquinas virtuales utilizando su asistente fácil de usar. (Pero solo escribo el XML a mano en estos días usando una VM existente como plantilla).

Aquí está la salida desinfectada de 'virsh dumpxml' para uno de mis invitados:

<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>

Otro pensamiento (no relevante para su pregunta pero podría ayudar): si puede, asegúrese de estar utilizando los controladores de red, bloque, aleatorio, reloj, etc. paravirtualizados: son significativamente más rápidos que los completamente virtualizados. Este es el material "model = virtio" mencionado anteriormente. Debe cargar módulos de controlador en el núcleo del host, como virtio_net.

Aquí está la salida de '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>

No conozco una forma de replicar exactamente el comportamiento Xen que usted describe. Sin embargo, puede usar kpartxpara exponer las particiones dentro de un LV que contiene una imagen de disco completo como dispositivos de bloque en el host, que luego puede montar, etc.

Vea mi respuesta a mi propia pregunta sobre este tema en KVM arrancando el kernel fuera de imagen y la partición existente . En resumen, obtener virt-install para crear una configuración para esto es bastante sencillo, dada una ligera modificación de guest / etc / fstab.