Virtuālā mašīna

Datorikā virtuālā mašīna ir datorsistēmas emulācija. Virtuālās mašīnas ir balstītas datoru arhitektūrās un nodrošina fiziska datora funkcionalitāti. To izveidei var lietot specializētu aparatūru, programmatūru vai to kombināciju.

Ir dažādi virtuālo mašīnu veidi ar dažādām funkcijām:

Sistēmas virtuālās mašīnas (sauktas arī par pilnīgas virtualizācijas virtuālajām mašīnām ) ir īstas darbstacijas aizstājējas. Tās nodrošina funkcionalitāti, kas nepieciešama operētājsistēmas darbībai. Hipervizors lieto mašīnkodu, lai pārvaldītu un dalītos ar aparatūru, ļaujot darboties vairākām vidēm, kas ir izolētas viena no otras, taču pastāv vienā un tajā pašā fiziskajā mašīnā. Mūsdienu hipervizori izmanto aparatūras virtualizāciju, virtualizācijai specifisku aparatūru, galvenokārt no resursdatora procesoriem.
Procesa virtuālās mašīnas ir paredzētas datorprogrammu darbībai no platformas neatkarīgā vidē.

Dažas virtuālās mašīnas, piemēram, QEMU, ir izstrādātas, lai arī atdarinātu dažādas arhitektūras un ļautu darboties programmatūrai un operētājsistēmām, kas paredzētas citam procesoram vai arhitektūrai. Operētājsistēmas līmeņa virtualizācija ļauj datora resursus sadalīt caur kodolu.

Definīcijas

Sistēmas virtuālās mašīnas

"Virtuālo mašīnu" Popeks un Goldbergs sākotnēji definēja kā "efektīvu, izolētu reāla datora mašīnas dublikātu".^[1] Pašreizējā izmantošana ietver virtuālās mašīnas, kurām nav tiešas atbilstības nevienai reālai aparatūrai^[2]. Fizisko "reālās pasaules" aparatūru, kurā darbojas virtuālās mašīnas, parasti sauc par resursdatoru, un virtuālo mašīnu, kas tiek emulēta šajā mašīnā, parasti sauc par viesi. Resursdators var emulēt vairākus viesus, no kuriem katrs var emulēt dažādas operētājsistēmas un aparatūras platformas.

Sākotnējais virtuālo mašīnu izveides iemesls bija vēlme darbināt vairākas operētājsistēmas vienlaikus, lai varētu koplietot laiku starp vairākām viena uzdevuma operētājsistēmām. Dažos aspektos sistēmas virtuālo mašīnu var uzskatīt par virtuālās atmiņas jēdziena vispārinājumu, kas vēsturiski bija pirms tās. IBM CP / CMS, pirmās sistēmas, kas nodrošina pilnīgu virtualizāciju, ieviesa laika koplietošanu, nodrošinot katram lietotājam viena lietotāja operētājsistēmu - Dialogmonitorsistēmu. Atšķirībā no virtuālās atmiņas, sistēmas virtuālā mašīna ļāva lietotājam ierakstīt privileģētas instrukcijas kodā. Šai pieejai bija dažādas priekšrocības, piemēram, tādu ievades / izvades ierīču pievienošana, ko neļauj standarta sistēma.^[2]

Tā kā tehnoloģija virtualizācijas vajadzībām pārveido virtuālo atmiņu, var tikt lietotas jaunas atmiņas pārsniegšanas sistēmas, lai pārvaldītu atmiņas koplietošanu starp vairākām virtuālām mašīnām vienā datora operētājsistēmā. Iespējams koplietot atmiņas lapas ar identisku saturu starp vairākām virtuālām mašīnām, kas darbojas vienā fiziskajā mašīnā, kā rezultātā tās var tikt kartētas uz vienu un to pašu fizisko lapu, izmantojot tehniku, ko sauc par kodola vienas lapas apvienošanu. Tas ir noderīgi lasāmlapām, piemēram, tādām, kas satur koda segmentus, kas attiecas uz vairākām virtuālām mašīnām, kurās darbojas vienāda vai līdzīga programmatūra, programmatūras bibliotēkām, tīmekļa serveriem, starpprogrammatūras komponentiem utt. Viesa operētājsistēmām nav jābūt saderīgām ar resursdatora aparatūru, tādējādi ļaujot tajā pašā datorā palaist dažādas operētājsistēmas (piemēram, Windows, Linux vai iepriekšējās operētājsistēmas versijas), lai atbalstītu nākotnes programmatūru.^[3]

Virtuālo mašīnu izmantošana atsevišķu viesu operētājsistēmu lietošanas atbalstam ir populāra iegultās sistēmās. Tipisks lietojums ir reāllaika operētājsistēmas palaišana vienlaikus ar vēlamo komplicēto operētājsistēmu, piemēram, Linux vai Windows. Tāpat tās izmanto programmatūrai, kas joprojām ir izstrādes stadijā, tāpēc tā darbojas izmēģināšanas vidē. Virtuālajām mašīnām ir priekšrocības operētājsistēmu izstrādē, un tās var ietvert uzlabotu atkļūdošanas piekļuvi un ātrāku pārstartēšanu.^[4]

Serveru konsolidācijai bieži tiek izmantotas vairākas virtuālās mašīnas, kurām ir sava viesa operētājsistēma.^[5]

Procesa virtuālās mašīnas

Procesa virtuālās mašīnas, ko dažkārt sauc par lietojumprogrammu virtuālo mašīnu vai pārvaldīto izpildlaika vidi, saimniekdatora operētājsistēmā darbojas kā parasta lietojumprogramma un atbalsta vienu procesu. Tās tiek izveidotas, kad šis process tiek uzsākts, un tiek iznīcinātas, kad šis process tiek izbeigts. To mērķis ir nodrošināt no platformas neatkarīgu programmēšanas vidi, kas apkopo informāciju par pamata aparatūru vai operētājsistēmu un ļauj programmu izpildīt tādā pašā veidā jebkurā platformā.

Procesa virtuālās mašīnas nodrošina augsta līmeņa abstrakciju, kādu lieto augsta līmeņa programmēšanas valodas (salīdzinot ar sistēmas virtuālās mašīnas zema līmeņa instrukciju kopu). Procesa virtuālās mašīnas tiek veidotas, izmantojot interpretatoru. Veiktspēju, kas ir salīdzināma ar kompilētām programmēšanas valodām, var sasniegt, izmantojot tiešlaika kompilāciju.

Šis virtuālo mašīnu veids ir kļuvis populārs Java programmēšanas valodā, izmantojot Java virtuālo mašīnu. Citi piemēri ir Parrot virtuālā mašīna un . NET Framework, kas darbojas virtuālajā mašīnā Common Language Runtime. Visi no tiem var kalpot kā abstrakcijas slānis jebkurai datora valodai.

Īpašs procesa virtuālo mašīnu lietojums ir sistēmas, kas abstrahē (potenciāli neviendabīgas) datoru kopas komunikācijas mehānismus. Šādas virtuālās mašīnas sastāv no viena procesa katrā fiziskajā mašīnā datoru kopā. Tās ir paredzētas, lai atvieglotu vienlaicīgu lietojumprogrammu programmēšanas uzdevumu, ļaujot programmētājam koncentrēties uz algoritmiem, nevis uz sakaru mehānismiem, ko nodrošina starpsavienojums un operētājsistēma.

Atšķirībā no citām procesa virtuālajām mašīnām, šīs sistēmas nenodrošina noteiktu programmēšanas valodu, bet ir iegultas esošā valodā. Parasti šāda sistēma nodrošina sasaisti starp vairākām valodām, kā C un Fortran. Piemēri ir Parallel Virtual Machine (PVM) un Message Passing Interface (MPI). Tās nav stingri nosakāmas par virtuālajām mašīnām, jo aplikācijas, kas darbojas to augšpusē, var piekļūt visiem operētājsistēmas pakalpojumiem, neaprobežojoties tikai ar sistēmas modeli.

Pilnīga virtualizācija

Pilnīgā virtualizācijā virtuālā mašīna simulē pietiekami daudz aparatūras, lai nemodificētu viesa operētājsistēmu (tādu, kas paredzēta tai pašai instrukciju kopai) varētu darbināt atsevišķi. Šī pieeja tika aizsākta 1966. gadā ar IBM CP-40 un CP-67, VM operētājsistēmas priekšgājējiem.

Kā piemērus var minēt Parallels Workstation, Parallels Desktop for Mac, VirtualBox, Virtual Iron, Oracle VM, Virtual PC, Virtual Server, Hyper-V, VMware Workstation, VMware Server (pārtraukta, agrāk saukta par GSX Server), VMware ESXi, QEMU, Adeos, Mac-on-Linux, Win4BSD, Win4Lin Pro un Egenera vBlade technology.

Aparatūrveicināta virtualizācija

Aparatūrveicinātā virtualizācijā aparatūra nodrošina arhitektūras atbalstu, kas atvieglo virtuālās mašīnas monitora izveidi un ļauj viesa operētājsistēmas darbināt atsevišķi. ^[6] Aparatūrveicināta virtualizācija pirmo reizi tika ieviesta IBM System/370 1972. gadā, lietošanai ar VM/370, pirmo virtuālo mašīnu operētājsistēmu, ko IBM piedāvāja kā oficiālu produktu. ^[7]

2005. un 2006. gadā Intel un AMD nodrošināja papildu aparatūru virtualizācijas atbalstam. Sun Microsystems (tagad Oracle Corporation) 2005. gadā pievienoja līdzīgas funkcijas savos UltraSPARC T sērijas procesoros. Šādai aparatūrai pielāgotu virtualizācijas platformu piemēri ir KVM, VMware Workstation, VMware Fusion, Hyper-V, Windows Virtual PC, Xen, Parallels Desktop for Mac, Oracle VM Server for SPARC, VirtualBox un Parallels Workstation.

2006. gadā tika konstatēts, ka pirmās paaudzes 32 un 64 bitu x86 aparatūras atbalsts reti sniedz veiktspējas priekšrocības, salīdzinājumā ar programmatūras virtualizāciju.^[8]

Operētājsistēmas līmeņa virtualizācija

Operētājsistēmas līmeņa virtualizācijā fiziskais serveris tiek virtualizēts operētājsistēmas līmenī, ļaujot vairākiem izolētiem un drošiem virtualizētiem serveriem darboties vienā fiziskā serverī. Viesa operētājsistēmas vidēm ir tāda pati operētājsistēmas darbības instance kā resursdatora sistēmai, tādējādi to pašu operētājsistēmas kodolu izmanto arī viesa vides ieviešanai. Lietojumprogrammas, kas darbojas noteiktā viesa vidē, to uzlūko kā atsevišķu sistēmu. Pirmie šādu risinājumu ieviesa FreeBSD jail ; citi piemēri ir Docker, Solaris Containers, OpenVZ, Linux-VServer, LXC, AIX Workload Partition, Parallels Virtuozzo Containers un iCore Virtual Accounts.

Atsauces

↑ Popek, Gerald J.; Goldberg, Robert P. (1974). "Formal requirements for virtualizable third generation architectures" (PDF). Communications of the ACM. 17 (7): 412–421. doi:10.1145/361011.361073. S2CID 12680060.
↑ ^2,0 ^2,1 Smith, James E.; Nair, Ravi (2005). "The Architecture of Virtual Machines". Computer. 38 (5): 32–38, 395–396. doi:10.1109/MC.2005.173. S2CID 6578280.
↑ Oliphant, Patrick. "Virtual Machines". VirtualComputing. Archived from the original on 2016-07-29. Retrieved 2015-09-23. Some people use that capability to set up a separate virtual machine running Windows on a Mac, giving them access to the full range of applications available for both platforms.
↑ "Super Fast Server Reboots – Another reason Virtualization rocks". vmwarez.com. 2006-05-09. Archived from the original on 2006-06-14. Retrieved 2013-06-14.
↑ "Server Consolidation and Containment With Virtual Infrastructure" (PDF). VMware. 2007. Archived (PDF) from the original on 2013-12-28. Retrieved 2015-09-29.
↑ Uhlig, Rich; Neiger, Gil; Rodgers, Dion; Santoni, Amy L.; Martins, Fernando C. M.; Anderson, Andrew V.; Bennett, Steven M.; Kägi, Alain; Leung, Felix H.; Smith, Larry (May 2005). "Intel virtualization technology". Computer. 38 (5): 48–56. doi:10.1109/MC.2005.163. S2CID 18514555.
↑ Randal, A. (2019). The Ideal Versus the Real: Revisiting the History of Virtual Machines and Containers.
↑ Adams, Keith; Agesen, Ole (2006-10-21). A Comparison of Software and Hardware Techniques for x86 Virtualization(PDF). ASPLOS’06 21–25 October 2006. San Jose, California, USA. Archived (PDF) from the original on 2010-08-20. Surprisingly, we find that the first-generation hardware support rarely offers performance advantages over existing software techniques. We ascribe this situation to high VMM/guest transition costs and a rigid programming model that leaves little room for software flexibility in managing either the frequency or cost of these transitions.

[1] Popek, Gerald J.; Goldberg, Robert P. (1974). "Formal requirements for virtualizable third generation architectures" (PDF). Communications of the ACM. 17 (7): 412–421. doi:10.1145/361011.361073. S2CID 12680060.

[:0-2] 2,0 ^2,1 Smith, James E.; Nair, Ravi (2005). "The Architecture of Virtual Machines". Computer. 38 (5): 32–38, 395–396. doi:10.1109/MC.2005.173. S2CID 6578280.

[3] Oliphant, Patrick. "Virtual Machines". VirtualComputing. Archived from the original on 2016-07-29. Retrieved 2015-09-23. Some people use that capability to set up a separate virtual machine running Windows on a Mac, giving them access to the full range of applications available for both platforms.

[4] "Super Fast Server Reboots – Another reason Virtualization rocks". vmwarez.com. 2006-05-09. Archived from the original on 2006-06-14. Retrieved 2013-06-14.

[5] "Server Consolidation and Containment With Virtual Infrastructure" (PDF). VMware. 2007. Archived (PDF) from the original on 2013-12-28. Retrieved 2015-09-29.

[6] Uhlig, Rich; Neiger, Gil; Rodgers, Dion; Santoni, Amy L.; Martins, Fernando C. M.; Anderson, Andrew V.; Bennett, Steven M.; Kägi, Alain; Leung, Felix H.; Smith, Larry (May 2005). "Intel virtualization technology". Computer. 38 (5): 48–56. doi:10.1109/MC.2005.163. S2CID 18514555.

[7] Randal, A. (2019). The Ideal Versus the Real: Revisiting the History of Virtual Machines and Containers.

[8] Adams, Keith; Agesen, Ole (2006-10-21). A Comparison of Software and Hardware Techniques for x86 Virtualization(PDF). ASPLOS’06 21–25 October 2006. San Jose, California, USA. Archived (PDF) from the original on 2010-08-20. Surprisingly, we find that the first-generation hardware support rarely offers performance advantages over existing software techniques. We ascribe this situation to high VMM/guest transition costs and a rigid programming model that leaves little room for software flexibility in managing either the frequency or cost of these transitions.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]