Exporter une VM avec virt-manager

Ayant réussi à faire fonctionner un logiciel privateur (non supporté sur les OS récents) en utilisant Windows XP dans une VM sur KVM, je dois maintenant pérenniser la solution en archivant la VM pour qu’elle puisse être installée sur n’importe quelle machine.

J’ai tout bêtement fait un scp du fichier qcow2 de la VM, mais quand j’essaie de l’importer via le virt-manager de ma machine, elle bloque sur « Booting on hard disk » de SeaBIOS (pas compris pourquoi).
Et si je la boote en UEFI, j’ai un shell, mais pas mon XP qui se lance.

J’ai lu qu’il faut faire un dumpxml de la VM sur la machine d’origine mais ensuite on en fait quoi du fichier xml généré ?
Comment on l’importe dans KVM sur la machine de destination ?
J’ai bien tenté un « define winxp.xml » mais ensuite ça ne me permet pas pour autant de démarrer ma VM.

Ce qui est bizarre c’est que pour un problème pourtant relativement courant j’imagine, je ne trouve rien de clair. Beaucoup de tutos sur comment migrer une VM à chaud dans un hyperviseur, ou sur comment importer telle ou telle image qcow2 spécifique dans KVM, mais rien sur comment déplacer à la main une VM d’une machine à une autre.

J’oubliais, le XML de la machine d’origine indique le chemin du fichier qcow2 sur la machine d’origine (qui n’a pas les mêmes utilisateurs), donc ça ne risque pas de convenir sur la machine de destination…

virsh -c qemu:///system define dumpDeLaMachine.xml

et tu verras la nouvelle machine apparaître dans l’interface de virt-manager
mais comme tu l’a remarqué, il te faudra changer le chemin d’accès au fichier .qcow2


Comme je le fais souvent quand je viens d’installer un nouveau système et que je veux utiliser mes machines virtuelles qui sont dans un système de fichiers séparé mais commun à tous mes systèmes Linux.

Du coup, je recopie tous les fichiers xml de mes machines virtuelles dans un répertoire
et je me suis créé un petit script pour que tous les fichiers soient pris en compte en une seule commande :

#!/bin/bash

# Créer, sans les démarrer, des machines virtuelles
# à partir des fichiers xml

repSrc="."                   # Répertoire dans lequel se trouvent les fichiers .xml
tblXml=( ${repSrc}/*.xml  )  # Créer un tableau-liste des fichiers .xml

for fXml in "${tblXml[@]}"; do
    virsh -c qemu:///system define "${fXml}"
done

Pareil pour créer les dumps :

#!/bin/bash

# pour récupérer les dumps XML
#  des machines virtuelles existantes

for dom in $(awk 'NR >= 3 {print $2}' <<< $(virsh -c qemu:///system list --all)); do
    virsh -c qemu:///system dumpxml "$dom" >> "$dom.xml";
done

et pareil pour les pools :

#!/bin/bash
# todo : activer les pool, et activer au démarrage
# activer aussi network par défaut

# Créer, sans les démarrer, les pools
# à partir des fichiers xml

repSrc="."                   # Répertoire dans lequel se trouvent les fichiers .pool
tblPool=( ${repSrc}/*.pool ) # Créer un tableau-liste des fichiers .pool

for fPool in "${tblPool[@]}"; do
    virsh -c qemu:///system pool-define "${fPool}"
done

Consulte l’aide en ligne des commandes possibles avec la commande virsh car elle est très bien faite, et ça aide beaucoup à comprendre tout ce qu’il est possible de faire en ligne de commande(s)

On en viendrait à oublier d’utiliser l’interface graphique virt-manager :slight_smile:


Par contre, il faudra penser aussi à activer dans le BIOS de la nouvelle machine hôte
la virtualisation ou/et ce qui permettra ce faire du passthrough,
et ils se peut aussi que quelques ports USB ou autres soient à mettre ajour d’une machine à l’autre,
mais bon, c’est du XML, donc c’est vite fait, et puis on peut aussi faire ça avec virt-manager

Ceci dit, il y a bien plus compétent que moi sur ce forum (et sur d’autres aussi) dans ce domaine.

2 J'aime

Ah, j’avais pas compris ce que faisait le « qemu:///system » que je voyais par-ci par-là…
(en fait j’ai toujours pas compris d’ailleurs mais quand je tape la commande en effet je vois la VM dans virt-manager)
(et comme j’ai oublié de modifier le chemin, quand j’ai voulu démarrer la VM en question dans virt-manager ça a éteint l’affichage de tous mes écrans, j’avoue que ça surprend)

Ben en fait même quand je fait la modification du xml j’ai le même problème…

Je me demande si ce n’est pas une question du périphérique Firewire qui est recherché au démarrage et pas trouvé ?

Voici la partie du XML qui parle plus ou moins de PCI, ce serait quoi qui serait à modifier ?

<controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:b5:59:e8'/>
      <source network='default'/>
      <model type='e1000'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>

Dans un premier temps, il te faut vérifier que la nouvelle machine hôte est capable de faire de la virtualisation
ensuite, il faut que cette machine soit aussi capable de faire du passthrough
et enfin, il faudra que les ports PCI et autres de la nouvelle machine hôte
correspondent à ceux qui ont été « récupérés » par ta machine virtuelle.

Avec un seul extrait du fichier xml sans connaître la machine hôte,
on ne pourra pas faire grand chose.

Ma machine accepte la virtualisation, c’est sûr puisque j’ai déjà pas mal de VMs qui tournent.
Je viens de vérifier que la machine de test l’acceptent aussi.
Dans les deux cas, ça ne devrait pas pour autant faire sauter l’affichage…

Il me semble que le pass-through se fait, oui.

Apparemment le FireWire correspondait à cette partie du code XML :

<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
    <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
  </source>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</hostdev>

Donc si je comprends bien, c’est le « bus=‹ 0x01 › » qui permettait de le repérer.

En l’enlevant, démarrer la VM est possible, malheureusement elle bloque sur « Booting on hard disk » de SeaBIOS.

La machine hôte n’a pas encore de carte Firewire intégrée, j’imagine que c’était ça qui faisait sauter l’affichage quand le XML contenait ce Firewire ?

Apparemment quelqu’un a eu le même problème mais sa solution est de refaire sa VM, ce qui n’est pas mon but…

En suivant le lien donné dans le ticket ci-dessus (mais qui concerne uniquement MacOS) il dit que le problème venait de ce que le qcow2 n’était pas attaché à la VM ?
Mais comment ça se fait ?
Aussi bien virt-manager que le XML me disent bien que le disque IDE est le [bon] qcow2…