Journal Migrer une VM de VMWare vers KVM

Posté par .
Tags : aucun
11
28
avr.
2010
Pas besoin de faire l’article de la virtualisation, il faudrait être sur une île déserte pour ne pas avoir croiser au moins un article sur le sujet… Gain de place, d’énergie ou de matériel, facilité d’utilisation et d'adminsitration, les machines virtuelles ont le vent en poupe. Parmi les solutions populaires, on trouve des solutions Open Source comme VirtualBox, Xen ou Kvm et des solutions propriétaires comme Hyper-V, Parallels ou VmWare (leader du marché avec 90%).

Petite exemple de migration d’une VM de VMWare vers une instance KVM couplée à la libvirt. Cet exemple sera fait avec une Red Hat 3, mais reste valable quelque soit le système migré, Windows y compris.

Premièrement il faut éteindre la VM sur VMWare, trouver le répertoire de stockage des vms. Bien souvent, VmWare fragmentent la machine virtuelle en plusieurs fichiers images vmdk. Si c’est le cas, il faut en faire une seul image à l’aide dela commande suivante :

vmware-vdiskmanager -r root_image.vmdk -t 0 complete_image.vmdk

Le fichier root_image fait généralement quelques kilo-octets et n’est pas suffixé par s*. Il faut ensuite la convertir en fichier brut, cela permettra par la suite de pousser cette image dans un volume LVM.

qemu-img convert complete_image.vmdk -O raw raw.img

Une fois que vous avez créé et activé un volume LVM, par exemple /dev/ovirt/vm. Il suffit de copier le fichier img dans le volume disque grâce à la commande dd :

dd if=raw.img of=/dev/ovirt/vm

Si votre volume est distant, la copie peut prendre quelques dizaines de minutes. Vous pouvez désormais créer la vm avec la libvirt, en utilisant le périphérique LVM comme disque dur.
  • # La virtualisation

    Posté par . Évalué à -1.

    • [^] # Re: La virtualisation

      Posté par (page perso) . Évalué à 10.

      C'est quand même un gros ramassis de n'importe quoi ce truc.

      Dans un environnement Windows, un service par serveur est une bonne pratique...

      Exemple: Spooleur d'impression planté (sous windows, c'est tout le temps, tu peux plus supprimer les jobs, le spooleur ne veut plus ni s'éteindre ni redémarrer), ben t'es bien heureux d'avoir une machine virtuelle pour gerer cette daube et de pouvoir faire un reboot qui va impacter un seul service et donc pouvoir passer presque inaperçu.


      Mais dans tous les cas, même en env Linux, ça permet une segmentation des taches, untel gere tel serveur, on arrive vite à des archis avec une dizaines de machines virtuelles par serveur, ou chaque admin fait son foin... Je te dis pas le bordel avec 1 seul machine avec 10 personnes avec le login root.

      Idem dans mon ancien taf, la salles serveur, c'était une cuisine (et oui), avec deux serveur Proxmox avec: 1 slis, 1 sambaedu, 1 debian de test, 1 windows 2003, 1 windows 2008, 1 windows XP et 1 windows Seven... Si on avait du remplacer ça par des machines physiques, on pouvait plus prendre le café le matin :)

      Donc certe, la virtualisation ça fait hype, souvent on en installe sans raison particulière mais dans de nombreux cas, c'est très utile.

      Et pourquoi 1 service par serveur ? (meme sous Linux).

      Ben quand tu as une migration à faire (upgrade system par ex) sur un service particulier, tu fais une copie de ta VM, tu la migres, tu la mets en prod et si c'est ok tu oublies l'ancienne...

      Si sur ton serveur y'a 10 services qui tournent, tu dois te migrer les 10 services d'un coup, SUPER...
      • [^] # Re: La virtualisation

        Posté par . Évalué à -2.

        Beau ramassis de connerie....

        Le nombre de machine virtuelle n'est pas infini! si t'as pas encore compris ça, ne parle plus de virtualisation.

        Avec des conneries dans ce genre, les économies de matériel, d'énergie et de temps, tu oublie. Je gère plus de 500 MV, et si on calmais pas les projet de temps en temps, on serait à la dèche de ressources. On arrive déjà à faire ramer des cluster de 8 machines de 64Gio de RAM et 4 Quadricore. Pourquoi? Parce que les gens crois que le nombre de machines est infini vu que c'est virtuel! Arrêtez de penser ça!

        Quand a Windows et son spooleur, si t'y connais rien, n'administre pas de serveur : j'ai administré pendant 3 ans des serveurs windows, de NT4 à 2008 en passant par 2000 et 2003 et je n'ai jamais eu ce genre de problèmes. En plus, mutualisé ou pas, tu peut quand même appliquer ta méthode de la seconde machine virtuel, ce qui est un peu con quand on a des snapshot...

        Bref, merci d'arrêter de raconter n'importe quoi!
        • [^] # Re: La virtualisation

          Posté par (page perso) . Évalué à 6.

          >Le nombre de machine virtuelle n'est pas infini!

          C'est pas vrai, putain, j'avais vraiment besoin d'un mec aussi intelligent que toi pour m'éclairer.

          500 MV, joli, quel bel engin...

          Après, plus serieusement, tout dépend de ce que font tes machines virtuelles, et de leur conso cpu/ram.

          >j'ai administré pendant 3 ans des serveurs windows, de NT4 à 2008 en passant par 2000 et 2003

          Wah, tout ca, que tu es fort, vraiment, quel homme...

          Plus serieusement, il devait pas faire grand chose tes serveurs niveau impression pour que cela ne te soit jamais arrivé! Et t'as pas du utiliser beaucoup de Windows dans ta vie car ce problème existe aussi dans le monde du desktop.

          1 job planté sous windows que l'ont ne peut pas supprimer, ca arrive régulièrement, et quand le service d'impression refuse de répondre, ben tu l'as dans le cul...

          >ce qui est un peu con quand on a des snapshot...

          Euh c'est quoi le rapport avec les snapshots ?

          Toi t'es du genre, je fais mon snapshot, je passe 3 heures à mettre à jour mon serveur et j'emmerde les utilisateurs, et si ca chie je reviens en arrière ?
          • [^] # Re: La virtualisation

            Posté par . Évalué à -2.

            >Toi t'es du genre, je fais mon snapshot, je passe 3 heures à mettre à jour mon serveur et j'emmerde les utilisateurs, et si ca chie je reviens en arrière ?

            Ouai, on appel ça une mise en Prod et en général, on l'a testé sur des serveurs de Pré-Prod avant...

            >Après, plus serieusement, tout dépend de ce que font tes machines virtuelles, et de leur conso cpu/ram.

            Quoi le fait que le nombre de machines ne soit pas infini? relis toi...

            >Plus serieusement, il devait pas faire grand chose tes serveurs niveau impression pour que cela ne te soit jamais arrivé! Et t'as pas du utiliser beaucoup de Windows dans ta vie car ce problème existe aussi dans le monde du desktop.

            Ben si pourtant, mais peut être que c'est toi qui ne sait pas t'en servir?

            > 1 job planté sous windows que l'ont ne peut pas supprimer, ca arrive régulièrement, et quand le service d'impression refuse de répondre, ben tu l'as dans le cul...

            Gestionnaire des tâches > terminer le processus spoolsv.exe, redémarrer le service... Mais bon, y'a surement d'autres moyens...

            >C'est pas vrai, putain, j'avais vraiment besoin d'un mec aussi intelligent que toi pour m'éclairer.
            >Wah, tout ca, que tu es fort, vraiment, quel homme...
            >Euh c'est quoi le rapport avec les snapshots ?

            A part ça, t'as de vrais arguments?
        • [^] # Re: La virtualisation

          Posté par . Évalué à 2.

          Beau ramassis de connerie....

          Je ne pense pas que tu ais déjà mis en place une infrastructures d'hébergement d'application (SI ou Services).

          C'est claire que si t'as juste joué avec VMWare workstation sur ton portable, ça va pas t'avoir beaucoup éclairé sur les avantages.

          Vu le niveau d'où ça part, je ne ramerai pas pour te répondre, c'est peine perdue.




      • [^] # Re: La virtualisation

        Posté par . Évalué à 7.

        Si sur ton serveur y'a 10 services qui tournent, tu dois te migrer les 10 services d'un coup, SUPER...

        Ou alors tu bascule gentiment tes services un par un sur une autre machine sur laquelle le système aura été mis à jour. Si ça ne marche pas tu re-bascules sur l'ancienne machine et tu recommences.

        C'est vrai qu'avant la virtualisation, on ne mettait jamais à jour.
        • [^] # Re: La virtualisation

          Posté par (page perso) . Évalué à 1.

          >alors tu bascule gentiment tes services un par un sur une autre machine
          >sur laquelle le système aura été mis à jour.

          Soit toto.prout ta machine de base.
          Soit toto2.prout ta machine à jour.

          Tu fais comment toi pour migrer tes 10 services 1 par 1 si les clients pointent vers toto.prout? Dès le premier service migré t'es bloqué.
          • [^] # Re: La virtualisation

            Posté par . Évalué à 6.

            si les clients pointent vers toto.prout

            10 services et un seul fqdn ? Autant utiliser l'ip directement, ça t'évitera de devoir gérer un dns.
            • [^] # Re: La virtualisation

              Posté par (page perso) . Évalué à 1.

              Faut il encore que tes services utilisent DNS pour faire leur résolution de nom, dans le monde windows, les mauvaises habitudes persistent...

              Bon, avec 2008 plus de WINS par défaut, ca va peut être changer, mais vu le nombre de soft ou pour fonctionner dans un env multiutilisateurs, il faut mettre du control total dans C:\Program Files\... (pourtant ca fait un moment que XP est sorti...), j'ai comme un doute...
      • [^] # Re: La virtualisation

        Posté par (page perso) . Évalué à 2.

        Spooleur d'impression planté (sous windows, c'est tout le temps [...] )
        Rhaaaa cette "fonctionnalité" là, elle m'énerve, mais elle m'énerve !!

        Tite question: dans ma boîte on a de gros serveurs TSE. Avec entre 30 et 150 personnes dessus selon la machine, et autant d'imprimantes. Et là, lorsque le spooler est mort, c'est le service informatique qui est mort :-)
        Créer un serveur séparé pour faire office de spooler ne change rien puisque le serveur TSE doit également avoir tous les pilotes, et il fait office de spooler intermédiaire (donc ça ne fait qu'augmenter le risque de panne).
        On s'en sort comment de cette sinistre affaire ? Jusqu'à présent je n'ai pas trouvé, mais il faut dire que nous avons très peu de problème de spooler car nous avons limité les pilotes.
        • [^] # Re: La virtualisation

          Posté par (page perso) . Évalué à 2.

          Oui, c'est l'avantage quand c'est toi qui commande le matériel et pas tes utilisateurs :)
        • [^] # Re: La virtualisation

          Posté par . Évalué à 2.

          Industrialisation des Postes de travail (souche commune) avec nombre de drivers limités et matos bien défini... Sans ça, c'est du masochisme...

          Ou vrai architecture, mais bon je suppose que tu vas devoir faire avec...
  • # virt-v2v

    Posté par (page perso) . Évalué à 2.

    Pour les gens qui connaissent pas, il y a ça aussi : http://people.redhat.com/mbooth/virt-v2v/
    C'est tout pas stable et en développement actif mais c'est fait pour ce genre de migration.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Précision

    Posté par . Évalué à 5.

    Pas besoin de convertir, de par l'héritage de Qemu, KVM sait déjà travailler avec des disques VMware, les fameux VMDK.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Y-a-t'il un pilote dans l'avion

    Posté par (page perso) . Évalué à 8.

    Dans l'avion je ne sais pas, mais dans Windows oui. Si tu démarres ton ex machine vmware sur KVM _et_ que c'est du Windows... ben ça marche pô :-)
    Il faut d'abord virer pilotes paravirtualisés vmware.
    Si on utilise Linux ou BSD, on n'a pas ce problème (mais il faut parfois éditer un fichier de configuration UDEV à cause des adresses MAC).
    • [^] # Re: Y-a-t'il un pilote dans l'avion

      Posté par . Évalué à 3.

      Merci pour l'info. C'est vrai que j'avais eu un écran bleu quand j'avais essayé, mais je n'avais pas cherché plus loin. Je vais essayer à nouveau sans.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # VMDK

    Posté par (page perso) . Évalué à 2.

    Jamais compris l'intérêt de ces formats d'image de disque dur àlacon®. Il n'y a qu'un seul format direct et simple : l'image brute. Avec l'aide des fichiers creux pour le stockage, et de la compression pour le transfert.
    • [^] # Re: VMDK

      Posté par . Évalué à 4.

      ça vient du monde windows et de cette fameuse limite des fichiers à 2Go sur le Fat32 qui fait qu'ils ont du inventer un format qui gère les volumes divers. Mais c'est vrai que maintenant que ntfs est généralisé au grand public depuis XP, ça n'a plus grand intérêt même dans le monde windows.

      J'imagine aussi que le format prend directement en charge la gestion des snapshots mais à vrai dire je ne me suis jamais penché sur le sujet pour savoir comment c'était fait.
      • [^] # Re: VMDK

        Posté par . Évalué à 4.

        c'est 4 Go, FAT32...
        • [^] # Re: VMDK

          Posté par . Évalué à 1.

          Tiens comme quoi ça c'est vraiment la préhistoire pour que je ne m'en rappelle plus.
    • [^] # Re: VMDK

      Posté par (page perso) . Évalué à 1.

      Des fonctionnalités du genre redimensionnement de l'image en fonction des besoins?
      Le stockage d'infos sur la VM en question directement intégrée dans l'image au lieu de la mettre dans un petit fichier de conf à coté, question de passer par le clicodrôme ou de devoir lire 3 pages de man à chaque changement de config que tu veux faire?
      Je ne vois pas tellement d'autres raisons...

      Une image brute peut supporter un redimensionnement à la volée selon les besoins d'ailleurs?
      • [^] # Re: VMDK

        Posté par . Évalué à 1.

        Des fonctionnalités du genre redimensionnement de l'image en fonction des besoins?
        man dd (ou plus simple man cat)

        stockage d'infos sur la VM en question directement intégrée dans l'image au lieu de la mettre dans un petit fichier de conf à coté
        Même pas. La VM est configurée par un fichier VMX, qui fait appel à des VMDK.


        Une image brute peut supporter un redimensionnement à la volée selon les besoins d'ailleurs?
        À la volée, je ne pense pas, mais un VMDK non plus. Cependant, tu peux le faire à froid avec dd, pas de limitation de ce côté.

        Sinon, une image de type VMDK, tu peux la mettre sur un volume logique LVM, comme dans le journal ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: VMDK

        Posté par . Évalué à 2.

        « Une image brute peut supporter un redimensionnement à la volée selon les besoins d'ailleurs? »

        Bah, c'est un fichier avec un système de fichier dedans.
        Agrandir la taille d'un fichier est une opération triviale.
        Agrandir un système de fichier pour exploiter la place disponible est relativement aisé, selon le FS choisi, mais ça se fait assez bien.

        Donc je suppose que la réponse est oui, et de façon relativement triviale.

        Finalement une image brute, ce n'est rien d'autre qu'un sous-partitionnement d'une partition logique de ton disque dur, en une autre partition logique, ou un ensemble de partitions avec table de partition et tout. C'est la façon simple et triviale de faire les choses.
        Il se trouve que ça marche plutôt bien en fait.

        Tu peux même monter directement ton image, ou une partition à l'intérieur de ton image si il en contient plusieurs, directement sur le système hôte.

        Bref, ça marche, c'est un peu la même différence qu'entre un vrai CD/DVD dans ton lecteur et une image ISO, matériellement c'est différent, mais sinon c'est la même tambouille pour y accéder, et le faire fonctionner.


        Yth.
    • [^] # Re: VMDK

      Posté par (page perso) . Évalué à 3.

      l'image "raw" serait suffisante pour faire ce que l'on fait avec un disque dur physique: l'associer à une machine.
      Par contre la virtualisation a créé de nouveaux "besoins" (on peut toujours en discuter hein :)), comme par exemple le fait de factoriser ce qui est factorisable entre plusieurs disques différents. Et dans ce cas, c'est bien pratique d'avoir un fichier pour le facteur commun et un fichier "delta" pour les spécificités de chacun.

      L'alternative "raw" serait probablement de réinventer un partitionnement intermédiaire, mais outre le fait que c'est un peu compliqué pour pas grand chose (puisque justement ça ne serait plus si "raw" que ça...), ça ne résisterait pas longtemps au fait qu'à un moment ces VMs vont être migrées sur des serveurs différents et qu'on aura alors autre chose à faire que "départitionner" les disques virtuels (alors qu'avec l'approche fichiers, on sait directement ce qu'on doit copier/déplacer/fusionner).

      Comme il a été dit plus haut, le support des snapshots est aussi plus simple comme ça, notamment du fait qu'ils sont accessibles en écriture.

      Et évidemment, l'indépendance relative (paraît que les VMs de 20Go sur disquettes 3.5'', ça marche pas trop :)) par rapport au système de stockage impose la possibilité d'un fichier fragmenté.

      Enfin bref, y a quand même quelques raisons, c'est promis ;)
      • [^] # Re: VMDK

        Posté par . Évalué à 1.

        Par contre la virtualisation a créé de nouveaux "besoins" (on peut toujours en discuter hein :)), comme par exemple le fait de factoriser ce qui est factorisable entre plusieurs disques différents. Et dans ce cas, c'est bien pratique d'avoir un fichier pour le facteur commun et un fichier "delta" pour les spécificités de chacun.

        Avec LVM, tu peux faire ce genre de chose : tu crées une image générique, et tu crées un snapshot pour chacune de tes VM, tout en restant en raw. En plus, tu peux également faire des snapshots de tes VM avec cette technique.

        En gros, on réutilise ce que propose le système d'exploitation sous-jacent plutôt que la tambouille apportée par l'outil de virtualisation (VMDK pour VMware ou QCow2 pour KVM/Qemu).

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: VMDK

          Posté par (page perso) . Évalué à 2.

          Tu sembles présupposer qu'il y a un système sous-jacent qui puisse exposer LVM, mais ce n'est pas le cas.
          Pour les solutions hosted à la rigueur, mais c'est tout...
          Et même comme ça, avoir une dépendance sur LVM (ou toute autre techno fournissant les mêmes avantages) serait plutôt un frein qu'autre chose.
          À titre perso j'aime bien pouvoir créer ma VM en tant que simple utilisateur, et donc par définition en n'ayant accès à rien de plus profond qu'un bout de filesystem.
          • [^] # Re: VMDK

            Posté par (page perso) . Évalué à 3.

            Enfin, si tu veux un VM performante, tout ne tourne pas en simple utilisateur, trap système, réseau, etc. Ce genre de chose sont parfois cachés dans des sudo ou des binaires suid...

            Personnellement, j'aime bien pour les << serveurs >> la technique de Xen sur debian qui consiste à faire une partition LVM pour chaque partition partition de la machine virtuelle. Ainsi, il n'y a pas de MBR, de table de partition... Il est très facile de réparer une machine virtuelle sur le serveur central.
      • [^] # Re: VMDK

        Posté par . Évalué à 2.

        l'image "raw" serait suffisante pour faire ce que l'on fait avec un disque dur physique: l'associer à une machine.
        Par contre la virtualisation a créé de nouveaux "besoins" (on peut toujours en discuter hein :)), comme par exemple le fait de factoriser ce qui est factorisable entre plusieurs disques différents. Et dans ce cas, c'est bien pratique d'avoir un fichier pour le facteur commun et un fichier "delta" pour les spécificités de chacun.


        En même temps, c'est plus simple d'utiliser la deduplication de ton FS ou de ta baie de stockage, qui est indépendante de ton appli.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.