Feeds:
Posts
Comments

Posts Tagged ‘live migration’

Een van de nieuwe vSphere 5 features lost een min of meer theoretisch probleem op. Stel dat je met vMotion een machine wilt verhuizen en dat de memory pages razendsnel veranderen in die machines. Het lukt je dan niet om de pagina’s naar de andere fysieke machine te verhuizen, omdat het resterende deel pagina’s dat nog te kopiëren overblijft maar niet kleiner wordt.

Daar heeft VMware iets op gevonden: Stun During Page Sends, oftewel verdoof de machine tijdens het verhuizen van de memory pages. Misschien moet je eigenlijk zeggen “versuffen”, omdat de machine wel degelijk blijft draaien, zoals het hoort tijdens vMotion.

vMotion

Dit is een van de vele verbeteringen rond vMotion in vSphere 5. Gelukkig zijn de meeste andere verbeteringen iets praktischer van aard. Zie voor een volledig overzicht de net gepubliceerde white paper daarover: “VMware vSphere vMotion – Archiecture, Performance and Best Practices in VMware vShpere 5”.

Bromn: Eric Sloof

Read Full Post »

Sun’s nieuwste 3.1 release van haar type 2 hypervisor VirtualBox ondersteunt nu ook live migration. En om het onderscheid met de concurrentie te verduidelijken wordt er gelijk maar een nieuw label op geplakt: “teleportation” (beam me up, Scotty).

Voor zover mij bekend is dit wel de eerste hosted hypervisor (dus anders dan bare metal hypervisors) die dit ondersteunt. Andere nieuwe features zijn:

  • 2D graphics ondersteuning voor Windows guest systemen
  • ondersteuning voor de virtIO standaard voor geparavirtualiseerde netwerk adapters

Alhoewel VirtualBox ook onder invloed van Oracle nog steeds gratis blijft, is dit vanaf nu wel beperkt tot persoonlijk gebruik. Zakelijk gebruik begint bij $30 per jaar.

Bron: virtualization.info

Read Full Post »

Microsoft had – net als VMware – het probleem op te lossen van de verschillen tussen CPU’s bij live migration. Deze CPU compatibility eis bewaakt dat zowel het operating systeem als de applicaties feilloos doordraaien op een andere fysieke machine na een live migration. Zijn de CPU’s niet compatibel dan loop je het risico dat het operating systeem of één van de applicaties een processorinstructie uitvoert die niet op die nieuwe processor aanwezig is, met alle gevolgen van dien (denk aan BSOD).

VMware heeft bij de oplossing hiervoor gekozen voor de meest veilige en robuuste manier. Dit is namelijk een combinatie van hypervisor-software en hardware-ondersteuning: “Flex Migration” in geval van Intel en “Extended Migration” bij AMD. Door deze hardware-ondersteunde aanpak kan de hypervisor-laag de onderliggende CPU forceren om geen instructies uit te voeren die de CPU op de machine waar je via live migration naar toe gaat niet aan zou kunnen. Daardoor weet je zeker dat alle software die op de eerste machine draait ook op de migration-target zal draaien (tenminste, voor zover het potentiële CPU-compatibiliteit problemen betreft natuurlijk).

Processor Compatibility

Microsoft heeft daarentegen bij de Live Migration van Server 2008 R2 gekozen voor een 100% software-aanpak. Het voordeel is duidelijk: dit ook werkt op oudere processoren die geen Flex of Extended Migration ondersteunen. Het nadeel is echter dat je nooit 100% zeker weet of er toch niet een applicatie draait op je eerste machine die niet – zoals het hoort – de capabilities van de processor vooraf heeft opgevraagd, maar gewoon instructies gebruikt die niet op alle processoren aanwezig zijn (zo’n applicatie kan bijvoorbeeld eenmalig een error-trap gebruiken om dit bij de start te detecteren). Alles gaat dan goed zolang de software op de eerste machine draait waar die instructies wel aanwezig zijn. Bij een live migration kan dit echter fatale gevolgen hebben. En helaas kan dat op elk moment in de tijd optreden, dus niet per se direct na de migratie want dan zou je wellicht nog handmatig kunnen ingrijpen.

Het argument van Microsoft hiervoor is “we zijn nog nooit software tegen gekomen die zich zo gedraagt”. Pragmatisme is natuurlijk altijd goed, maar gaat dit niet net een stap te ver?

Zie Microsoft’s Virtualization Team Blog voor een uitleg van Microsoft’s aanpak van Live Migration in Server 2008 R2

Read Full Post »

VMware’s VMotion is de meest bekende techniek om live migrations uit te voeren. Dit houdt in dat je draaiende virtuele machines van de ene fysieke server naar de andere verhuist, zonder dat de clients die van die draaiende machine gebruik maken er iets van merken.

De belangrijkste bottleneck hierbij is de migratie van main memory via het LAN (de virtuele disk moet namelijk sowieso op een shared storage systeem staan om VMotion te kunnen uitvoeren). Dat LAN moet dan ook minimaal een bandbreedte van 1Gbps hebben, en liever nog 10Gbps.

VMotion

Om de interruptie van de virtuele machine zo kort mogelijk te houden, wordt het geheugenis een paar kopie-slagen verhuist, terwijl de virtuele machine nog op de “oude” server draait. Na elke kopie wordt gekeken hoeveel verschil er intussen weer is ontstaan door de draaiende machine en wordt dat verschil opnieuw verstuurt. Normaal gesproken moeten die verschillen dus steeds kleiner worden. Uiteindelijk beslist VMotion om het laatste restant te versturen, de “oude” virtuele machine te stoppen en de “nieuwe” in de lucht te brengen.

Kevin Lawton heeft dit mechanisme nu verder verfijnd, door over meerdere servers te onderzoeken hoeveel duplicaten van brokken memory al aanwezig zijn in de “nieuwe” server of in zijn directe omgeving. Hij toont aan dat hiermee enorme versnellingen mogelijk zijn, met factoren 4 tot 10 of zelfs meer. Wellicht dat hierdoor live migration ook ooit op lange afstand via relatief trage verbindingen mogelijk gemaakt kan worden.

Bron: virtualization.info

Read Full Post »

Live migration zorgt ervoor dat je draaiende virtuele machines ongemerkt voor de gebruikers kunt verplaatsen van de ene fysieke host naar de andere. Je kunt dit bijvoorbeeld gebruiken om de belasting van de fysieke hosts in balans te houden (load balancing dus). Het mooiste voorbeeld daarvan is VMware’s Distributed Resource Scheduler.

Wat live migration ook mogelijk maakt – in theorie althans – is het verplaatsen van virtuele machines om je netwerkbelasting te optimaliseren. Doug Gourlay van Cisco noemt dit Anti-Routing of Virtual Routing. Je zou er bijvoorbeeld automatisch voor kunnen zorgen dat virtuele machines die onderling intensief over het netwerk communiceren, dicht bij elkaar – wellicht op dezelfde fysieke host – terecht komen.

Chris Hoff griezelt bij de gedachte wat dit voor je security zou kunnen inhouden. Voor hem vormt virtual routing dan ook veel meer de antimaterie van security dan van routing.

Read Full Post »

Zoals eerder gemeld is het live migreren van virtuele machines over processoren van verschillende makelij geen sinecure. Ook Server Virtualization News komt nu tot dezelfde conclusie. Er staat VMware niets in de weg om een soortgelijke demo te geven als die van Red Hat en AMD. Echter, garanderen dat je virtuele machine onder alle omstandigheden blijft doordraaien na een live migration is andere koek. VMware weigert dan ook terecht dit te ondersteunen zolang ze zulke garanties niet kunnen geven.

De suggestie dat dit met een stukje bescherming van Intel te maken zou hebben gaat mij te ver, te meer daar Intel haar belang in VMware juist aan het afbouwen is.

Bron: virtualization.info.

UPDATE: Zie ook Mike D’s blog voor nog meer uitleg en leidend tot dezelfde conclusie.

Read Full Post »

Red Hat en AMD demonstreren hoe je een draaiende virtuele machine kunt migreren van een Intel processor naar een AMD processor (‘live migration‘ dus). Als je weet hoe complex dit is (zie ‘Zin en onzin van VMotion CPU compatibiliteit‘) dan krijgt het geheel toch wel de WOW-factor van een kermisattractie.

Wat ik vermoed is dat Red Hat er op hypervisor-niveau voor zorgt dat de virtuele machines slechts de grootst gemene deler van zowel Intel als AMD zien. Op deze manier regel regel je dan dat het operating systeem binnen de virtuele machine geen gebruik maakt van vendor-specifieke uitbreidingen. Dit is met enig kunst en vliegwerk wellicht te doen.

Wat mij eerlijk gezegd erg moeilijk lijkt is dat je kunt garanderen dat de applicaties binnen de virtuele machine hetzelfde doen. Dit laatste is juist de reden dat VMware met VMotion zoveel effort gestoken heeft in Enhanced VMotion Compatibility. Maar wellicht is Red Hat erin geslaagd om Intel’s Flex Migration en AMD’s Extended Migration onder één noemer te brengen?

Bron: VMblog.com.

Read Full Post »

Follow

Get every new post delivered to your Inbox.