Właśnie zbudowałem nowy błyszczący host maszyny wirtualnej oparty na KVM / libvirt, zawierający 4 dyski twarde SATA II i działający CentOS 5.5 x86_64.
Zdecydowałem się utworzyć dyski maszyn wirtualnych jako woluminy logiczne w grupie woluminów LVM zarządzanej jako pula pamięci libvirt, zamiast zwykłej praktyki tworzenia dysków jako obrazów qcow.
Nie mogę zdecydować, czy powinienem utworzyć woluminy logiczne maszyny wirtualnej w grupie woluminów hosta maszyny wirtualnej, czy w dedykowanej grupie woluminów.
Którą metodę powinienem wybrać i dlaczego?
Metoda 1: Użyj grupy woluminów hosta VM
Realizacja:
- mały RAID1
md0zawierający/bootsystem plików - duża RAID10
md1zajmująca pozostałą przestrzeń, która zawiera grupę woluminów LVMvghost.vghostzawiera główny system plików hosta VM i partycję wymiany - utwórz dyski maszyny wirtualnej jako woluminy logiczne
vghostzgodnie z wymaganiami
Plusy:
- jeśli w głównym systemie plików hosta VM zabraknie miejsca, mogę przydzielić więcej miejsca
vghoststosunkowo łatwo - System jest już gotowy do pracy (ale nie jest niczym nowym, aby zacząć od nowa)
Cons:
Pomijając fakt, że ta metoda wydaje się działać, nie mogę pozbyć się wrażenia, że jest to zły pomysł. Czuję to:
- może to w jakiś sposób stanowić zagrożenie bezpieczeństwa
- w pewnym momencie w przyszłości mogę znaleźć pewne ograniczenia związane z konfiguracją i żałuję, że nie korzystałem z dedykowanej grupy
- system (CentOS, libvirt itp.) może nie być tak zaprojektowany, aby mógł być używany w ten sposób, i dlatego w pewnym momencie mogę przypadkowo uszkodzić / utracić pliki hosta VM i / lub system plików
Metoda 2: Użyj dedykowanej grupy woluminów
Realizacja:
- tak samo
md0imd1jak w sposobie 1, z wyjątkiem makemd1prostu wystarczająco duży, aby zawierać dla hosta VM (np. 5 do 10 GB) - duża RAID10
md2zajmująca pozostałą przestrzeń.md2zawiera grupę woluminów LVMvgvms, których woluminy logiczne mają być używane wyłącznie przez maszyny wirtualne
Plusy:
- Mogę majstrować
vgvmsbez obawy o uszkodzenie systemu operacyjnego hosta - wydaje się to bardziej eleganckim i bezpiecznym rozwiązaniem
Cons:
- jeśli w systemie plików hosta VM zabraknie miejsca, musiałbym przenieść części jego systemu plików (np. / usr lub / var) na
vgvms, co nie wydaje się zbyt przyjemne. - Muszę ponownie zainstalować system operacyjny hosta (który, jak wspomniano wcześniej, nie mam nic przeciwko temu)
AKTUALIZACJA # 1:
Jednym z powodów, dla których martwię się brakiem miejsca na dysku hosta VM w Metodzie 2, jest to, że nie wiem, czy host VM jest wystarczająco silny, aby uruchomić wszystkie usługi na maszynach wirtualnych, tj. Być może będę musiał przeprowadzić migrację niektórych / wszystkich usług z maszyn wirtualnych do systemu operacyjnego hosta.
Specyfikacja sprzętu hosta VM:
- Procesor Phenom II 955 X4 Black Edition (3,2 GHz, 4-rdzeniowy procesor)
- 2x4 GB pamięci RAM Kingston PC3-10600 DDR3
- Płyta główna Gigabyte GA-880GM-USB3
- 4x dyski twarde WD Caviar RE3 500 GB SATA II (7200 obr./min)
- Antec BP500U Basiq 500W zasilacz ATX
- Obudowa CoolerMaster CM 690
AKTUALIZACJA # 2:
Jednym z powodów, dla których uważam, że system może nie być zaprojektowany do używania hosta VG jako puli pamięci libvirt w Metodzie 1, jest pewne zachowanie, które zauważyłem w virt-manager:
- po dodaniu skarżył się, że nie może aktywować VG (oczywiście, ponieważ system operacyjny hosta już ją aktywował)
- po usunięciu odmówił tego, ponieważ nie mógł dezaktywować VG (oczywiście, ponieważ system operacyjny hosta nadal używa root i swap LV)