KVM / qemu - LVM-Volumes direkt ohne Image-Datei verwenden?

Ich bin mir nicht ganz sicher, wie ich diese Frage formulieren soll (daher der schlechte Titel). Lassen Sie mich ein Beispiel dafür geben, was ich versuche.

Auf meinem (alten) Xen-Host kann ich jedem Gast LVM-Dateisysteme direkt präsentieren. Diese Dateisysteme werden tatsächlich auf dem Host erstellt und formatiert und direkt weitergeleitet. Beispiel: Für einen meiner Hosts, der eine separate tmp- und Swap-Partition verwendet, definiere ich den Speicher folgendermaßen:

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

Guest1-swap wird also als Swap-Partition formatiert, guest1-disk und guest1-tmp werden mit ext4 formatiert, und aus der Sicht des Gasts werden sie einfach als drei formatierte Partitionen unter / dev / sda angezeigt.

(Das mag nach viel Arbeit klingen, aber es gibt Provisioning-Skripte, wie die fantastischen Xen-Tools , die so ziemlich alles automatisierten).

Dies bietet einige wirklich nützliche Funktionen, von denen ich zwei besonders für KVM herausfinden möchte:

• Hängen Sie die Gast-Dateisysteme vom Host-Betriebssystem ein . Ich kann jederzeit ein schreibgeschütztes Mounten eines Gast-Dateisystems durchführen, auch wenn der Gast ausgeführt wird. Dies hat den zusätzlichen Vorteil, dass ich LVM-Snapshots aller vorhandenen Volumes erstellen kann, während der Gast ausgeführt wird. Auf diese Weise kann ich alle meine Gäste während des Betriebs zentral vom Host sichern.

• Größenänderung des Online-Volumes . Da die Volumes Standard-Linux-Dateisysteme enthalten, kann ich eine Kombination aus lvextend und resize2fs verwenden, um meine Gast-Dateisysteme wieder zu vergrößern, während sie online sind.

Ich richte gerade einen KVM-Host ein, der den Xen-Host ersetzt. Ähnlich wie beim Xen-Setup nutze ich LVM, um direkten Dateisystemzugriff zu ermöglichen, aber KVM / qemu verhält sich anders, da immer eine Image-Datei für die Gäste erstellt wird, auch auf dem LVM-Volume. Aus der Sicht des Gasts wird dies als nicht partitionierte Festplatte angesehen. Es ist Sache des Gasts, eine Partitionsbezeichnung anzuwenden und dann die Partitionen und Dateisysteme zu erstellen.

Aus Sicht der Gäste ist das in Ordnung, aber aus Sicht der Server / Verwaltung scheint es weitaus weniger flexibel zu sein als das von mir beschriebene Xen-Setup. Ich bin noch neu in KVM, daher kann mir (hoffentlich) etwas fehlen.

Dieses Problem trat auf, als ich versuchte, meine frühere Sicherungslösung auf dem KVM-Host erneut zu implementieren, und der Befehl mount wurde blockiert, als ich versuchte, eines der Dateisysteme des Gasts bereitzustellen. Das anzusprechen ist mein aktuelles Anliegen, aber es hat mich auch über die Größenänderung beunruhigt, da ich mir sicher bin, dass dieses Problem auch irgendwann auftauchen wird.

Also, hier sind meine Fragen:

1. Gibt es eine Möglichkeit, dass kvm / qemu LVM-Volume-Dateisysteme direkt verwendet, wie ich es für mein Xen-Setup beschrieben habe? Ich verwende libvirt für die Verwaltung, wenn das einen Unterschied macht.

2. Wenn nicht, was kann ich tun, um ähnliche Bereitstellungs- / Sicherungsfunktionen unter KVM zu erhalten? Ich habe Diskussionen über die Verwendung von libguestfs mit FUSE gesehen, aber ist das wirklich die beste Option? Ich würde es vorziehen, wenn möglich bei einem nativen Dateisystem-Mount zu bleiben.

3. Ist es auch möglich, die Größe eines Online-Dateisystems unter KVM zu ändern? Ich habe mehrere Diskussionen / Anleitungen dazu gefunden, aber die Antworten scheinen überall zu sein, ohne klare und definitiv unkomplizierte Lösungen.

Entschuldigung für den langen Beitrag, wollte nur sicherstellen, dass es klar war. Bitte teilen Sie mir mit, ob ich weitere hilfreiche Informationen zur Verfügung stellen kann. Freue mich auf die Diskussion. :-)

1. qemu-kvm kann LVs anstelle von Dateien als virtuelle Festplatten verwenden. Dies ist eigentlich ein recht häufiger Anwendungsfall.
2. libguestfs (und suchen Sie nur nach einer Reihe von virt-*Tools) kann den Zugriff auf Gastdateisysteme auf eine sauberere Weise ermöglichen als alles, was Sie direkt auf dem Host erneut bereitstellen, obwohl beides möglich ist.
3. Das Ändern der Größe von Online-FS ist keine Funktion von kvm, sollte aber vom Gastbetriebssystem unterstützt werden. resize2fsfunktioniert in einer VM genauso gut wie auf physischer Hardware. Das einzige Problem ist, dass der Gast die Größenänderungen erneut erkennt. Versuchen Sie virt-resizeals Standard - Tool, sondern lvresizeund qemu-imgauch leicht verwendet werden kann (wenn auch im Offline - Modus, einen Gast - Neustart erfordern in der Regel).

Ich denke, lvresizemit resize2fswird tatsächlich ohne einen Neustart des Gastes funktionieren, aber ich habe es noch nicht versucht

Ich verwende qemu-kvm + libvirt mit genau der Konfiguration, nach der Sie fragen, aus den von Ihnen angegebenen Gründen, aber zusätzlich, weil ich ohne die Dateisystemschicht des KVM-Hosts eine viel bessere Leistung erhalte . Wenn Sie die VG in virt-manager als 'Speicherpool' hinzufügen, können Sie solche VMs mithilfe des benutzerfreundlichen Assistenten erstellen. (Aber ich schreibe das XML heutzutage nur von Hand unter Verwendung einer vorhandenen VM als Vorlage).

Hier ist die bereinigte Ausgabe von 'virsh dumpxml' für einen meiner Gäste:

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

Ein anderer Gedanke (nicht relevant für Ihre Frage, aber er könnte helfen): Wenn Sie können, stellen Sie sicher, dass Sie die Treiber "paravirtualisiert" für Netzwerk, Block, Zufall, Uhr usw. verwenden - sie sind bedeutend schneller als die vollständig virtualisierten. Dies ist das "model = virtio" Zeug oben. Sie müssen Treibermodule in den Kernel des Hosts laden, z. B. virtio_net.

Hier ist die Ausgabe von '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>

Ich kenne keine Möglichkeit, das von Ihnen beschriebene Xen-Verhalten exakt zu replizieren. Sie können kpartxjedoch die Partitionen in einer LV, die ein Image auf der gesamten Festplatte enthält, als Blockgeräte auf dem Host bereitstellen, die Sie dann bereitstellen können usw.

Die Antwort auf meine eigene Frage zu diesem Problem finden Sie unter KVM-Booten von einem Image-Kernel und einer vorhandenen Partition . Kurz gesagt, es ist ziemlich einfach, virt-install zu veranlassen, eine Konfiguration dafür zu erstellen, wenn man eine kleine Modifikation von guest / etc / fstab vornimmt.