KVM / qemu: utilizzare i volumi LVM direttamente senza file immagine?

Non sono sicuro di come formulare questa domanda (da qui il titolo scarso), quindi lasciatemi fornire un esempio di ciò che sto cercando di fare.

Sul mio (vecchio) host Xen, sono in grado di presentare i filesystem LVM direttamente a ciascun guest. Questi filesystem sono effettivamente creati e formattati sull'host e passati direttamente. Ad esempio, per uno dei miei host che usano partizioni tmp e swap separate, definisco la memoria in questo modo:

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

Quindi, guest1-swap è formattato come una partizione di swap, guest1-disk e guest1-tmp sono formattati con ext4, e dal punto di vista del guest li vede semplicemente come tre partizioni formattate in / dev / sda.

(Questo può sembrare un sacco di lavoro, ma ci sono script di provisioning, come i fantastici strumenti xen , che hanno automatizzato praticamente tutto).

Ciò fornisce alcune funzionalità davvero utili, due delle quali sono particolarmente interessato a capire per KVM:

• Montare i filesystem guest dal sistema operativo host . Posso eseguire un montaggio in sola lettura di qualsiasi file system guest in qualsiasi momento, anche mentre l'host è in esecuzione. Questo ha il vantaggio secondario di consentire a my di creare snapshot LVM di qualsiasi volume esistente mentre il guest è in esecuzione. In questo modo, sono in grado di eseguire il backup centralizzato di tutti i miei ospiti, mentre sono in esecuzione, dall'host.

• Ridimensionamento del volume online . Poiché i volumi contengono filesystem Linux standard, posso usare una combinazione di lvextend e resize2fs per far crescere i miei filesystem guest, mentre sono online.

Attualmente sto configurando un host KVM che sostituirà l'host Xen. Simile all'installazione di Xen, sto sfruttando LVM per fornire l'accesso diretto al filesystem, ma KVM / qemu si comporta diversamente in quanto crea sempre un file di immagine per gli ospiti, anche sul volume LVM. Dal punto di vista del guest, vede questo come un disco non partizionato, e spetta al guest applicare un'etichetta di partizione, quindi creare le partizioni e i filesystem.

Dal punto di vista dell'ospite va bene, ma dal punto di vista del server / della gestione sembra essere molto meno flessibile della configurazione di Xen che ho descritto. Sono ancora nuovo in KVM, quindi potrei mancare (speriamo) qualcosa.

Ho riscontrato questo problema durante il tentativo di reimplementare la mia precedente soluzione di backup sull'host KVM e il comando mount si è bloccato quando ho provato a montare uno dei filesystem del guest. Quindi, affrontare questa è la mia attuale preoccupazione, ma mi ha anche preoccupato della cosa del ridimensionamento, perché sono sicuro che anche a un certo punto sorgerà il problema.

Quindi, ecco le mie domande:

1. C'è un modo per fare in modo che kvm / qemu utilizzi i filesystem di volume LVM direttamente come ho descritto per la mia configurazione di Xen? Uso libvirt per la gestione se questo fa la differenza.

2. In caso contrario, cosa posso fare per ottenere funzionalità di montaggio / backup simili in KVM? Ho visto discussioni sull'uso di libguestfs w / FUSE per farlo, ma è davvero l'opzione migliore? Preferirei rimanere con un mount di filesystem nativo se possibile.

3. Inoltre, in caso contrario, è possibile eseguire il ridimensionamento di un filesystem online in KVM? Ho trovato diverse discussioni / howtos su questo, ma le risposte sembrano essere dappertutto senza soluzioni chiare, e sicuramente non semplici.

Ci scusiamo per il lungo post, volevo solo assicurarmi che fosse chiaro. Per favore fatemi sapere se posso fornire altre informazioni che potrebbero essere utili. In attesa di discussione. :-)

1. qemu-kvm può usare LV come dischi virtuali anziché file. questo è in realtà un caso d'uso piuttosto comune.
2. libguestfs (e cerca solo un set di virt-*strumenti) può fornire accesso ai filesystem guest in modo più pulito rispetto a qualsiasi cosa rimontassi direttamente sull'host, sebbene entrambi siano possibili.
3. Il ridimensionamento di FS online non è una caratteristica di kvm, ma qualcosa di cui il SO guest dovrebbe essere capace. resize2fsfunzionerà in una VM così come su hardware fisico, l'unico problema è il guest che rileva nuovamente le modifiche alle dimensioni. Provare virt-resizecome lo strumento standard, ma lvresizee qemu-imgpuò anche essere facilmente utilizzato (anche se in modalità non in linea, che richiede un riavvio ospite di solito).

Credo che lvresizecon resize2fseffettivamente funzionare senza un riavvio ospite, ma non ho ancora provato

Uso qemu-kvm + libvirt con esattamente la configurazione di cui mi stai chiedendo, per i motivi che hai elencato, ma anche perché ottengo prestazioni molto migliori senza il livello del filesystem dell'host KVM nell'ambito. Se aggiungi VG come 'pool di archiviazione' in virt-manager, puoi creare tali VM usando la sua procedura guidata intuitiva. (Ma scrivo a mano l'XML in questi giorni usando una VM esistente come modello).

Ecco l'output disinfettato di 'virsh dumpxml' per uno dei miei ospiti:

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

Un altro pensiero (non pertinente alla tua domanda, ma potrebbe essere d'aiuto): se puoi, assicurati di utilizzare i driver di rete, blocchi, casuali, clock "paravirtualizzati" - sono significativamente più veloci di quelli completamente virtualizzati. Questa è la roba "model = virtio" sopra. Devi caricare i moduli driver nel kernel dell'host come virtio_net.

Ecco l'output di '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>

Non conosco un modo per replicare esattamente il comportamento Xen che descrivi. Tuttavia, è possibile utilizzare kpartxper esporre le partizioni all'interno di un LV che contiene un'immagine dell'intero disco come dispositivi a blocchi sull'host, che è quindi possibile montare, ecc.

Vedi la mia risposta alla mia domanda su questo problema su KVM che avvia il kernel off-image e la partizione esistente . In breve, ottenere virt-install per creare una configurazione per questo è piuttosto semplice, data una leggera modifica di guest / etc / fstab.