Bonjour Yann,
Je dirais:
On 06/04/16 13:48, Yann Lehmann wrote:
> Bonjour,
>
> Dans l'organisation où je travaille, nous avons récemment acquis un
> nouveau serveur physique pour consolider notre infrastructure.
>
> Il tourne sous VMWare ESXi 6.0 (oui je sais, pas libre) et héberge 5
> machines virtuelles sous Windows (...) et une sous Linux.
>
> Nous avons encore un vieux serveur physique qui tourne sous Linux, et
> l'objectif est de virtualiser ce système sur la machine ESXi.
>
> D'après mes premières (et succinctes) recherches sur le net, il y a au
> minimum les 3 manières ci-dessous de procéder:
>
> 1) nouvelle installation de Linux dans la VM, puis transfert des
> données d'applications (fichiers de configuration, bases de données,
> etc. comme lors d'un transfert entre 2 machines physiques)
Recommandée si cela représente une opportunité de mettre à jour la
machine "from scratch" ou si les partitions définies sur la machine
physiques sont "trop grosses".
>
> 2) copie des disques/partitions (avec 'dd' ou autre) vers la machine
> virtuelle et adaptation éventuelle des fichiers de configuration
> ('fstab' entre autre)
Sans aucun doute la manière la plus rapide de faire, pour autant que
l'on soit à l'aise avec ce genre d'opération et que les partitions
définies ne soient pas "trop grosses". Une certitude: une fois la
migration terminée, Linux n'y verra que du feu (contrairement à certains
autres OS beaucoup plus "touchy" à propos de ce genre de modif')
>
> 3) utilitaire p2v de VMWare, qui tourne sous Windows et ne semble pas
> prendre en charge les configs Linux tournant sur du RAID matériel (ce
> qui est le cas ici)
>
> J'aurais deux questions dans l'optique de cette virtualisation:
>
> 1) quelqu'un saurait-il me recommander l'une ou l'autre des 3 méthodes
> ci-dessus (ou une alternative) ?
>
> 2) jusqu'à présent, j'ai utilisé un partitionnement "classique" sur
> les machines Linux que j'ai configurées et n'ai pas d'expérience avec
> LVM. Ce dernier fait-il sens dans une machine virtuelle ?
LVM permettant de:
a. très facilement augmenter la taille d'une partition
b. très facilement avoir autant de partitions que nécessaire (sans les
astuces du genre "primary" vs "extended" d'un partitionnement bas niveau
et avec l'avantage d'une identification claire des partitions:
/dev/mapper/-)
je dirais que cela conserve son sens, *même* dans une machine virtuelle
(où l'on est pas nécessairement plus à l'abri de ce genre de besoin que
dans une machine physique) et ça ne "mange pas de pain"
> Si oui, quelles sont les principales différences/difficultés
> rencontrées par rapport à un partitionnement "classique" ?
Je peux peut-être répondre partiellement à cette question en détaillant
la stratégie que j'ai appliqué aux quelques 250 (!) VM Linux (serveurs,
sans GUI) que nous hypervisons (avec KVM plutôt qu'ESX):
1. pour toutes les VMs, un disque (virtuel) de 5GiB, pour l'OS:
/boot: ext4, 0.5GiB # rester le plus "basique" possible, pour le jour
où il faut dépatouiller grub ou le initrd (PS: en 10 ans, ça ne m'est
jamais arrivé... mais "better safe than sorry")
/(root): LVM/ext4, 2GiB
/var: LVM/ext4, 1GiB
/tmp: LVM/ext4, 0.5GiB
(swap): LVM, 1GiB # ne devrait jamais être utilisé dans une VM... mais
"better safe than sorry"
2. pour les VMs nécessitant un espace de stockage (données applicatives)
supérieur à ce que /var propose (1GiB): un ou plusieurs disques
(virtuels) supplémentaires de taille adéquate, et utiliser des symlinks
dans /var; exemple: /var/lib/mysql => /disk2/var/lib/mysql
Dans tous les cas: limiter autant que possible la taille des disques
virtuels, pour le jour où il faut s'amuser à les déplacer ou les
récupérer depuis les backups (expérience vécue il y a 5 jours... 67
VMs... 1.5TB de données "disques"... 7 VMs Windows en représentant à
elles seules la moitié...).
À noter que pour les disques virtuels - sous KVM - deux choix sont
possibles:
- format "RAW": pas de "compression" des données (disque de 5GiB =
fichier de 5GiB)... mais très "deduplication-friendly" (si stockage de
multiples VMs sur des filers proposant la dédup' des données) => idéal
pour le disque "OS" (nous dépassons les 90% de dédup' grâce à cette astuce)
- format "QCOW2": le fichier du disque grossit au fur et à mesure que
des données y sont écrites, donc pas de gaspillage de l'espace physique
=> idéal pour les disques "données"
ESX doit j'imagine proposer le même genre de choix.
Enfin, c'est une piste parmi d'autre ;-)
Cédric
>
> Merci par avance pour toute info, lien, etc. et meilleures salutations
> Yann
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> http://forum.linux-gull.ch/mailman/listinfo/gull
___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull
