Wyszukiwanie w witrynie

Seria RHCSA: Podstawy wirtualizacji i administrowania gościem za pomocą KVM – część 15


Jeśli sprawdzisz w słowniku słowo „wirtualizacja”, przekonasz się, że oznacza ono „stworzyć wirtualną (a nie rzeczywistą) wersję czegoś”. W informatyce termin wirtualizacja odnosi się do możliwości jednoczesnego uruchamiania wielu systemów operacyjnych i izolowania ich od siebie, na tym samym systemie fizycznym (sprzętowym), znanym w schemacie wirtualizacji jako host.

Dzięki monitorowi maszyny wirtualnej (znanemu również jako hypervisor) maszynom wirtualnym (zwanym gośćmi) udostępniane są zasoby wirtualne (tj. procesor, pamięć RAM, pamięć masowa, sieć interfejsy, żeby wymienić tylko kilka) z podstawowego sprzętu.

Mając to na uwadze, łatwo zauważyć, że jedną z głównych zalet wirtualizacji są oszczędności (w zakresie sprzętu i infrastruktury sieciowej oraz nakładów związanych z konserwacją) oraz znaczne zmniejszenie przestrzeni fizycznej wymaganej do umieszczenia całego niezbędnego sprzętu.

Ponieważ ten krótki poradnik nie może omówić wszystkich metod wirtualizacji, zachęcam do zapoznania się z dokumentacją wymienioną w podsumowaniu w celu uzyskania dalszych szczegółów na ten temat.

Należy pamiętać, że niniejszy artykuł ma być punktem wyjścia do poznania podstaw wirtualizacji w RHEL 7 przy użyciu KVM (maszyny wirtualnej opartej na jądrze) z narzędziami wiersza poleceń, a nie -głębokie omówienie tematu.

Weryfikacja wymagań sprzętowych i instalowanie pakietów

Aby skonfigurować wirtualizację, Twój procesor musi ją obsługiwać. Możesz sprawdzić, czy Twój system spełnia wymagania za pomocą następującego polecenia:


grep -E 'svm|vmx' /proc/cpuinfo

Na poniższym zrzucie ekranu widać, że obecny system (z mikroprocesorem AMD) obsługuje wirtualizację, na co wskazuje svm. Gdybyśmy mieli procesor oparty na technologii Intel, zamiast tego w wynikach powyższego polecenia zobaczylibyśmy vmx.

Ponadto w oprogramowaniu sprzętowym hosta (BIOS lub UEFI) muszą być włączone możliwości wirtualizacji.

Teraz zainstaluj niezbędne pakiety:

  1. qemu-kvm to wirtualizator typu open source, który zapewnia emulację sprzętową dla hiperwizora KVM, natomiast qemu-img zapewnia narzędzie wiersza poleceń do manipulowania obrazami dysków.
  2. libvirt zawiera narzędzia umożliwiające interakcję z możliwościami wirtualizacji systemu operacyjnego.
  3. libvirt-python zawiera moduł, który pozwala aplikacjom napisanym w Pythonie korzystać z interfejsu dostarczonego przez libvirt.
  4. libguestfs-tools: różne narzędzia wiersza poleceń administratora systemu dla maszyn wirtualnych.
  5. virt-install: inne narzędzia wiersza poleceń do administrowania maszyną wirtualną.

yum update && yum install qemu-kvm qemu-img libvirt libvirt-python libguestfs-tools virt-install

Po zakończeniu instalacji uruchom i włącz usługę libvirtd:


systemctl start libvirtd.service
systemctl enable libvirtd.service

Domyślnie każda maszyna wirtualna będzie mogła komunikować się tylko z resztą na tym samym serwerze fizycznym i z samym hostem. Aby umożliwić gościom dostęp do innych komputerów w naszej sieci LAN, a także do Internetu, musimy skonfigurować interfejs mostkowy w naszym hoście (powiedzmy na przykład br0) poprzez:

1. dodając następujący wiersz do naszej głównej konfiguracji karty sieciowej (najprawdopodobniej /etc/sysconfig/network-scripts/ifcfg-enp0s3):


BRIDGE=br0

2. utworzenie pliku konfiguracyjnego dla br0 (/etc/sysconfig/network-scripts/ifcfg-br0) z tą zawartością (pamiętaj, że może być konieczna zmiana adresu IP, adresu bramy i informacji DNS):


DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
IPADDR=192.168.0.18
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
NM_CONTROLLED=no
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=br0
ONBOOT=yes
DNS1=8.8.8.8
DNS2=8.8.4.4

3. na koniec, włączenie przekazywania pakietów poprzez wykonanie w /etc/sysctl.conf:


net.ipv4.ip_forward = 1

i ładowanie zmian w bieżącej konfiguracji jądra:


sysctl -p

Pamiętaj, że może być konieczne poinformowanie zapory sieciowej, że ten rodzaj ruchu powinien być dozwolony. Pamiętaj, że możesz zapoznać się z artykułem na ten temat z tej samej serii (Część 11: Kontrola ruchu sieciowego za pomocą FirewallD i Iptables), jeśli potrzebujesz pomocy.