KVM / qemu - używać woluminów LVM bezpośrednio bez pliku obrazu?

Nie jestem do końca pewien, jak sformułować to pytanie (stąd kiepski tytuł), dlatego podaję przykład tego, co próbuję zrobić.

Na moim (starym) hoście Xen jestem w stanie przedstawić systemy plików LVM bezpośrednio każdemu gościowi. Te systemy plików są w rzeczywistości tworzone i formatowane na hoście i przekazywane bezpośrednio przez. Np. Dla jednego z moich hostów używających osobnych partycji tmp i swap definiuję pamięć masową w następujący sposób:

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

Tak więc guest1-swap jest sformatowany jako partycja wymiany, guest1-disk i guest1-tmp są sformatowane przy pomocy ext4, a z perspektywy gościa po prostu widzi je jako trzy sformatowane partycje w / dev / sda.

(Może to zabrzmieć dużo pracy, ale istnieją skrypty obsługi, takie jak niesamowite narzędzia xen , które zautomatyzowały prawie wszystko).

Zapewnia to kilka naprawdę przydatnych funkcji, z których dwa jestem szczególnie zainteresowany opracowaniem KVM:

• Podłącz systemy plików gościa z systemu operacyjnego hosta . Mogę wykonać montaż tylko do odczytu dowolnego systemu plików gościa w dowolnym momencie, nawet gdy gość jest uruchomiony. Ma to tę zaletę, że pozwala mi tworzyć migawki LVM dowolnego istniejącego woluminu podczas działania gościa. W ten sposób mogę centralnie wykonać kopię zapasową wszystkich moich gości podczas pracy z hosta.

• Zmiana rozmiaru woluminu online . Ponieważ woluminy zawierają standardowe systemy plików Linuksa, mogę użyć kombinacji lvextend i resize2fs, aby rozwinąć systemy plików gości ponownie, gdy są one online.

Obecnie konfiguruję host KVM, który zastąpi host Xen. Podobnie do konfiguracji Xen wykorzystuję LVM, aby zapewnić bezpośredni dostęp do systemu plików, ale KVM / qemu zachowuje się inaczej, ponieważ zawsze tworzy plik obrazu dla gości, nawet na wolumenie LVM. Z punktu widzenia gościa traktuje to jako dysk niepodzielony na partycje i to od gościa można zastosować etykietę partycji, a następnie utworzyć partycje i systemy plików.

Z perspektywy gościa to w porządku, ale z perspektywy serwera / zarządzania wydaje się być znacznie mniej elastyczne niż konfiguracja Xen, którą opisałem. Nadal jestem nowy w KVM, więc mogę (mam nadzieję) coś przegapić.

Natknąłem się na ten problem, gdy próbowałem ponownie wdrożyć moje poprzednie rozwiązanie do tworzenia kopii zapasowych na hoście KVM, a polecenie mount zostało zablokowane, gdy próbowałem zamontować jeden z systemów plików gościa. Zajmowanie się tym jest moim aktualnym problemem, ale wzbudziło mnie również zaniepokojenie zmianą rozmiaru, ponieważ jestem pewien, że problem pojawi się w pewnym momencie.

Oto moje pytania:

1. Czy jest jakiś sposób, aby kvm / qemu korzystał bezpośrednio z systemów plików woluminu LVM, tak jak to opisano w mojej konfiguracji Xen? Używam libvirt do zarządzania, jeśli to robi różnicę.

2. Jeśli nie, co mogę zrobić, aby uzyskać podobną funkcjonalność montażu / tworzenia kopii zapasowych w KVM? Widziałem dyskusje na temat korzystania z libguestfs w / FUSE, aby to zrobić, ale czy to naprawdę najlepsza opcja? Wolałbym trzymać się natywnego montowania systemu plików, jeśli to w ogóle możliwe.

3. Jeśli nie, to czy można zmienić rozmiar systemu plików online w KVM? Znalazłem kilka dyskusji / poradników na ten temat, ale odpowiedzi wydają się być wszędzie, bez jasnych i zdecydowanie nieskomplikowanych rozwiązań.

Przepraszam za długi post, chciałem się tylko upewnić, że to jasne. Daj mi znać, czy mogę podać inne informacje, które byłyby pomocne. Czekamy na dyskusję. :-)

1. qemu-kvm może używać LV jako wirtualnych dysków zamiast plików. w rzeczywistości jest to dość powszechny przypadek użycia.
2. libguestfs (i po prostu poszukaj zestawu virt-*narzędzi) może zapewnić dostęp do systemów plików gości w czystszy sposób niż cokolwiek, co ponownie podłączasz bezpośrednio do hosta, chociaż oba są możliwe.
3. Zmiana rozmiaru FS online nie jest cechą kvm, ale jest czymś, co powinien mieć system operacyjny gościa. resize2fsbędzie działać na maszynie wirtualnej, podobnie jak na fizycznym sprzęcie, jedynym problemem jest ponowne wykrywanie zmian przez gościa. Spróbuj virt-resizejako standardowe narzędzie, ale lvresizei qemu-imgmogą być łatwo wykorzystane (choć w trybie offline, co wymaga ponownego uruchomienia gość zazwyczaj).

Myślę, lvresizeze resize2fsfaktycznie działają bez restartu gości, ale nie próbowałem tego jeszcze

Korzystam z qemu-kvm + libvirt z dokładnie taką konfiguracją, o jaką pytasz, z podanych powodów, ale dodatkowo, ponieważ uzyskuję znacznie lepszą wydajność bez warstwy systemu plików hosta KVM w zakresie. Jeśli dodasz VG jako „pulę pamięci” w virt-manager, możesz tworzyć takie maszyny wirtualne za pomocą przyjaznego dla użytkownika kreatora. (Ale teraz piszę XML ręcznie, używając istniejącej maszyny wirtualnej jako szablonu).

Oto zdezynfekowane wyjście „virsh dumpxml” dla jednego z moich gości:

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

Kolejna myśl (niezwiązana z pytaniem, ale może pomóc): jeśli możesz, upewnij się, że używasz sterowników „parawirtualizowanych”, blokowych, losowych, zegarowych itp. - są one znacznie szybsze niż w pełni zwirtualizowane. To jest powyższe „model = virtio”. Musisz załadować moduły sterowników do jądra hosta, takie jak virtio_net.

Oto wynik „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>

Nie znam sposobu na dokładne odtworzenie opisywanego zachowania Xen. Można jednak użyć kpartxdo ujawnienia partycji w LV, która zawiera obraz całego dysku jako urządzenia blokowe na hoście, które można następnie zamontować itp.

Zobacz moją odpowiedź na moje pytanie na ten temat w KVM uruchamiającym jądro poza obrazem i istniejącą partycję . Krótko mówiąc, uzyskanie virt-install do utworzenia konfiguracji jest dość proste, biorąc pod uwagę niewielką modyfikację guest / etc / fstab.