Virtualiseringsgrunderna och en introduktion till KVM. Vad är KVM-virtualisering KVM vad är


Hypervisorer (virtualiseringsteknologier) har funnits i mer än 30 år, och under denna tid har de lyckats bli en av de viktigaste "kuggarna" i molnets ekosystem. Många virtualiseringsföretag väljer två populära hypervisorer, VMware och KVM. Vi föreslår att ta reda på vilken som är bättre. Men först lite teori.

Vad är en hypervisor?

En hypervisor är ett program som separerar operativsystemet från hårdvaran. Hypervisorer virtualiserar serverresurser (processor, minne, disk, nätverksgränssnitt, etc.), så att de kan användas som sina egna och skapar flera separata virtuella maskiner baserade på en server. Varje skapad virtuell maskin är isolerad från sina grannar för att inte påverka andras arbete. För att hypervisorn ska fungera krävs virtualiseringsstöd: för Intel-processorer på en Intel VT-processor och för AMD-processorer på AMD-V.

Hypervisorer är indelade i två typer: den första arbetar direkt med servern, och användarens operativsystem körs ovanpå hypervisorn. Dessa hypervisorer kan tillhandahålla serverhanteringsfunktioner till vissa användare, och de flesta företag använder dessa hypervisorer.

Den andra typen av hypervisor, även känd som Hosted Hypervisor, körs med operativsystemet installerat på servern. Och operativsystem för nya användare byggs ovanpå hypervisorn.

Desktop-hypervisorer som Oracle VirtualBox eller VMware Workstation är typ 2-hypervisorer, medan VMware och KVM är typ 1. VMware och KVM installeras direkt på servern och kräver inget operativsystem för att installeras.

VMware vSphere

Innan du köper VMware vSphere kan du prova testversionen (60 dagar), varefter du måste köpa en licens eller stå ut med begränsningarna för gratisversionen.

Gratisversionen, kallad VMware Free vSphere Hypervisor, har inga CPU- eller minnesgränser för värden, men det finns ett antal andra:

  • Produktens API är skrivskyddad;
  • en virtuell maskin kan inte ha fler än 8 kärnor;
  • det kan inte användas tillsammans med Veeam för att skapa säkerhetskopior;
  • anslutning till vCenter Server stöds inte;
  • Teknikerna för hög tillgänglighet, VM Host Live Migration och VM Storage Live Migration stöds inte heller.

Produkten från VMware skiljer sig från sina motsvarigheter till stöd för ett stort antal operativsystem - Windows, Linux, Solaris, FreeBSD, Netware, MacOS och andra.

Att installera en VMware-distribution på en server är väldigt enkelt: starta bara från CD, flash-enhet eller PXE. Dessutom stöds skript för att automatisera processen att installera programvara, konfigurera nätverket och ansluta till vCenter-servern.

Det är också viktigt att det finns en speciell VMware vCenter Converter som låter dig använda MS Virtual Server, Virtual PC, Hyper-V-bilder i ESXi, såväl som fysiska servrar och bilder av diskpartitioner skapade av sådana program som Acronis True Image, Norton Ghost och andra.

VMware vSphere har inbyggd Microsoft Active Directory-integration, vilket innebär att du kan autentisera användare i ett privat eller hybridmoln med hjälp av Microsoft Domain Services. Flexibel resursallokering möjliggör hot add CPU, RAM och hårddisk (inklusive ändra storlek på nuvarande hårddisk utan att starta om).

VMware Fault Tolerate är en VMware-teknik designad för att skydda virtuella maskiner med kontinuerliga tillgänglighetskluster. Om värden (ESXi-servern) med den primära arbetskopian av den virtuella maskinen misslyckas, kommer den skyddade virtuella maskinen omedelbart att byta till den "sekundära" eller "skugga" kopian som körs på en annan ESXi-server. För maskiner som skyddas av VMware Fault Tolerance finns det en konstant (realtids-) kopia av hela minnets tillstånd och processorinstruktioner från huvudkopian till skuggkopian. Om den primära ESXi-värden misslyckas kommer användarna inte ens att märka failover-processen till den andra värden. Det är här som feltolerans skiljer sig från hög tillgänglighet. I High Availability, om den fysiska servern misslyckas, kommer de virtuella maskinerna att startas om på andra noder, och medan operativsystemen startas om kommer användare inte att kunna komma åt de virtuella servrarna.

Utöver VMware Fault Tolerate ger VMware vCloud Suite Enterprise-licensen hög tillgänglighet, resiliens och katastrofåterställning med vSphere HA, vMotion, Storage vMotion och vCenter Site Recovery Manager.

För att minska planerade avbrott i serviceservrar eller lagringssystem (DSS), flyttar vMotion- och Storage vMotion-funktionerna virtuella maskiner och deras diskar online utan att avbryta applikationer och användare. VSphere Replication stöder flera replikeringsalternativ för vCenter Site Recovery Manager (SRM) för att skydda mot större katastrofer. SRM tillhandahåller centraliserad katastrofåterställningsplanering, automatisk över- och återställningsfel från en säkerhetskopieringsplats eller vCloud, och icke-störande katastrofåterställningstestning.

Egenskaperna med denna hypervisor inkluderar selektivitet för hårdvaran - innan du installerar måste du noggrant kontrollera den befintliga hårdvaran för kompatibilitet med den önskade versionen av ESXi. Det finns en speciell för detta på VMware-webbplatsen.

Licensiering av VMware-produkter har sina egna detaljer. Ytterligare förvirring läggs till genom periodiska ändringar (från version till version av vSphere) i VMwares licenspolicy. Det finns flera punkter att tänka på innan du köper VMware vSpere-licenser:

  • hypervisorn är licensierad på en fysisk basis (CPU). Varje server-CPU kräver en separat vSphere-licens (kärnor är inte fysiska processorer och räknas inte till licensieringen);
  • den tillgängliga funktionaliteten för en ESXi-server bestäms av vSphere-licensen som är installerad på den. En detaljerad guide om licenser finns på;
  • för varje köpt vShpere-licens måste du köpa ett servicesupportpaket (minst ett år);
  • VMware sätter inga gränser för mängden minne (RAM) installerat på servern eller för antalet virtuella maskiner som körs.

En annan VMware-produkt, Vcenter Server, kan användas för att hantera flera värdar med ESXi-hypervisorer, lagringssystem och nätverksutrustning. De vSphere-klientplugin-program som tillhandahålls av VMware-partners ger IT-administratörer möjlighet att hantera tredjepartselement i datacentret direkt från denna konsol. Därför kan vCenter-användare säkerhetskopiera, skydda data, hantera servrar, nätverk och säkerhet direkt från vCenter-gränssnittet. I samma konsol kan du konfigurera triggers som meddelar dig om problem, och få data om driften av hela infrastrukturen i form av grafer eller tabeller.

KVM

KVM är en lättanvänd, lätt, resurssnål och ganska funktionell hypervisor. Det låter dig distribuera en virtualiseringsplattform och organisera virtualisering under operativsystemet Linux på kortast möjliga tid. Under drift får KMV åtkomst till operativsystemets kärna genom en speciell modul (KVM-Intel eller KVM-AMD). Från början stödde KVM endast x86-processorer, men moderna versioner av KVM stöder en mängd olika processorer och gästoperativsystem, inklusive Linux, BSD, Solaris, Windows, etc. Förresten, alla Wiki-resurser (MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity) använder just denna hypervisor.

Eftersom gästoperativsystem interagerar med en hypervisor som är integrerad i Linux-kärnan, har gästoperativsystem möjligheten att komma åt hårdvara direkt utan att behöva ändra gästoperativsystemet. På grund av detta är det nästan ingen nedgång i gästoperativsystemet.

KVM tillåter virtuella maskiner att använda omodifierad QEMU, VMware och andra bilder som innehåller operativsystem. Varje virtuell maskin har sin egen virtuella hårdvara: nätverkskort, disk, grafikkort och annan hårdvara.

Tack vare stöd för omodifierade VMware-bilder kan en fysisk server enkelt virtualiseras med samma VMware vServer Converter-verktyg och sedan överföra den resulterande filen till hypervisorn.

Att installera KVM på ett Linux-operativsystem består av att installera KVM-paketet och Libvirt-virtualiseringsbiblioteket, samt att noggrant ställa in virtualiseringsmiljön. Beroende på vilket operativsystem som används på värden måste du konfigurera en brygga eller anslutning till en VNC-konsol genom vilken virtuella maskiner kommer att kommunicera med värden.

Det är svårare att administrera KVM, eftersom det inte finns någon transparent åtkomst till filer, processer, konsoler och nätverksgränssnitt, så du måste konfigurera det själv. Att bygga om VM-parametrar i KVM (CPU, RAM, HDD) är inte särskilt bekvämt och kräver ytterligare steg, inklusive omstart av operativsystemet.

Projektet i sig erbjuder inte praktiska grafiska verktyg för att hantera virtuella maskiner, bara Virsh-verktyget, som implementerar alla nödvändiga funktioner. För bekväm hantering av virtuella maskiner kan du dessutom installera Virt-Manager-paketet.

KVM har inte inbyggda verktyg som Fault Tolerate for VMware, så det enda sättet att skapa ett HA-kluster är att använda nätverksreplikering med DRDB. DRBD-klustret stöder bara två noder, och noderna synkroniseras utan kryptering. Det vill säga, för en säkrare anslutning måste du använda en VPN-anslutning.

För att bygga ett kluster med hög tillgänglighet behöver du dessutom Heartbeat-programmet, som gör att noderna i klustret kan utbyta servicemeddelanden om deras status, och Pacemaker, klusterresurshanteraren.

KVM-hypervisorn distribueras som en produkt med öppen källkod, och för företagsanvändare finns en kommersiell Red Hat Virtualization (RHEL)-lösning baserad på KVM och oVirts virtuella.

Den otvivelaktiga fördelen med denna hypervisor är att den kan köras på vilken server som helst. Hypervisorn är ganska opretentiös vad gäller resurser, vilket gör den enkel att använda för testuppgifter.

Observera att KVM inte har någon supporttjänst. Om något inte fungerar kan du räkna med forumen och gemenskapshjälp. Eller gå till RHEL.

Så vad ska du välja?

Båda hypervisorerna är mogna, pålitliga, högpresterande virtualiseringssystem, vart och ett med sina egna egenskaper att ta hänsyn till när man väljer.

KVM är generellt mer skalbar än VMware, främst för att vSphere har vissa begränsningar på de servrar som den kan hantera. Dessutom har VMware lagt till ett stort antal lagringsnätverk (SAN) för att stödja flera leverantörer. Den här funktionen innebär att VMware har fler lagringsalternativ än KVM, men det gör det också svårare att stödja VMware-lagring när den expanderar.

KVM är vanligtvis den mest populära hypervisorn för företag som vill minska implementeringskostnaderna och är mindre intresserade av funktioner i företagsklass.

Forskning har visat att KVM:s TCO vanligtvis är 39 procent lägre än VMware, även om faktisk TCO är beroende av specifika faktorer som driftsparametrar och arbetsbelastning på platsen.

Tät integration med värdoperativsystemet är en av de vanligaste anledningarna till att utvecklare väljer KVM. Speciellt de som använder Linux. Inkluderandet av KVM i många Linux-distributioner gör det också till ett bekvämt val för utvecklare.

Molnleverantörer som erbjuder IaaS-tjänster till sina kunder väljer vanligtvis en infrastruktur som bygger på VMware-produkter. Lösningar baserade på VMware Sphere innehåller alla viktiga företagsfunktioner för att säkerställa hög och kontinuerlig tillgänglighet, ger stöd för fler gästoperativsystem och har möjlighet att gränssnitta kundens infrastruktur med molntjänster.

På Cloud4Y ser vi VmWare som den ledande virtualiseringslösningen. Men vi är också intresserade av andra lösningar, inklusive Xen och KVM. Och här är vad vi märkte: det finns inte mycket information som gör att vi kan jämföra dessa hypervisorer: den senaste bra forskning som vi hittade på nätverket går tillbaka till 2012 och kan naturligtvis inte längre anses vara relevant. Idag kommer vi inte heller att presentera den senaste, men enligt vår mening, ganska användbar forskning som ägnas åt prestanda hos KVM- och Xen-hypervisorerna.

KVM hypervisor

Ja, virtualiseringsguruer kommer att förlåta oss, men först kommer vi att påminna läsarna om vad en hypervisor är och vad den är till för. För att utföra uppgifter som skiljer sig åt i sin innebörd (mjukvaruutveckling, hosting, etc.), är det enklaste sättet att använda virtuella maskiner: de låter dig ha flera olika operativsystem med en lämplig mjukvarumiljö. För att underlätta arbetet med virtuella maskiner används hypervisorer - mjukvaruverktyg som gör att du snabbt kan distribuera, stoppa och starta en virtuell dator. KVM är en av de mest använda hypervisorerna.


KVM är programvara som låter dig organisera virtualisering baserad på datorer som kör Linux och liknande operativsystem. Nyligen har KVM ansetts vara en del av Linux-kärnan och utvecklas parallellt med den. Denna hypervisor kan endast användas på system där virtualisering stöds av hårdvara - med Intel- och AMD-processorer.


Under drift får KVM tillgång till kärnan direkt via en processorspecifik modul (kvm-intel eller kvm-amd). Dessutom innehåller komplexet huvudkärnan - kvm.ko och UI-element, inklusive den utbredda QEMU. KVM låter dig arbeta direkt med VM-filer och diskbilder. Varje virtuell maskin är försedd med sitt eget isolerade utrymme.

Xen hypervisor

Till en början lanserades ett projekt av Cambridge-studenter som så småningom blev en kommersiell version av Xen. Den första utgåvan går tillbaka till 2003, och 2007 köptes källkoden av Citrix. Xen är en plattformsoberoende hypervisor med stor funktionalitet och enorma möjligheter, vilket gör det möjligt att använda den i företagssfären. Xen stöder paravirtualisering, ett speciellt operativsystems kärnläge där kärnan är konfigurerad att köras samtidigt med en hypervisor.

Endast den nödvändiga uppsättningen funktioner har lagts till i Xen-koden: hantering av virtuellt minne och processorklockfrekvens, arbete med DMA, realtidstimer och avbrott. Resten av funktionaliteten flyttas till domäner, det vill säga till virtuella maskiner som körs vid den tiden. Detta gör Xen till den lättaste hypervisorn.

Forskningsväsen

Testning baserad på två SuperMicro-servrar, var och en med en Intel Xeon E3-1220 fyrkärnig processor @ 3,10 Hz, 24 GB Kingston DDR3 RAM och fyra Western Digital RE-3 160 GB (RAID 10) drivrutiner. BIOS-versionerna är identiska.
För hosting och virtuella maskiner tog vi Fedora 20 (med SELinux). Här är mjukvaruversionerna vi har tagit:

  • Kärna: 3.14.8
  • För KVM: qemu-kvm 1.6.2
  • För Xen: xen 4.3.2
Alla rotfilsystem är XFS med standardkonfiguration. De virtuella maskinerna skapas med virt-Manager med standardinställningarna för KVM och Xen. De virtuella diskarna använde råbilder och tilldelades 8 GB RAM med 4 vCPU:er (virtuella processorer). OS som kördes på Xen använde PVHVM.

Förklaringar

En del av er kanske börjar bli illamående över att ägaren av Fedora 20, Red Hat, lägger ner en betydande mängd ansträngning för att stödja KVM. För att vara tydlig, har Red Hat inte gjort några betydande framsteg inom Xen på flera år.


Dessutom är konkurrensen mellan hypervisorer hårt kontrollerad och minimerad. På de flesta virtuella servrar kommer du att ha flera virtuella maskiner som tävlar om CPU-tid, I/O-enheter och nätverksåtkomst. Våra tester tar inte hänsyn till detta. En enskild hypervisor kan prestera dåligt när resursantalet är lågt, och sedan prestera mycket bättre än sina konkurrenter när resursantalet är högre.

Den här studien utfördes på Intel-processorer, så resultaten kan skilja sig åt för AMD och ARM.

resultat

Tester för virtuella maskiner installerade direkt på "hårdvara", det vill säga utan ett operativsystem (nedan kallat "hårdvara"), fungerade som grund för att testa virtuella maskiner. Prestandavariationen mellan de två icke-virtualiserade servrarna var 0,51 % eller mindre.


KVM-prestandan sjönk med cirka 1,5 % jämfört med hårdvaran i nästan alla tester. Endast två tester visade ett annat resultat: ett av dem var 7-Zip-testet, där KVM visade sig 2,79% långsammare än hårdvara. Det konstiga är att KVM var 4,11 % snabbare i PostMark-riktmärket (som simulerade en hårt belastad e-postserver). Prestandan hos Xen skilde sig mer från hårdvarans prestanda än i KVM-situationen. I tre tester skiljde Xen sig med 2,5 % från hårdvarans hastighet, i andra test visade det sig vara ännu långsammare.

I PostMark benchmark var Xen 14,41 % långsammare än hårdvara. Vid omstart skilde sig testresultaten från originalet med 2 %. Det bästa KVM-riktmärket, MAFFT, ligger på andra plats i det sämsta för Xen.

Här är en snabb sammanfattning av testet:

Bästa värde Ren metall KVM Xen
Tidsinställd MAFFT-justering lägre 7.78 7.795 8.42
Smallpt lägre 160 162 167.5
POV-Ray lägre 230.02 232.44 235.89
PostMark högre 3667 3824 3205
OpenSSL högre 397.68 393.95 388.25
John the Ripper (MD5) högre 49548 48899.5 46653.5
John the Ripper (DES) högre 7374833.5 7271833.5 6911167
John the Ripper (Blowfish) högre 3026 2991.5 2856
KLOMP högre 3.3 3.285 3.125
C-Ray lägre 35.35 35.66 36.13
7-Zip högre 12467.5 12129.5 11879

Om du vill se hela resultatet, följ länken.

Istället för en slutsats

I våra tester var KVM nästan alltid 2 % långsammare än hårdvara. Xen var 2,5 % långsammare i tre av tio tester, och ännu sämre i resten: med 5–7 %. Även om KVM presterade bra i PostMark-riktmärket, bör det noteras att vi bara körde ett I/O-test, och för att få en mer tillförlitlig bild är det värt att göra några fler.


För att välja rätt hypervisor måste du bedöma vilken typ av arbetsbelastning du har. Om din arbetsbelastning involverar mindre CPU och mer I/O, kan fler I/O-tester göras. Om du huvudsakligen arbetar med ljud och video, prova x264 eller mp3 benchmarks.

Som mister_fog med rätta påpekade köpte Citrix 2007 inte Xen-källkoden, utan XenSource-företaget, som grundades av Xen-utvecklarna och var engagerat i den kommersiella utvecklingen av detta open source-projekt. ...


Nyligen släpptes en intressant rapport från företaget Principled Technologies, som bland annat är specialiserat på alla typer av testning av hård- och mjukvarumiljöer. Dokumentet "" förklarar att ESXi-hypervisorn kan köra fler virtuella maskiner på samma hårdvara än RHEV KVM-hypervisorn.

Det är tydligt att studien är partisk (åtminstone om man tittar på titeln), men eftersom det inte finns så många sådana dokument så bestämde vi oss för att uppmärksamma den.

För testning använde vi en Lenovo x3650 M5 rackserver, på vilken Microsoft SQL Server 2016 kördes i virtuella maskiner med OLTP-belastning. OPM (order per minut) användes som den huvudsakliga prestationsindikatorn, som visar en kvantitativ bedömning av utförda transaktioner.

Om du inte använder Memory Overcommit-teknikerna är resultatet av att köra en värd i antalet OPM på 15 virtuella maskiner ungefär detsamma på båda hypervisorerna:

Men när det finns en ökning av antalet virtuella maskiner, så presterar vSphere mycket bättre:

Korsen markerar maskinerna som helt enkelt inte startade på RHV, produktkonsolen gav följande fel:

Trots inkluderingen av minnesoptimeringstekniker i Red Hat Virtualization Manager (RHV-M), såsom minnesballong och kärndelat minne, vägrade den sextonde virtuella maskinen fortfarande att starta på KVM:

Tja, på vSphere fortsatte de att öka antalet virtuella datorer tills de stötte på brist på resurser:

Det visade sig att med overcommit-tekniker på vSphere visade det sig köra 24 virtuella maskiner och på RHV - bara 15 stycken. Som ett resultat drog vi slutsatsen att 1,6 gånger fler virtuella maskiner kan köras på VMware vSphere:

För att inte säga att detta är ett objektivt test, men det är uppenbart att ESXi i det här fallet presterar bättre än KVM när det gäller eventuella optimeringar av minne och andra VM-resurser.


Taggar: VMware, Red Hat, Performance, RHV, vSphere, ESXi, KVM
Taggar: KVM, oVirt, Open Source, Update

Kom ihåg att RHEV är baserat på den Kernel-baserade Virtual Machine (KVM) hypervisorn och stöder OpenStacks öppna molnarkitektur. Låt oss se vad som är nytt i den uppdaterade RHEV-versionen 3.4.

Infrastruktur

  • SNMP-konfigurationstjänst för att stödja tredje parts övervakningssystem.
  • Spara inställningarna för molninstallationen av RHEV för möjligheten att återställa den i händelse av ett fel eller för replikering i andra moln.
  • RHEV-autentiseringstjänster har skrivits om och förbättrats.
  • Möjligheten att lägga till en processor till VM (Hot Plug CPU). Detta kräver stöd från operativsystemet.
  • Icke-rootanvändare har nu tillgång till loggar.
  • Nytt installationsprogram baserat på TUI (textuellt användargränssnitt).
  • IPv6-stöd.
  • Möjlighet att välja en anslutning till VM-konsolen i Native Client eller noVNC-läge.
  • Möjlighet att ändra vissa inställningar för den virtuella maskinen som körs.
  • Fullt stöd för RHEL 7 som gästoperativsystem.
  • Möjlighet att aktivera/avaktivera KSM (Kernel Samepage Merging) på klusternivå.
  • Möjlighet att starta om VM från RHEVM eller med ett konsolkommando.

Nätverk

  • Tätare integration med OpenStack-infrastrukturen:
    • Förbättringar av säkerhet och skalbarhet för nätverk som distribueras med Neutron.
    • Stöder Open vSwitch-teknik (skalbar virtuell switch) och SDN-funktioner.
  • Nätverksetiketter - etiketter som kan användas när man refererar till enheter.
  • Korrekt numreringsordning för virtuell nätverkskort (vNIC).
  • Stöd för iproute2.
  • En enda punkt för att konfigurera nätverksinställningarna för flera värdar på ett specificerat nätverk.

Lagringsmöjligheter

  • Blandade lagringsdomäner - möjligheten att samtidigt använda diskenheter från iSCSI, FCP, NFS, Posix och Gluster-lagring för att organisera lagring av virtuella maskiner.
  • Multiple Storage Domains - möjligheten att distribuera diskar från en virtuell maskin över flera lagringar i datacentret.
  • Möjlighet att ange diskar som ska delta i att skapa ögonblicksbilder, såväl som de som inte gör det.
  • Mekanismen för att återställa en virtuell dator från en säkerhetskopia har förbättrats - nu är det möjligt att ange en ögonblicksbild av tillståndet som du vill återställa till.
  • Asynkron hantering av Gluster-lagringsuppgifter.
  • Read-Only Disk for Engine - Denna funktion gör att Red Hat Enterprise Virtualization Manager-hanteringsverktyget kan använda skrivskyddade diskar.
  • Flervägsåtkomst för iSCSI-lagring.

Virtualiseringsverktyg

  • Guest OS-agenter (ovirt-guest-agent) för OpenSUSE och Ubuntu.
  • SPICE Proxy - möjligheten att använda proxyservrar för att ge användare åtkomst till sina virtuella datorer (om de till exempel befinner sig utanför infrastrukturnätverket).
  • SSO (Single Sign-On) Method Control - möjligheten att växla mellan olika pass-through-autentiseringsmekanismer. Än så länge finns det bara två alternativ: gästagent SSO och ingen SSO.
  • Stöd för flera versioner av samma virtuella maskinmall.

Förbättringar av schemaläggare och servicenivå

  • Förbättringar av den virtuella maskinens schemaläggare.
  • Affinitets-/Anti-affinitetsgrupper (regler för förekomsten av virtuella maskiner på värdar - placera maskiner tillsammans eller separat).
  • Power-Off Capacity är en strömpolicy som låter dig stänga av en värd och förbereda dess virtuella maskiner för migrering till en annan plats.
  • Även Virtual Machine Distribution - möjligheten att distribuera virtuella maskiner till värdar baserat på antalet virtuella datorer.
  • Reservation av virtuell maskin med hög tillgänglighet - mekanismen låter dig garantera återställning av virtuella maskiner i händelse av ett fel på en eller flera värdservrar. Det fungerar på basis av beräkning av den tillgängliga kapaciteten hos klustervärdarnas datorresurser.

Förbättringar av gränssnittet

  • Bugfixar relaterade till det faktum att gränssnittet inte alltid reagerade på händelser som inträffade i infrastrukturen.
  • Stöd för låga skärmupplösningar (när vissa delar av kontrollkonsolen inte var synliga vid låga upplösningar).

Du kan ladda ner Red Hat Enterprise Virtualization 3.4 från den här länken. Dokumentation finns tillgänglig.


Taggar: Red Hat, RHEV, Update, Linux, KVM

Den nya versionen av RHEL OS har många nya intressanta funktioner, bland vilka många relaterar till virtualiseringsteknologier. Några av de stora nya funktionerna i RHEL 7:

  • Inbyggt stöd för paketerade Docker-applikationer.
  • Kernel patching utility Technology Preview - patchar kärnan utan att starta om operativsystemet.
  • Direkt och indirekt integration med Microsoft Active Directory, beskrivs mer i detalj.
  • XFS är nu standardfilsystemet för start-, rot- och användardatapartitioner.
    • För XFS har den maximala filsystemstorleken ökats från 100 TB till 500 TB.
    • För ext4 har denna storlek utökats från 16 TB till 50 TB.
  • Förbättrad OS-installationsprocess (ny guide).
  • Möjlighet att hantera Linux-servrar med hjälp av Open Linux Management Infrastructure (OpenLMI).
  • Förbättringar av NFS- och GFS2-filsystem.
  • Nya funktioner för KVM-virtualiseringsteknik.
  • Möjlighet att köra RHEL 7 som gäst-OS.
  • Förbättringar av NetworkManager och ett nytt kommandoradsverktyg för att utföra NM-CLI-nätverksuppgifter.
  • Stöder Ethernet-nätverksanslutningar med hastigheter upp till 40 Gbps.
  • Stöder trådlös WiGig-teknik (IEEE 802.11ad) (vid hastigheter upp till 7 Gbps).
  • Ny Team Driver-mekanism som praktiskt taget kombinerar nätverksenheter och portar till ett enda gränssnitt på L2-nivå.
  • Ny dynamisk tjänst FirewallD, som är en flexibel brandvägg som har företräde framför iptables och stöder flera nätverksförtroendezoner.
  • GNOME 3 i klassiskt skrivbordsläge.

För mer information om de nya funktionerna i RHEL 7, se Red Hat.

När det gäller virtualisering introducerar Red Hat Enterprise Linux 7 följande stora innovationer:

  • Teknologisk förhandsvisning av virtio-blk-data-plane-funktionen, som gör att QEMU I/O-kommandon kan utföras i en separat optimerad tråd.
  • En teknisk förhandsvisning av PCI Bridge-teknik har dykt upp, vilket gör att fler än 32 PCI-enheter kan stödjas i QEMU.
  • QEMU Sandboxing - förbättrad isolering mellan RHEL 7-värdens gästoperativsystem.
  • Stöd för "hot" att lägga till virtuella processorer till maskiner (vCPU Hot Add).
  • Multiple Queue NIC - varje vCPU har sina egna sändnings- och mottagningsköer, vilket eliminerar behovet av andra vCPU:er (endast för Linux gäst-OS).
  • Hot Migration Page Delta Compression-teknik gör att KVM-hypervisorn kan migrera snabbare.
  • KVM introducerar stöd för paravirtualiserade funktioner i Microsoft OS, till exempel Memory Management Unit (MMU) och Virtual Interrupt Controller. Detta gör att Windows-gäster kan köra snabbare (dessa funktioner är inaktiverade som standard).
  • Stöder EOI Acceleration-teknik baserad på Intel och AMD Advanced Programmable Interrupt Controller (APIC)-gränssnitt.
  • Teknologisk förhandsvisning av USB 3.0-stöd i KVM gästoperativsystem.
  • Stöder Windows 8, Windows 8.1, Windows Server 2012 och Windows Server 2012 R2 gästoperativsystem på en KVM-hypervisor.
  • I/O Throttling-funktioner för gästoperativsystem på QEMU.
  • Stöd för ballongteknik och genomskinliga enorma sidor.
  • Den nya virtio-rng-enheten är tillgänglig som en slumptalsgenerator för gästoperativsystem.
  • Stöd för hetmigrering av gästoperativsystem från en Red Hat Enterprise Linux 6.5-värd till en Red Hat Enterprise Linux 7-värd.
  • Stöder kartläggning av NVIDIA GRID och Quadro-enheter som en andra enhet utöver emulerad VGA.
  • Para-Virtualized Ticketlocks-teknologi, som förbättrar prestandan när det finns fler virtuella vCPU:er än fysiska på värden.
  • Förbättrad felhantering för PCIe-enheter.
  • Ny Virtual Function I/O (VFIO) drivrutin förbättrar säkerheten.
  • Stöder Intel VT-d Large Pages Technology när du använder VFIO-drivrutinen.
  • Förbättringar av att ge exakt tid åt virtuella maskiner på KVM.
  • Stöd för bilder i formatet QCOW2 version 3.
  • Förbättrad Live Migration-statistik - total tid, förväntad stilleståndstid och bandbredd.
  • Dedikerad ström för Live Migration, som tillåter heta migrationer att inte påverka gästens OS-prestanda.
  • Emulering av AMD Opteron G5-processorer.
  • Stöd för nya Intel-processorinstruktioner för KVM gästoperativsystem.
  • Stöder skrivskyddade virtuella diskformat VPC och VHDX.
  • Nya funktioner i libguestfs-verktyget för att arbeta med virtuella diskar på maskiner.
  • Nya Windows Hardware Quality Labs (WHQL) drivrutiner för Windows gästoperativsystem.
  • Integration med VMware vSphere: Öppna VM-verktyg, 3D-grafikdrivrutiner för OpenGL och X11 och förbättrad kommunikationsmekanism mellan gästoperativsystemet och ESXi-hypervisorn.

Release Notes för den nya OS-versionen finns på den här länken. Du kan läsa om virtualiseringsfunktionerna i den nya RHEL 7-versionen (och - på ryska). Källorna för Red Hat Enterprise Linux 7 rpm-paketen är nu endast tillgängliga via Git-förvaret.


Taggar: Linux, QEMU, KVM, Update, RHEL, Red Hat

Ravello har hittat ett intressant sätt att utnyttja kapslad virtualisering i sin Cloud Application Hypervisor-produkt, vilket gör att den kan distribuera virtuella datorer universellt över olika virtualiseringsplattformar i de offentliga molnen hos olika tjänsteleverantörer.

Huvudkomponenten i detta system är HVX-teknik - dess egen hypervisor (baserad på Xen), som är en del av Linux OS och kör kapslade virtuella maskiner utan att ändra dem med binära översättningstekniker. Vidare kan dessa maskiner lagras i Amazon EC2, HP Cloud, Rackspace och till och med privata moln som hanteras av VMware vCloud Director (stöd för det senare förväntas snart).

Ravello-produkten är en SaaS-tjänst, och sådana kapslingsdockor kan enkelt laddas upp till vilken som helst av de värdwebbplatser som stöds, oavsett vilken hypervisor den använder. Ett virtuellt nätverk mellan maskiner skapas via en L2-överlagring över den befintliga L3-infrastrukturen hos värddatorn med hjälp av ett GRE-liknande protokoll (endast baserat på UDP):

Själva mekaniken i den föreslagna Cloud Application Hypervisor-tjänsten är följande:

  • Användaren laddar upp virtuella maskiner till molnet (maskiner skapade på ESXi / KVM / Xen-plattformar stöds).
  • Beskriver applikationer för flera maskiner som använder ett speciellt GUI eller API.
  • Publicerar sina virtuella datorer till ett eller flera moln som stöds.
  • Den resulterande konfigurationen sparas som en ögonblicksbild i Ravello-molnet (då kan den återställas eller laddas ur) - denna lagring kan skapas både på basis av Amazon S3 molnlagring, CloudFiles, och på basis av sitt eget block lagringar eller NFS-volymer.
  • Efter det kan varje användare få en multi-maskin konfiguration av sin applikation på begäran.

Den uppenbara frågan som kommer upp först är hur är det med prestanda? Jo, först och främst är Cloud Application Hypervisor inriktad på utvecklings- och testteam där prestanda inte är en kritisk faktor.

Och för det andra visar resultaten av prestandatester av sådana kapslade dockor inte så dåliga resultat:

För dem som är intresserade av HVX-teknik finns det en bra översiktsvideo på ryska:


Taggar: Rovello, Nested Virtualization, Cloud, HVX, VMware, ESXi, KVM, Xen, VMachines, Amazon, Rackspace

Den nya versionen av den öppna virtualiseringsplattformen RHEV 3.0 är baserad på Red Ha Enterprise Linux version 6-distribution och, traditionellt, KVM-hypervisorn.

Nya funktioner i Red Hat Enterprise Virtualization 3.0:

  • Red Hat Enterprise Virtualization Manager-hanteringsverktyget är nu Java-baserat och körs på JBoss-plattformen (tidigare användes .NET och var därför kopplat till Windows, nu kan du använda Linux för hanteringsservern).
  • En självbetjäningsportal för användare att självdistribuera virtuella maskiner, skapa mallar och administrera sina egna miljöer.
  • Nytt RESTful API som ger tillgång till alla lösningskomponenter från tredjepartsapplikationer.
  • En avancerad administrationsmekanism som ger möjlighet att granulärt tilldela behörigheter, delegera behörighet baserat på användarroller och hierarkisk behörighetshantering.
  • Stöder lokala serverdiskar som lagring för virtuella maskiner (men Live Migration stöds inte för dem).
  • En integrerad rapporteringsmotor som analyserar historisk prestandadata och förutsäger utvecklingen av virtuell infrastruktur.
  • Optimerad för WAN-anslutningar, inklusive dynamisk komprimeringsteknik och automatisk justering av skrivbordseffekter och färgdjup. Dessutom har den nya versionen av SPICE utökat stöd för Linux gästdatorer.
  • Uppdaterad KVM-hypervisor baserad på den senaste Red Hat Enterprise Linux 6.1 som släpptes i maj 2011.
  • Stöder upp till 160 logiska processorer och 2 TB minne för värdservrar, 64 vCPU:er och 512 GB minne för virtuella maskiner.
  • Nya möjligheter för administration av stora installationer av RHEV 3.0.
  • Stöd för stora sidor med minne (Transparant Huge Pages, 2MB istället för 4KB) i gästoperativsystem, vilket förbättrar prestandan genom att minska antalet läsningar.
  • Optimering av vhost-net-komponenten. Nu har KVM-nätverksstacken flyttats från användarläge till kärnläge, vilket avsevärt ökar prestandan och minskar nätverkslatens.
  • Använder funktionerna i sVirt-biblioteket, som ger hypervisorsäkerhet.
  • Den paravirtualiserade kontrollern x2paic har dykt upp, vilket minskar omkostnader på innehållet i den virtuella datorn (särskilt effektivt för intensiva arbetsbelastningar).
  • Async-IO-teknik för att optimera I/O och förbättra prestanda.

Du kan ladda ner den slutliga versionen av Red Hat Enterprise Virtualization 3.0 med den här länken.

Och, slutligen, en kort videorecension av Red Hat Enterprise Virtualization Manager 3.0 (RHEV-M):


Taggar: Red Hat, Enterprise, Update, KVM, Linux

Bra jobbat NetApp! Roman, vi väntar på översättning till ryska)


Taggar: Red Hat, KVM, NetApp, Storage, NFS

ConVirt 2.0 Open Source låter dig hantera Xen- och KVM-hypervisorerna som ingår i gratis och kommersiella Linux-distributioner, distribuera virtuella servrar från mallar, övervaka prestanda, automatisera administratörsuppgifter och konfigurera alla aspekter av den virtuella infrastrukturen. ConVirt 2.0 stöder hetmigrering av virtuella maskiner, "tunna" virtuella diskar (växer när de fylls upp med data), kontroll av virtuella maskiners resurser (inklusive körning), omfattande övervakningsfunktioner och metoder för intelligent placering av virtuella maskiner på värdservrar (manuellt) lastbalansering).

ConVirt 2.0 finns fortfarande bara i Open Source-utgåvan, men utvecklarna lovar att snart släppa ConVirt 2.0 Enteprise-utgåvan, som kommer att skilja sig från gratisutgåvan i följande funktioner:

FunktionConVirt 2.0
Öppen källa		ConVirt 2.0 Enterprise

Arkitektur
Stöd för flera plattformar
Arkitektur utan agent
Universell webbåtkomst
Datacenteromfattande konsol

Administrering
Starta, Stopp, Pausa, Fortsätt
Underhållsläge
Ögonblicksbild
Ändra resursallokering på en körande virtuell dator

Övervakning
Realtidsdata
Historisk information
Serverpooler
Förvaringspooler
Varningar och meddelanden

Provisionering
Mallbaserad provisionering
Mallbibliotek
Integrerade Virtual Appliance-kataloger
Tunn försörjning
Schemalagd provisionering

Automatisering
Intelligent virtuell maskinplacering
Live migration
Värd för privat nätverk
SAN, NAS Storage Support

Avancerad automation
Hög tillgänglighet
Säkerhetskopiering och återställning
VLAN-inställning
Lagringsautomation
Dynamisk resursallokering
Strömsparläge

säkerhet
SSH-åtkomst
Fleranvändaradministration
Revision
Finkornig åtkomstkontroll

Integration
Öppna arkivet
Kommandoradsgränssnitt
Programmatisk API

Taggar: Xen, KVM, Convirt, Citrix, Red Hat, Gratis, Öppen källkod,

Convirture, 2007 års XenMan GUI för att hantera XEN hypervisor, nyligen släppt fri Convirture ConVirt 1.0, som bytte namn till XenMan.

Med ConVirt kan du hantera Xen- och KVM-hypervisorer med hjälp av följande funktioner:

  • Hantering av flera värdservrar.
  • Snapshots (snapshots).
  • Livemigrering av virtuella maskiner mellan värdar.
  • VM backup.
  • Den enklaste övervakningen av värdar och virtuella maskiner.
  • Stöd för virtuella moduler (Virtual Appliances).

Du kan ladda ner Convirture ConVirt 1.0 från denna länk:

Convirture ConVirt 1.0
Etiketter: Xen, KVM

I en sysadmins liv kommer det en dag en tid då du måste distribuera en företagsinfrastruktur från början eller göra om en befintlig som har ärvts. I den här artikeln kommer jag att prata om hur man korrekt distribuerar en hypervisor baserad på Linux KVM och libvirt med stöd för LVM (logisk grupp).

Vi kommer att gå igenom alla krångligheterna med hypervisorhantering, inklusive konsol- och GUI-verktyg, resursexpansion och migrering av virtuella maskiner till en annan hypervisor.

Låt oss först ta reda på vad virtualisering är. Den officiella definitionen är: "Virtualisering är tillhandahållandet av en uppsättning datorresurser eller deras logiska association, abstraherat från hårdvaruimplementeringen och samtidigt som den ger logisk isolering från varandra av datorprocesser som körs på en fysisk resurs." Det vill säga, i mänskliga termer, med en kraftfull server kan vi förvandla den till flera mediumservrar, och var och en av dem kommer att utföra sin uppgift som tilldelats den i infrastrukturen, utan att störa andra.

Systemadministratörer som arbetar nära med virtualisering på företaget, mästare och virtuoser i sitt hantverk, uppdelade i två läger. Vissa är anhängare av högteknologisk, men vansinnigt dyr VMware för Windows. Andra är älskare av öppen källkod och gratislösningar baserade på Linux VM. Det kan ta lång tid att räkna upp fördelarna med VMware, men här kommer vi att fokusera på virtualisering baserad på Linux VM.

Virtualiseringstekniker och hårdvarukrav

Det finns nu två populära virtualiseringstekniker: Intel VT och AMD-V. Intel VT (från Intel Virtualization Technology) implementerar virtualisering i riktig adresseringsläge; motsvarande hårdvaru-I/O-virtualisering kallas VT-d. Denna teknik kallas ofta VMX (Virtual Machine eXtension). AMD skapade sina virtualiseringstillägg och kallade dem ursprungligen AMD Secure Virtual Machine (SVM). När tekniken kom ut på marknaden blev den känd som AMD Virtualization (förkortat AMD-V).

Innan hårdvaran tas i bruk, se till att utrustningen stöder någon av dessa två tekniker (du kan se specifikationerna på tillverkarens webbplats). Om stöd för virtualisering är tillgängligt måste det aktiveras i BIOS innan hypervisorn distribueras.

Andra hypervisorkrav inkluderar hårdvaru-RAID (1, 5, 10) stöd, vilket ökar hypervisorns feltolerans i händelse av ett hårddiskfel. Om det inte finns något stöd för hårdvaru-RAID kan du använda programvara som en sista utväg. Men RAID är ett måste!

Lösningen som beskrivs i den här artikeln har tre virtuella maskiner och körs framgångsrikt på minimikraven: Core 2 Quad Q6600 / 8 GB DDR2 PC6400 / 2 × 250 GB SATA HDD (hårdvara RAID 1).

Installera och konfigurera hypervisorn

Jag ska visa dig hur du konfigurerar en hypervisor med Debian Linux 9.6.0 - X64-86 som exempel. Du kan använda vilken Linux-distribution du vill.

När du bestämmer dig för valet av strykjärn och det äntligen kommer, är det dags att installera hypervisorn. När vi installerar operativsystemet gör vi allt som vanligt, förutom partitioneringen av diskarna. Oerfarna administratörer väljer ofta alternativet "Partera automatiskt allt diskutrymme utan att använda LVM". Då kommer all data att skrivas till en volym, vilket inte är bra av flera anledningar. För det första, om hårddisken misslyckas, kommer du att förlora all data. För det andra kommer det att bli mycket krångel att byta filsystem.

I allmänhet, för att undvika onödiga gester och slöseri med tid, rekommenderar jag att du använder diskpartitionering med LVM.

Logisk volymhanterare

Den logiska volymhanteraren (LVM) är ett delsystem tillgängligt på Linux och OS / 2, byggt ovanpå Device Mapper. Dess syfte är att representera olika områden från en hårddisk eller områden från flera hårddiskar som en enda logisk volym. LVM skapar en logisk volymgrupp (VG - Volumes Group) från fysiska volymer (PV - Physical Volumes). Den består i sin tur av logiska volymer (LV - Logical Volume).

Alla Linux-distributioner med kärna 2.6 och högre har nu LVM2-stöd. För att använda LVM2 på ett OS med en 2.4-kärna måste du installera en patch.

Efter att systemet har identifierat hårddiskarna startar hårddiskpartitionshanteraren. Välj objektet Guidad - använd hela disken och ställ in LVM.


Nu väljer vi den skiva som vår volymgrupp ska installeras på.



Systemet kommer att erbjuda alternativ för att markera media. Välj "Skriv alla filer till en sektion" och gå vidare.




Efter att ha sparat ändringarna får vi en logisk grupp och två volymer i den. Den första är rotpartitionen och den andra är växlingsfilen. Här kommer många att ställa frågan: varför inte välja layouten manuellt och skapa LVM själv?

Mitt svar är enkelt: när du skapar en logisk grupp VG skrivs startpartitionen inte till VG, utan skapas som en separat partition med ext2-filsystemet. Om detta inte tas med i beräkningen kommer startvolymen att vara i en logisk grupp. Detta kommer att döma dig till plåga och lidande när du återställer startvolymen. Det är därför startpartitionen skickas till icke-LVM-volymen.



Låt oss gå vidare till att konfigurera den logiska gruppen för hypervisorn. Vi väljer objektet "Konfiguration av hanteraren för logiska volymer".



Systemet kommer att meddela att alla ändringar kommer att skrivas till disken. Vi instämmer.



Låt oss skapa en ny grupp - låt oss till exempel döpa den till vg_sata.



INFO

Servrarna använder SATA, SSD, SAS, SCSI, NVMe media. Det är bra att ange inte värdnamnet när du skapar en logisk grupp, utan vilken typ av media som används i gruppen. Jag råder dig att namnge den logiska gruppen så här: vg_sata, vg_ssd, vg_nvme, och så vidare. Detta kommer att hjälpa dig att förstå vilka medier den logiska gruppen är byggd från.




Vi skapar vår första logiska volym. Detta kommer att vara volymen för rotpartitionen för operativsystemet. Vi väljer objektet "Skapa logisk volym".



Välj en grupp för den nya logiska volymen. Vi har bara en.



Tilldela ett namn till den logiska volymen. Det mest korrekta sättet att tilldela ett namn är att använda ett prefix i form av ett logiskt gruppnamn - till exempel vg_sata_root, vg_ssd_root, och så vidare.



Vi anger volymen för den nya logiska volymen. Jag råder dig att allokera 10 GB för roten, men mindre kan vara, eftersom den logiska volymen alltid kan utökas.



I analogi med exemplet ovan, skapa följande logiska volymer:

  • vg_sata_home - 20 GB för användarkataloger;
  • vg_sata_opt - 10 GB för installation av programvara;
  • vg_sata_var - 10 GB för data som ändras ofta, till exempel systemloggar och andra program;
  • vg_sata_tmp - 5 GB för tillfällig data, om mängden temporär data är stor kan du göra mer. I vårt exempel skapades det här avsnittet inte som onödigt;
  • vg_sata_swap - lika med mängden RAM. Detta är en swap-sektion, och vi skapar den av säkerhetsskäl - ifall hypervisorn får slut på RAM.

När du har skapat alla volymer, avsluta managern.



Nu har vi flera volymer för att skapa partitioner av operativsystemet. Som du kanske gissar har varje partition sin egen logiska volym.



Skapa en partition med samma namn för varje logisk volym.



Vi sparar och registrerar de ändringar som gjorts.



När du har sparat ändringarna av disklayouten kommer de grundläggande systemkomponenterna att installeras, och du kommer sedan att uppmanas att välja och installera ytterligare systemkomponenter. Av alla komponenter behöver vi ssh-server och standardsystemverktyg.



Efter installationen kommer GRUB-starthanteraren att genereras och skrivas till disken. Installera den på den fysiska disk där startpartitionen är sparad, det vill säga /dev/sda.




Nu väntar vi på att starthanteraren ska slutföra skrivningen till disken, och efter meddelandet startar vi om hypervisorn.





Efter att ha startat om systemet, gå till hypervisorn via SSH. Först och främst, under roten, installerar vi de verktyg som behövs för arbetet.

$ sudo apt-get install -y sudo htop screen net-tools dnsutils bind9utils sysstat telnet traceroute tcpdump wget curl gcc rsync

Vi skräddarsyr SSH efter smak. Jag råder dig att omedelbart göra tillstånd med nycklar. Vi startar om och kontrollerar användbarheten.

$ sudo nano / etc / ssh / sshd_config $ sudo systemctl starta om sshd; sudo systemctl status sshd

Innan du installerar virtualiseringsprogramvara måste du kontrollera de fysiska volymerna och tillståndet för den logiska gruppen.

$ sudo pvscan $ sudo lvs

Installera virtualiseringskomponenter och verktyg för att skapa en nätverksbrygga på hypervisorgränssnittet.

$ sudo apt-get update; apt-get upgrade -y $ sudo apt installera qemu-kvm libvirt-bin libvirt-dev libvirt-daemon-system libvirt-klienter virtinst bridge-utils

Efter installationen konfigurerar vi nätverksbryggan på hypervisorn. Kommentera inställningarna för nätverksgränssnittet och ställ in nya:

$ sudo nano / etc / nätverk / gränssnitt

Innehållet blir ungefär så här:

Auto br0 iface br0 inet statisk adress 192.168.1.61 nätmask 255.255.255.192 gateway 192.168.1.1 broadcast 192.168.0.61 dns-nameserver 127.0.0.1 dns_bridge_bridge 0_bridge_bridge_0.

Lägg till vår användare, under vilken vi kommer att arbeta med hypervisorn, till grupperna libvirt och kvm (för RHEL kallas gruppen qemu).

$ sudo gpasswd -a iryzhevtsev kvm $ sudo gpasswd -a iryzhevtsev libvirt

Nu måste vi initiera vår logiska grupp för att arbeta med hypervisorn, starta den och lägga till den för start vid systemstart.

$ sudo virsh pool-lista $ sudo virsh pool-define-as vg_sata logical --target / dev / vg_sata $ sudo virsh pool-start vg_sata; sudo virsh pool-autostart vg_sata $ sudo virsh pool-lista

INFO

För att LVM-gruppen ska fungera korrekt med QEMU-KVM måste du först aktivera den logiska gruppen via virsh-konsolen.

Nu laddar vi ner distributionssatsen för installation på gästsystem och lägger den i önskad mapp.

$ sudo wget https://mirror.yandex.ru/debian-cd/9.5.0/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso $ sudo mv debian-9.5.0-amd64-netinst .iso / var / lib / libvirt / images /; ls -al / var / lib / libvirt / images /

För att ansluta till virtuella maskiner via VNC, redigera filen /etc/libvirt/libvirtd.conf:

$ sudo grep "listen_addr =" /etc/libvirt/libvirtd.conf

Låt oss avkommentera och ändra raden listen_addr = "0.0.0.0". Spara filen, starta om hypervisorn och kontrollera om alla tjänster är igång.

Fortsättning är endast tillgänglig för deltagare

Alternativ 1. Gå med i "site"-gemenskapen för att läsa allt material på sajten

Medlemskap i communityn inom den angivna perioden ger dig tillgång till ALLT Hackers material, ökar din personliga kumulativa rabatt och låter dig samla ett professionellt Xakep-resultat!

För mig personligen är det lättast att tänka på KVM (Kernel-baserad virtuell maskin) som en sådan abstraktionsnivå över Intel VT-x och AMD-V hårdvaruvirtualiseringsteknologier. Vi tar en maskin med en processor som stöder en av dessa teknologier, installerar Linux på denna maskin, installerar KVM i Linux, som ett resultat får vi möjlighet att skapa virtuella maskiner. Ungefär så fungerar molnhotelltjänster, till exempel Amazon Web Services. Tillsammans med KVM används ibland också Xen, men en diskussion om denna teknik ligger utanför ramen för detta inlägg. Till skillnad frånier, till exempel, samma Docker, låter KVM dig köra vilket operativsystem som helst som gästsystem, men det har också b. O Högre virtualiseringskostnader.

Notera: Stegen som beskrivs nedan testades av mig på Ubuntu Linux 14.04, men i teorin kommer de att vara till stor del giltiga för andra versioner av Ubuntu och andra Linux-distributioner. Allt ska fungera både på skrivbordet och på servern som nås via SSH.

Installerar KVM

Kontrollera om Intel VT-x eller AMD-V stöds av vår processor:

grep -E "(vmx | svm)" / proc / cpuinfo

Om något värms upp, stöds det, och du kan fortsätta.

Installera KVM:

sudo apt-get uppdatering
sudo apt-get installera qemu-kvm libvirt-bin virtinst bridge-utils

Vad är vanligt att lagra där:

  • / var / lib / libvirt / boot / - ISO-avbildningar för installation av gästsystem;
  • / var / lib / libvirt / images / - bilder av hårddiskar i gästsystem;
  • / var / log / libvirt / - alla loggar ska sökas här;
  • / etc / libvirt / - katalog med konfigurationsfiler;

Nu när KVM är installerat, låt oss skapa vår första virtuella maskin.

Skapande av den första virtuella maskinen

Jag valde FreeBSD som gästsystem. Ladda ner ISO-bilden av systemet:

cd / var / lib / libvirt / boot /
sudo wget http: // ftp.freebsd.org/ sökväg / till / some-freebsd-disk.iso

I de flesta fall hanteras virtuella maskiner med virsh-verktyget:

sudo virsh --hjälp

Innan vi startar den virtuella maskinen måste vi samla in lite ytterligare information.

Vi tittar på listan över tillgängliga nätverk:

sudo virsh nätlista

Visa information om ett specifikt nätverk (med namnet standard):

sudo virsh net-info standard

Låt oss se listan över tillgängliga optimeringar för gäst-OS:

sudo virt-install --os-variant lista

Så nu skapar vi en virtuell maskin med 1 CPU, 1 GB RAM och 32 GB diskutrymme, ansluten till standardnätverket:

sudo virt-installera \
--virt-typ = kvm \
--namn freebsd10 \
--ram 1024 \
--vcpus = 1 \
--os-variant = freebsd8 \
--hvm \
--cdrom = / var / lib / libvirt / boot / FreeBSD-10.2 -RELEASE-amd64-disc1.iso \
--nätverksnätverk = standard, modell = virtio \
--grafik vnc \
--disksökväg = / var / lib / libvirt / images / freebsd10.img, storlek = 32, bus = virtio

Du kan se:

VARNING Det går inte att ansluta till den grafiska konsolen: virt-viewer inte
installerat. Installera paketet "virt-viewer".

Domäninstallationen pågår fortfarande. Du kan återansluta till konsolen
för att slutföra installationsprocessen.

Detta är normalt och det borde det vara.

Sedan tittar vi på egenskaperna för den virtuella maskinen i XML-format:

sudo virsh dumpxml freebsd10

Här är den mest kompletta informationen. Inklusive till exempel MAC-adressen, som vi kommer att behöva ytterligare. Hittills hittar vi information om VNC. I mitt fall:

Med hjälp av din favoritklient (jag använder personligen Rammina) går vi till VNC och använder SSH port forwarding om det behövs. Vi kommer direkt in i FreeBSD-installationsprogrammet. Sedan är allt som vanligt - Nästa, Nästa, Nästa, vi får det installerade systemet.

Grundläggande kommandon

Låt oss nu ta en titt på de grundläggande kommandona för att arbeta med KVM.

Få en lista över alla virtuella maskiner:

sudo virsh lista --all

Få information om en specifik virtuell maskin:

sudo virsh dominfo freebsd10

Starta virtuell maskin:

sudo virsh starta freebsd10

Stoppa virtuell maskin:

sudo virsh avstängning freebsd10

Svårt att spika den virtuella maskinen (trots namnet, detta inte radera):

sudo virsh förstör freebsd10

Starta om den virtuella maskinen:

sudo virsh starta om freebsd10

Klona en virtuell maskin:

sudo virt-klon -o freebsd10 -n freebsd10-klon \
--file / var / lib / libvirt / images / freebsd10-clone.img

Aktivera/inaktivera autorun:

sudo virsh autostart freebsd10
sudo virsh autostart --inaktivera freebsd10

Starta virsh i dialogläge (alla kommandon är i dialogläge - som beskrivs ovan):

sudo virsh

Redigera egenskaper för virtuell maskin i XML, inklusive här kan du ändra gränsen för mängden minne, etc.

sudo virsh redigera freebsd10

Viktig! Tyvärr tas kommentarer från den redigerade XML-filen bort.

När den virtuella maskinen stoppas kan disken även ändras storlek:

sudo qemu-img ändra storlek / var / lib / libvirt / images / freebsd10.img -2G
sudo qemu-img info / var / lib / libvirt / images / freebsd10.img

Viktig! Ditt gästoperativsystem kommer troligen inte att gilla att disken plötsligt blir större eller mindre. I bästa fall kommer den att starta i nödläge med ett förslag om att partitionera om disken. Chansen är stor att du inte vill göra det här. Det kan vara mycket lättare att starta en ny virtuell maskin och migrera all data till den.

Att säkerhetskopiera och återställa är ganska enkelt. Det räcker att spara dumpxml-utgången någonstans, såväl som skivavbildningen, och sedan återställa dem. På Youtube hittade en video med en demonstration av denna process är allt väldigt enkelt.

Nätverksinställningar

En intressant fråga är hur man avgör vilken IP-adress den virtuella maskinen fick efter uppstart? KVM gör detta på ett knepigt sätt. Det slutade med att jag skrev ett manus som detta i Python:

#! / usr / bin / env python3

# virt-ip.py-skript
# (c) 2016 Aleksander Alekseev
# http:// webbplats /

import sys
import ang
importera os
import underprocess
från xml .etree import ElementTree

def eprint (str):
print (str, fil = sys .stderr)

if len (sys .argv)< 2 :
eprint ("ANVÄNDNING:" + sys .argv [0] + " " )
eprint ("Exempel:" + sys .argv [0] + "freebsd10")
sys .exit (1)

if os .geteuid ()! = 0:
eprint ("FEL: du ska vara root")
eprint ("Tips: kör` sudo "+ sys .argv [0] +" ... `");
sys .exit (1)

if subprocess .call ( "vilken arping 2> & 1> / dev / null", skal = Sant)! = 0:
eprint ("FEL: arping hittades inte")
eprint ( "Tips: kör` sudo apt-get install arping` ")
sys .exit (1)

Domän = sys .argv [1]

om inte re .match ("^ * $", domän):
eprint ( "FEL: ogiltiga tecken i domännamnet")
sys .exit (1)

Domout = subprocess .check_output ("virsh dumpxml" + domän + "|| true",
skal = sant)
domout = domout.decode ("utf-8") .strip ()

om domout == "":
# felmeddelande har redan skrivits ut av dumpxml
sys .exit (1)

Doc = ElementTree.fromstring (domout)

# 1.lista alla nätverksgränssnitt
# 2.kör `arping` på varje gränssnitt parallellt
# 3.grep svar
cmd = "(ifconfig | cut -d" "-f 1 | grep -E". "|" + \
"xargs -P0 -I IFACE arping -i IFACE -c 1 () 2> & 1 |" + \
"grep" bytes från ") || true"

för barn i doc.iter ():
if child.tag == "mac":
macaddr = child.attrib ["adress"]
macout = underprocess .check_output (cmd .format (macaddr),
skal = sant)
print (macout.decode ("utf-8"))

Skriptet fungerar med både standardnätverket och det överbryggade nätverket, vars konfiguration kommer att diskuteras vidare. I praktiken är det dock mycket bekvämare att konfigurera KVM så att den alltid tilldelar samma IP-adresser till gästsystem. För att göra detta, redigera nätverksinställningarna:

sudo virsh net-edit standard

... något som det här:

>



>

Efter att ha gjort dessa ändringar


>

... och ersätt det med något i stil med:




>

Vi startar om gästsystemet och kontrollerar att det fått en IP via DHCP från routern. Om du vill att gästen ska ha en statisk IP-adress konfigureras denna som vanligt inom gästen själv.

Virt-manager program

Du kanske också är intresserad av virt-manager-programmet:

sudo apt-get install virt-manager
sudo usermod -a -G libvirtd ANVÄNDARNAMN

Så här ser dess huvudfönster ut:

Som du kan se är virt-manager inte bara ett GUI för virtuella maskiner som körs lokalt. Med dess hjälp kan du hantera virtuella maskiner som körs på andra värdar, samt titta på vackra grafer i realtid. Jag tycker personligen att det är särskilt bekvämt i virt-manager att du inte behöver söka i konfigurationerna på vilken port VNC:n för ett visst gästsystem körs. Du hittar bara den virtuella maskinen i listan, dubbelklickar så får du tillgång till monitorn.

Det är också mycket bekvämt att använda virt-manager för att göra saker som annars skulle kräva mödosam redigering av XML-filer och i vissa fall ytterligare kommandon. Till exempel, byta namn på virtuella maskiner, konfigurera CPU-affinitet och liknande. Förresten, att använda CPU-affinitet minskar avsevärt effekten av bullriga grannar och effekten av virtuella maskiner på värdsystemet. Använd den alltid när det är möjligt.

Om du bestämmer dig för att använda KVM som ersättning för VirtualBox, kom ihåg att de inte kan dela hårdvaruvirtualisering sinsemellan. För att KVM ska fungera på ditt skrivbord måste du inte bara stoppa alla virtuella maskiner i VirtualBox och Vagrant, utan även starta om systemet. Jag tycker personligen att KVM är mycket bekvämare än VirtualBox, åtminstone eftersom det inte kräver att du kör kommandot sudo / sbin / rcvboxdrv installation efter varje kärnuppdatering fungerar den tillräckligt med Unity och låter dig i allmänhet dölja alla fönster.


2021 gtavrl.ru.