Bonjour,
Il m'a semblé avoir lu quelque part que maintenant VMware (version 3.5 donc) permettait le swap en local et non sur le SAN, améliorant de manière significative les performances de l'OS tournant dans la VM (notamment Windows).
Mais je n'arrive pas à retrouver cette information.
Aurais-je rêvé ?
:smileylaugh:
Merci à vous.
- En général, le SAN, si il est de qualité, est conçu pour supporter un grand nombre d'accès simultanés et est donc plus performant en I/O et BP que le stockage local propre à un host, ne serait-ce que par le nombre de disque (on parle d'axes). Fais-en l'expèrience toi-même avec un outil du genre Atto dans une VM avec un vmdk local puis un vmdk sur le san.
- D'autre part, tu risques de perdre la fonctionnalité vmotion :
Virtual Machine Configuration Requirements for VMotion :
A number of specific virtual machine configurations can prevent migration of a virtual
machine with VMotion. These configurations are summarized below:
You cannot use migration with VMotion to migrate virtual machines using raw
disks for clustering purposes.
You cannot use migration with VMotion to migrate a virtual machine that uses a
virtual device backed by a device that is not accessible on the destination host.
(For example, you cannot migrate a virtual machine with a CD drive backed by the
physical CD drive on the source host.) Disconnect these devices before migrating
the virtual machine.
You cannot use migration with VMotion to migrate a virtual machine that uses a
virtual device backed by a device on the client computer. Disconnect these devices
before migrating the virtual machine.
You cannot use migration with VMotion to migrate a virtual machine if the
destination host cannot access the virtual machine's swapfile. For more
information, see "Swapfile Location Compatibility" on page 242.
Donc attention, en cas d'utilisation de vmotion, si le swapfile est local, le host de destination risque de ne pas le voir .... adieu vmotion (CQFD)
- En général, le SAN, si il est de qualité, est conçu pour supporter un grand nombre d'accès simultanés et est donc plus performant en I/O et BP que le stockage local propre à un host, ne serait-ce que par le nombre de disque (on parle d'axes). Fais-en l'expèrience toi-même avec un outil du genre Atto dans une VM avec un vmdk local puis un vmdk sur le san.
- D'autre part, tu risques de perdre la fonctionnalité vmotion :
Virtual Machine Configuration Requirements for VMotion :
A number of specific virtual machine configurations can prevent migration of a virtual
machine with VMotion. These configurations are summarized below:
You cannot use migration with VMotion to migrate virtual machines using raw
disks for clustering purposes.
You cannot use migration with VMotion to migrate a virtual machine that uses a
virtual device backed by a device that is not accessible on the destination host.
(For example, you cannot migrate a virtual machine with a CD drive backed by the
physical CD drive on the source host.) Disconnect these devices before migrating
the virtual machine.
You cannot use migration with VMotion to migrate a virtual machine that uses a
virtual device backed by a device on the client computer. Disconnect these devices
before migrating the virtual machine.
You cannot use migration with VMotion to migrate a virtual machine if the
destination host cannot access the virtual machine's swapfile. For more
information, see "Swapfile Location Compatibility" on page 242.
Donc attention, en cas d'utilisation de vmotion, si le swapfile est local, le host de destination risque de ne pas le voir .... adieu vmotion (CQFD)
Je suis bien d'accord avec toi, mis à part que mon SAN, relativement gros, et surtout mutualisé pour pas mal de comptes, est bien sollicité...
:smileyblush:
ATTO serait-il cet utilitaire : ATTO Disk Benchmark Test ?
Il est effet la localisation du swap file sur une ressource non accessible par le serveur cible pose problème.
En fait je pensais à quelque chose de plus "révolutionnaire" : peut être ais-je confondu avec une autre fonctionnalité (par exemple la quantité de RAM virtualisée supérieure à la RAM physique...) ou un concurrent (Hyper-V)...
Pourtant, c'est promis, je n'ai pas bu !
:smileylaugh: