En virtuell maskins processortyp: varför standardvalet är långsamt och varför host inte alltid är rätt

När man skapar en virtuell maskin finns ett fält som heter processortyp, och det lämnas oftast på standardvärdet. Det värdet är en ganska gammal, allmän processormodell.

Det är ingen förbiseelse utan ett medvetet val. Men att lämna det där utan att veta vad det kostar dig är däremot en förbiseelse.

Varför standardvalet är så gammalt

Den processormodell som visas för en virtuell maskin avgör vart den maskinen kan flyttas. En körande maskin kan inte flyttas till en tjänare som inte stöder de processoregenskaper den fått se.

Att visa den äldsta och mest allmänna modellen ger den bredaste kompatibiliteten. Det är standardvalets logik: den ska kunna gå överallt.

Vad det kostar

Moderna processorer har särskilda instruktioner som gör vissa arbeten många gånger snabbare. Kryptering, komprimering, mediearbete och avtrycksberäkning drar direkt nytta av dem.

Den gamla standardmodellen döljer de instruktionerna för gästen. Eftersom gästen inte ser dem tar den den långsamma vägen. Resultat: din tjänare skulle kunna göra det arbetet snabbt, din virtuella maskin kan det inte.

Skillnaden är inte liten. En tjänst som krypterar kan i den virtuella maskinen ta flera gånger den tid samma arbete tar på tjänaren. Och den skillnaden dyker aldrig upp någonstans som ett fel; den känns bara som "här är det långsamt".

Den andra ytterligheten: att visa tjänarens processor som den är

I andra änden kan du skicka vidare tjänarens processor som den är. Gästen ser alla moderna instruktioner och kör som snabbast.

Priset är lika tydligt: den maskinen kan inte flyttas medan den kör till en tjänare med en annan processor. Har du byggt ett kluster står den maskin du vill flytta en underhållsnatt kvar just på grund av den här inställningen.

Valet är alltså samma byte som återkommer gång på gång i den här wikin: prestanda eller rörlighet.

Tre lägen, tre svar

Har du en enda maskin, skicka vidare tjänarens processor. Det finns ingenstans att flytta, så det är meningslöst att betala för kompatibilitet.

Är tjänarna i klustret identiska kan du också skicka vidare den. Samma processor, samma egenskaper.

Skiljer sig tjänarna i klustret, ta mellanvägen: välj en namngiven modern modell som alla stöder. Du får merparten av de moderna instruktionerna och flyttbarheten bevaras. Detta är det mest förbisedda och oftast mest riktiga alternativet.

Den vanliga fällan

Det sker i den här ordningen: du börjar med en maskin, ställer processorn på tjänarens, månader går, du köper en andra tjänare och bygger ett kluster, och när en underhållsnatt kommer flyttar maskinerna inte.

I det ögonblicket minns ingen en inställning gjord för månader sedan. Den dag du bygger ett kluster, gå igenom processorinställningen på de befintliga maskinerna.

Vad man bör veta när man ändrar

Att ändra processormodell innebär att visa gästen att hårdvaran har ändrats. Därför kräver ändringen att maskinen stängs av helt och startas igen; att starta om inifrån räcker inte.

Vissa operativsystem märker en hårdvaruändring även licensmässigt. Har du en sådan gäst, räkna med det innan du gör ändringen.

Vad Atlas gör

Atlas känner igen de gamla standardprocessortyperna och märker det när en maskin fortfarande kör med någon av dem.

Valet av nivå spelar roll här: detta är ett förslag, ingen varning. Skälet är ärligt: standardvalet är inte trasigt, det fungerar. Det finns bara prestanda kvar på bordet. Att kalla något som inte är trasigt för en varning sänker värdet på riktiga varningar.

Märkningen ligger under rubriken prestanda, så den säger inte "den här maskinen är fel uppsatt", den säger "den här maskinen kunde vara snabbare".

Och förslaget tar dig direkt dit inställningen finns. Att berätta för någon att något kan förbättras och sedan låta hen leta efter var det ligger är bara marginellt bättre än att inte berätta.