Reading Time: 4 minutes

Per l’elenco di tutti gli obiettivi vedere la pagina dell’esame VCP5.

Objective 5.4 – Migrate Virtual Machines

Vedere anche (in inglese): Objective 5.4 – Migrate Virtual Machines e Objective 5.4 – Migrate Virtual Machines.

Identify ESXi host and virtual machine requirements for vMotion and Storage vMotion (same as vSphere 4.x)

Vedere la vSphere Virtual Machine Administration guide (pag. 219) e la vCenter Server and Host Management guide (pag. 119 e  122).

Oltre ad altri requisiti, per il vMotion è necessaria un’interfaccia vmkernel specifica (abilitata per il vMotion) e la compatibilità dei processi o l’EVC. Per lo Storage vMotion l’host dove viene eseguita l’operazione deve poter vedere sia il datastore sorgente che quello di destinazione.

Identify Enhanced vMotion Compatibility CPU requirements (similar as vSphere 4.x)

Vedere la vCenter Server and Host Management guide (pag. 123) e l’articolo VMware KB: Enhanced VMotion Compatibility (EVC) processor support. Da notare che sono disponibili maggiori baseline.

Identify snapshot requirements for vMotion/Storage vMotion migration (similar as vSphere 4.x)

Vedere la vCenter Server and Host Management guide (pag. 121). Esistono alcune limitazioni per le VM con snapshot:

  • vMotion e host migration sono possibili (se ovviamente sono soddisfatti i relativi requisti ed in particolare che tutti i file della VM risiedano su storage condiviso).
  • Storage vMotion o datastore migration sono possibili se gli host sono ESX 3.5 / ESXi 3.5 o successivi e se tutti i file della VM risiedono in una singola directory.
  • Da notare che un’operazione di revert di una snapshot dopo un vMotion puà fallire, visto che il processore potrebbe essere cambiato (in realtà questo può capitare solo se la snapshot contiene anche lo stato della VM).

Migrate virtual machines using vMotion/Storage vMotion (similar as vSphere 4.x)

Vedere la vSphere Virtual Machine Administration guide (pag. 223) e la vCenter Server and Host Management guide (pag. 132). Può essere anche gestito tramite vSphere Web Client.

Capire anche la differenza del livello di priorità del vMotion. Nel caso di un vMotion con high priority, sugli host ESX/ESXi 4.1 o successivi, il vCenter Server cerca di riservare le risorse sia su sorgente che destinazione dando un livello di share maggiore delle migrazioni con standard priority. Sugli host con ESX/ESXi 4.0 o precedente, vCenter Server cerca di riservare un livello fisso di risorse e una migrazione di tipo high priority può non procedere se non ci sono abbastanza risorse libere.

Per quanto riguarda lo Storage vMotion è da notare che l’operazione non è supportata durante l’installazione delle VMware Tools.

Configure virtual machine swap file location (same as vSphere 4.x)

Vedere la vCenter Server and Host Management guide (pag. 121).

I VM swapfile possono essere salvati in due diverse posizioni: all’interno della cartella con i file di configurazione della VM, oppure su un datastore (locale o condiviso) specificato a livello di host. La configurazione si può applicare sia a livello globale (nel cluster) o a livello di singola VM. Con host 3.5 o successivi, durante un’operazione di vMotion, se il swapfile si trova in una posizione diversa da quella richiesta dall’host di destinazione, viene copiato tra un host e l’altro. Questo ovviamente rallenta l’operazione di vMotion.

Migrate a powered-off or suspended virtual machine (similar as vSphere 4.x)

Vedere la vSphere Virtual Machine Administration guide (pag. 220). Può essere anche gestito tramite vSphere Web Client.

Da notare che quando si migra una VM in stato di sospensione, l’host di destinazione deve avere un livello di compatibilità di processore tale da garantirne il resume.

Utilize Storage vMotion techniques (changing virtual disk type, renaming virtual machines, etc.) (same as vSphere 4.x)

See the vSphere Virtual Machine Administration guide (page 226).

Durante un’operazione di Storage vMotion (o anche una semplice operazione a “freddo” di datastore migrtion) tutti i file relativi alla VM vengono rinomitati (se necessario) per corrispondere la nome corrente dalla VM (cambiare nome alla VM, non corrisponde a rinominarne i file relativi). Inolte durante tali operazioni è anche possibile cambiare il formato dei file vmdk da thin a flat o viceversa.

Per quanto riguarda invece i dischi RDM, quelli in virtual compatibility mode possono essere migrati (o meglio viene migrato il file proxy) oppure possono essere convertiti a thick-provisioned o thinprovisioned (a patto che la destinazione non sia un datastore NFS). Per quelli in physical compatibility mode è invece possibile solo migrare il file proxy.

Share