KVM / qemu - utiliser des volumes LVM directement sans fichier image?

Je ne sais pas trop comment formuler cette question (d'où le mauvais titre), alors laissez-moi vous donner un exemple de ce que j'essaie de faire.

Sur mon (ancien) hôte Xen, je peux présenter des systèmes de fichiers LVM directement à chaque invité. Ces systèmes de fichiers sont en fait créés et formatés sur l'hôte, et transmis directement à travers. Par exemple, pour un de mes hôtes utilisant un tmp séparé et des partitions de swap, je définis le stockage comme ceci:

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

Ainsi, guest1-swap est formaté comme une partition de swap, guest1-disk et guest1-tmp sont formatés avec ext4, et du point de vue de l'invité, il les considère simplement comme trois partitions formatées sous / dev / sda.

(Cela peut sembler beaucoup de travail, mais il existe des scripts d'approvisionnement, tels que les impressionnants outils xen , qui automatisent à peu près tout).

Cela fournit des capacités vraiment utiles, dont deux m'intéressent particulièrement à trouver pour KVM:

• Montez les systèmes de fichiers invités à partir du système d'exploitation hôte . Je peux faire un montage en lecture seule de n'importe quel système de fichiers invité à tout moment, même lorsque l'invité est en cours d'exécution. Cela a l'avantage secondaire de permettre à my de créer des instantanés LVM de tout volume existant pendant que l'invité est en cours d'exécution. De cette façon, je suis en mesure de sauvegarder de manière centralisée tous mes invités, en cours d'exécution, à partir de l'hôte.

• Redimensionnement du volume en ligne . Étant donné que les volumes contiennent des systèmes de fichiers Linux standard, je peux utiliser une combinaison de lvextend et resize2fs pour développer mes systèmes de fichiers invités, à nouveau lorsqu'ils sont en ligne.

Je configure actuellement un hôte KVM qui remplacera l'hôte Xen. Semblable à la configuration Xen, je tire parti de LVM pour fournir un accès direct au système de fichiers, mais KVM / qemu se comporte différemment en ce qu'il crée toujours un fichier image pour les invités, même sur le volume LVM. Du point de vue de l'invité, il voit cela comme un disque non partitionné, et c'est à l'invité d'appliquer une étiquette de partition, puis de créer les partitions et les systèmes de fichiers.

D'un point de vue invité, c'est bien, mais d'un point de vue serveur / gestion, il semble être beaucoup moins flexible que la configuration Xen que j'ai décrite. Je suis encore nouveau sur KVM, donc je peux (espérons-le) manquer quelque chose.

J'ai rencontré ce problème en essayant de réimplémenter mon ancienne solution de sauvegarde sur l'hôte KVM et la commande de montage s'est étouffée lorsque j'ai essayé de monter l'un des systèmes de fichiers de l'invité. Donc, répondre à cela est ma préoccupation actuelle, mais cela m'a également préoccupé par le redimensionnement, car je suis sûr que ce problème se posera à un moment donné également.

Donc, voici mes questions:

1. Existe-t-il un moyen pour que kvm / qemu utilise les systèmes de fichiers de volume LVM directement comme je l'ai décrit pour ma configuration Xen? J'utilise libvirt pour la gestion si cela fait une différence.

2. Sinon, que puis-je faire pour obtenir des fonctionnalités de montage / sauvegarde similaires sous KVM? J'ai vu des discussions sur l'utilisation de libguestfs w / FUSE pour ce faire, mais est-ce vraiment la meilleure option? Je préfère m'en tenir à un montage de système de fichiers natif si possible.

3. Sinon, est-il possible de redimensionner un système de fichiers en ligne sous KVM? J'ai trouvé plusieurs discussions / howtos à ce sujet, mais les réponses semblent être partout sans solutions claires et certainement pas simples.

Désolé pour le long post, je voulais juste m'assurer qu'il était clair. Veuillez me faire savoir si je peux fournir d'autres informations qui pourraient être utiles. Dans l'attente de la discussion. :-)

1. qemu-kvm peut utiliser des LV comme disques virtuels au lieu de fichiers. il s'agit en fait d'un cas d'utilisation assez courant.
2. libguestfs (et recherchez simplement un ensemble d' virt-*outils) peut fournir un accès aux systèmes de fichiers invités d'une manière plus propre que tout ce que vous remontez directement sur l'hôte, bien que les deux soient possibles.
3. Le redimensionnement de FS en ligne n'est pas une fonctionnalité de kvm, mais quelque chose que le système d'exploitation invité devrait être capable. resize2fsfonctionnera dans une machine virtuelle ainsi que sur du matériel physique, le seul problème étant que l'invité redétecte les changements de taille. Essayez virt-resizecomme outil standard, mais lvresizeil qemu-imgpeut également être facilement utilisé (bien qu'en mode hors ligne, nécessitant généralement un redémarrage invité).

Je pense lvresizequ'avec resize2fsfonctionnera sans redémarrage invité, mais je ne l'ai pas encore essayé

J'utilise qemu-kvm + libvirt avec exactement la configuration que vous demandez, pour les raisons que vous avez énumérées, mais en plus parce que j'obtiens de bien meilleures performances sans la couche du système de fichiers de l'hôte KVM dans la portée. Si vous ajoutez le VG en tant que «pool de stockage» dans virt-manager, vous pouvez créer de telles machines virtuelles à l'aide de son assistant convivial. (Mais je viens d'écrire le XML à la main ces jours-ci en utilisant une machine virtuelle existante comme modèle).

Voici la sortie aseptisée de «virsh dumpxml» pour l'un de mes invités:

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

Une autre pensée (sans rapport avec votre question, mais cela pourrait aider): si vous le pouvez, assurez-vous que vous utilisez les pilotes réseau, paravirtualisé, par blocs, aléatoires, d'horloge, etc. - ils sont nettement plus rapides que ceux entièrement virtualisés. C'est le truc "model = virtio" ci-dessus. Vous devez charger des modules de pilote dans le noyau de l'hôte tel que virtio_net.

Voici la sortie 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>

Je ne connais pas de moyen de reproduire exactement le comportement Xen que vous décrivez. Cependant, vous pouvez utiliser kpartxpour exposer les partitions dans un LV qui contient une image de disque entier en tant que périphériques de bloc sur l'hôte, que vous pouvez ensuite monter, etc.

Voir ma réponse à ma propre question sur ce problème lors du démarrage du noyau hors image KVM et de la partition existante . En bref, obtenir virt-install pour créer une configuration pour cela est assez simple, étant donné une légère modification de guest / etc / fstab.