I det föregående
1. Kval av val
Så vad kan du välja mellan? I
- Servervirtualiseringssystem "R-virtualisering» (libvirt, KVM, QEMU)
- Mjukvarupaket "Brest virtualiseringsverktyg» (libvirt, KVM, QEMU)
- Plattform för hantering och övervakning av virtualiseringsmiljön "Sharx Stream" (en molnlösning som inte lämpar sig för statliga kontor i 95 % av fallen (sekretess, etc.)
- Mjukvarupaket för virtualisering av servrar, stationära datorer och applikationer "VÄRD" (KVM x86)
- System för säker hantering av virtualiseringsmiljön "Z|virt"(aka oVirt+KVM)
- Managementsystem för virtualiseringsmiljö"ROSA virtualisering"(aka oVirt+KVM)
- Hypervisor QP VMM (för lik Oracle Virtual Box för att vara något annat)
Du kan också ta hänsyn till hypervisorer som ingår i OS-distributionen eller finns i deras arkiv. Till exempel har Astra Linux KVM-stöd. Och eftersom det är inkluderat i OS-arkiven kan det anses vara "legitimt" för installation och användning. "Vad kan användas som en del av importsubstitution och vad som inte kan" diskuterades i föregående
Faktiskt här
- VirtualBox
- Virt-chef (KVM) Örnström
- libvirt över KVM
ROSA Linux har ingen sådan lista, men du kan hitta den på wikin
- ROSA virtualisering över oVirt över KVM
- QEMU över KVM
- oVirt 3.5 över KVM
Calculate har detta
Alt Linux har samma sak
1.2. Det finns ett MEN
Vid närmare granskning drar vi slutsatsen att vi bara kommer att behöva hantera ett fåtal välkända hypervisorer, nämligen:
QEMU är ett gratis och öppen källkodsprogram för att emulera hårdvara från olika plattformar, som kan fungera utan att använda KVM, men att använda hårdvaruvirtualisering snabbar upp prestanda avsevärt för gästsystem, så att använda KVM i QEMU (-enable-kvm) är det föredragna alternativet. (c) Det vill säga QEMU är en typ 2 hypervisor, vilket är oacceptabelt i en produktmiljö. Med KVM kan det användas, men i det här fallet kommer QEMU att användas som KVM-hanteringsverktyget...
Använder originalet VirtualBox i handeln är faktiskt
Totalt: i sin rena form har vi bara KVM.
2. Resten: KVM eller KVM?
Om du fortfarande behöver byta till en "inhemsk" hypervisor är ditt val, ärligt talat, litet. Det kommer att vara KVM i ett eller annat omslag, med vissa modifieringar, men det kommer fortfarande att vara KVM. Om detta är bra eller dåligt är en annan fråga, det finns fortfarande inget alternativ.
Om villkoren inte är så strikta, då, som diskuterats i föregående
Dessa produkter är långt ifrån jämförbara
Om distribution och konfiguration KVM det var inte skrivet på samma sätt
Detsamma gäller för
Jag ser ingen mening med att upprepa mig och beskriva dessa system, jämföra osv. Man kan givetvis dra fram nyckelpunkter från artiklar, men det skulle vara respektlöst mot författarna tycker jag. Den som måste välja kommer att läsa inte bara detta, utan också ett berg av information för att bestämma sig.
Den enda skillnaden jag vill fokusera på är failover-klustring. Om Microsoft har detta inbyggt i operativsystemet och hypervisorfunktionaliteten, måste du i fallet med KVM använda programvara från tredje part, som bör inkluderas i OS-förråden. Samma kombination av Corosync+Pacemaker, till exempel. (Nästan alla inhemska operativsystem har den här kombinationen... kanske alla, men jag kollade inte 100% av dem.) Manualer för att sätta upp klustring finns också i överflöd.
3. Slutsats
Tja, som vanligt brydde sig inte våra Kulibins, de tog vad de hade, lade till lite eget och producerade en "produkt" som enligt dokument är inhemsk, men i verkligheten är OpenSource. Är det vettigt att spendera pengar från budgeten på "separata" virtualiseringssystem (läs: ingår inte i operativsystemet)? Tänk inte. Eftersom du fortfarande kommer att få samma KVM behöver du bara betala för det.
Att välja en ersättare för en hypervisor beror alltså på vilket server-OS du ska köpa till företaget och driva. Eller, som i mitt fall, kommer du att stanna med det du redan har (Hyper-VESXi insert_needed).
Källa: will.com