Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue110:clonezilla_virtualbox [2016/06/30 11:34] – créée andre_domenech
+++ issue110:clonezilla_virtualbox [2016/07/09 17:18] (Version actuelle) – auntiee
@@ Ligne 1: / Ligne 1: @@
-Virtual execution environments such as Virtualbox, VMWare and others have long been a boon for users who wish to try out a new GNU/Linux distribution. Not everybody has a spare machine lying around that can be used as a testbed. Even for those who do, the test computer may already be taken up by another project. One possible strategy could be the creation of various partitions that share a single computer’s hard drive. But this approach also has its dangers, especially when testing distributions that one does not know well yet: not all installers work in the same way, and accidents do happen. When they do, partitions may be deleted, reformatted, or the system rendered inoperative due to a borked boot-loader. In a virtual environment, on the other hand, an installation that goes wrong will have no effect on the computer’s host operating system. At worst, the virtual machine is deleted along with all its files, and the cost in terms of the owner’s time and effort is minimal.
+**Virtual execution environments such as Virtualbox, VMWare and others have long been a boon for users who wish to try out a new GNU/Linux distribution. Not everybody has a spare machine lying around that can be used as a testbed. Even for those who do, the test computer may already be taken up by another project. One possible strategy could be the creation of various partitions that share a single computer’s hard drive. But this approach also has its dangers, especially when testing distributions that one does not know well yet: not all installers work in the same way, and accidents do happen. When they do, partitions may be deleted, reformatted, or the system rendered inoperative due to a borked boot-loader. In a virtual environment, on the other hand, an installation that goes wrong will have no effect on the computer’s host operating system. At worst, the virtual machine is deleted along with all its files, and the cost in terms of the owner’s time and effort is minimal.**
-However, once a distribution has been successfully installed and we find that we actually like it, it begs the question of how to transfer the resulting system to an actual computer. Going once more through the complete installation process on the physical hardware seems a waste of time, and perhaps also of bandwidth – if new software packages have already been downloaded once to update the virtual machine. It would perhaps be more logical to somehow transfer the contents of the virtual machine’s hard drive to the actual computer. This article explores one way of doing this - a way that does not require a degree in computer systems administration to carry out.
+Les environnements d’exécution virtuels, Virtualbox, VMWare et autres, sont depuis longtemps une aubaine pour les utilisateurs qui souhaitent tester de nouvelles distributions GNU/Linux. Tout le monde ne dispose pas d’une machine supplémentaire qui puisse servir de banc d’essai et, même chez ceux dont c’est le cas, la machine de test peut être mobilisée par un second projet. Une stratégie envisageable est la création de plusieurs partitions qui permettent le partage du disque dur d’un unique ordinateur. Mais cette approche comporte également des dangers, particulièrement quand on teste une distribution que l’on connaît mal : tous les installeurs ne fonctionnent pas de la même façon et des accidents peuvent se produire. Dans ce cas, des partitions peuvent être effacées, reformatées, ou le système peut être rendu inopérant par un bootloader défectueux. En revanche, dans un environnement virtuel, une installation qui se passe mal n’aura aucun effet sur le système d’exploitation de la machine hôte. Au pire, la machine virtuelle est détruite avec tous ses fichiers et le coût en termes de temps et d'efforts du propriétaire reste minimum.
-I will be using Virtualbox as a virtual machine, both because it is already in the Ubuntu repositories and because it actually works quite well. On the client side, I will be using Ubuntu 16.04 for the amd64 architecture. Since most computers sold in the last several years now have 64-bit architectures, to my mind there remain few reasons to choose the 32-bit (“i386”) versions of Ubuntu - although there will be a caveat on this aspect later on. For now, let us set up a new 64-bit virtual machine within Virtualbox. 1 GByte of RAM is about as low as one can go to install Xenial, so that is the amount we will specify for the virtual machine. Needless to say, our host computer will need to have at the very least 2 GBytes of physical RAM, one to give to the virtual machine, and another for its own needs.
+**However, once a distribution has been successfully installed and we find that we actually like it, it begs the question of how to transfer the resulting system to an actual computer. Going once more through the complete installation process on the physical hardware seems a waste of time, and perhaps also of bandwidth – if new software packages have already been downloaded once to update the virtual machine. It would perhaps be more logical to somehow transfer the contents of the virtual machine’s hard drive to the actual computer. This article explores one way of doing this - a way that does not require a degree in computer systems administration to carry out.**
-As for the hard drive, Virtualbox suggests creating an 8 GByte volume, based on the name of the distribution to be installed. This virtual hard drive will, in fact, be contained within a single file on the host system. Since the file is a sparse hard drive, only sectors that actually contain data will be recorded, so the file itself will take up rather less space than the full 8 GBytes given. As a reference, a recent Ubuntu freshly installed should use between 4 and 5 GBytes.
+Quoi qu’il en soit, une fois qu’une distribution a été installée et qu’elle s’avère satisfaisante, se pose la question de son transfert sur un ordinateur réel. Passer à nouveau par tout le processus d’installation sur le matériel physique semble une perte de temps et de bande passante (si de nouveau paquets logiciels ont déjà été chargés pour mettre à jour la machine virtuelle). Il serait sans doute plus logique de transférer le contenu du disque dur de la machine virtuelle sur celui de la véritable machine. Cet article explore une manière de procéder, une manière qui ne nécessite pas une formation d’administrateur système pour être utilisée avec succès.
+**
+I will be using Virtualbox as a virtual machine, both because it is already in the Ubuntu repositories and because it actually works quite well. On the client side, I will be using Ubuntu 16.04 for the amd64 architecture. Since most computers sold in the last several years now have 64-bit architectures, to my mind there remain few reasons to choose the 32-bit (“i386”) versions of Ubuntu - although there will be a caveat on this aspect later on. For now, let us set up a new 64-bit virtual machine within Virtualbox. 1 GByte of RAM is about as low as one can go to install Xenial, so that is the amount we will specify for the virtual machine. Needless to say, our host computer will need to have at the very least 2 GBytes of physical RAM, one to give to the virtual machine, and another for its own needs.**
-Now, for the caveat on 64-bit versus 32-bit systems. I am executing this virtual machine on a physical computer with a processor that has the VT-x technology included in its CPU (an Intel Core i5). This is needed in order to execute a 64-bit virtual computer. On a physical computer with just about any of the current low-cost CPUs - such as the Atom or Centrino - the required technology is not available within the processor, and 64-bit virtual machines cannot be executed. In this case, simulating a 32-bit system may be a viable alternative, especially if the end target is to set up a lower-end computer. Simply specify an Ubuntu 32-bit system when setting up Virtualbox, and use an ISO image with the i386 architecture suffix.
+Je vais me servir de Virtualbox comme machine virtuelle, à la fois parce qu’il est déjà présent dans les dépôts Ubuntu et parce qu’il marche très bien. Côté client je vais utiliser Ubuntu 16.04 pour architecture AMD64. Comme la plupart des ordinateurs vendus ces dernières années sont des 64-bit, il y a, selon moi, peu de raisons de choisir une version 32-bit d’Ubuntu (« i386 ») — même si plus loin je consacre une mise en garde à ce sujet. Pour l’instant, paramétrons une nouvelle machine virtuelle de 64-bit dans Virtualbox : un Go de RAM est à peu près le minimum que l’on puisse utiliser pour installer Xenial, c’est donc la quantité que nous spécifierons pour notre machine virtuelle. Il va sans dire que notre ordinateur hôte aura besoin d’au moins deux Go de RAM : un pour la machine virtuelle et un pour ses propres besoins.
+**As for the hard drive, Virtualbox suggests creating an 8 GByte volume, based on the name of the distribution to be installed. This virtual hard drive will, in fact, be contained within a single file on the host system. Since the file is a sparse hard drive, only sectors that actually contain data will be recorded, so the file itself will take up rather less space than the full 8 GBytes given. As a reference, a recent Ubuntu freshly installed should use between 4 and 5 GBytes.**
+Quant au disque dur, en se basant sur le nom de la distribution qui sera installée, Virtualbox suggère la création d’un volume de 8 Gbytes. Ce disque dur virtuel sera en fait représenté par un fichier unique sur le système hôte. Comme ce disque est mince, seuls les secteurs qui contiennent effectivement des données seront enregistrés et le fichier lui-même occupera donc moins d’espace que les 8 GBytes initialement réservés. Une distribution récente d’Ubuntu fraîchement installée occupera entre 4 et 5 Go.
+**Now, for the caveat on 64-bit versus 32-bit systems. I am executing this virtual machine on a physical computer with a processor that has the VT-x technology included in its CPU (an Intel Core i5). This is needed in order to execute a 64-bit virtual computer. On a physical computer with just about any of the current low-cost CPUs - such as the Atom or Centrino - the required technology is not available within the processor, and 64-bit virtual machines cannot be executed. In this case, simulating a 32-bit system may be a viable alternative, especially if the end target is to set up a lower-end computer. Simply specify an Ubuntu 32-bit system when setting up Virtualbox, and use an ISO image with the i386 architecture suffix.**
+Et maintenant, notre mise en garde concernant les systèmes 32 et 64-bit. J’utilise cette machine virtuelle sur un ordinateur physique dont le processeur (un Intel Core i5) embarque la technologie VT-x. Cela est indispensable pour faire tourner une machine virtuelle de 64-bit. Sur une machine munie d’un processeur bon marché (comme un Atom ou un Centrino) la technologie requise n’est pas disponible et les machines virtuelles de 64-bit ne peuvent donc pas fonctionner. Dans ce cas, simuler un système de 32-bit peut être un choix judicieux, particulièrement si la machine cible est un ordinateur bon marché. Choisissez simplement Ubuntu 32-bit au moment de paramétrer votre machine virtuelle et utilisez une image ISO dont le nom contient le suffixe « i386 ».
+**
 Another point that may be useful when setting up the virtual machine is to tell Virtualbox to use 3D acceleration techniques; in essence, we are telling it to emulate a relatively modern GPU, instead of a basic model. This is because I am setting up a desktop system. If, on the other hand, one was to set up a server system that will not need a graphical interface, this step can be omitted.
-At this point, we have a working virtual machine set up. To install Ubuntu, we will just need to connect the boot ISO image as a virtual CD-ROM unit. I tend to use the default settings – which is to emulate an IDE unit. Setting the CD reader up as a SATA unit is certainly possible, but gives no benefit in terms of speed - since this is all a virtual environment that depends only on the speed of the underlying host computer.
+At this point, we have a working virtual machine set up. To install Ubuntu, we will just need to connect the boot ISO image as a virtual CD-ROM unit. I tend to use the default settings – which is to emulate an IDE unit. Setting the CD reader up as a SATA unit is certainly possible, but gives no benefit in terms of speed - since this is all a virtual environment that depends only on the speed of the underlying host computer.**
+Un autre choix utile au moment de ce paramétrage est de demander à VirtualBox d’utiliser l’accélération 3D. Cela permet d’émuler un processeur graphique plutôt moderne au lieu d’un modèle basique. Ceci parce que je prépare un système de bureau. Si, par contre, vous souhaitez mettre en place un serveur dépourvu d’interface graphique, vous pouvez ignorer cette étape.
+À ce stade nous disposons d’une machine virtuelle fonctionnelle. Pour installer Ubuntu, il nous suffira d’y connecter l’image ISO bootable en tant que lecteur CD-ROM virtuel. J’ai tendance à utiliser le réglage par défaut qui émule un lecteur IDE. On peut, bien sûr, définir ce lecteur comme périphérique SATA, mais cela n’apporte aucun bénéfice en termes de rapidité, puisque nous sommes dans un environnement virtuel dont les performances ne dépendent que de celles de la machine hôte.
+**
 We can now boot the virtual machine, and if all goes well, we should get the Live CD running within a new window. It can be useful to observe the status bar at the bottom, which allows us to monitor the presence of disk and network activity.
-Testing the new distribution, and installation on to the virtual hard drive, take place as usual. In this case, we will be installing it onto the virtual drive. The Installer application works as usual, within the virtual machine’s window. We will tell the installer to update the new system during installation, so we end up with an up-to-date state that can then be replicated on the target system.
+Testing the new distribution, and installation on to the virtual hard drive, take place as usual. In this case, we will be installing it onto the virtual drive. The Installer application works as usual, within the virtual machine’s window. We will tell the installer to update the new system during installation, so we end up with an up-to-date state that can then be replicated on the target system.**
+Nous pouvons maintenant démarrer la machine virtuelle et, si tout se passe bien, nous verrons une session live s’ouvrir dans une nouvelle fenêtre. Il peut être intéressant d’observer la barre d’état en bas : elle permet de vérifier la présence du disque et de contrôler l’activité réseau.
+Les tests et l’installation de la nouvelle distribution sur le disque dur virtuel se déroulent comme de coutume. L’installeur fonctionne comme d’habitude dans la fenêtre de la machine virtuelle. Nous lui demanderons d’effectuer les mises à jour du système pendant l’installation, comme cela nous obtiendrons un système prêt à être recopié sur la machine cible.
+**
 The 8 GByte hard drive will be sufficient for our needs. A single ext4 partition will be used for this example, though more complex layouts with separate /home and swap partitions may certainly be envisioned. The virtual drive is detected by the Ubuntu installer as “VBOX HARDDISK”, with the correct size. The small discrepancy is due to the use of 8 GBytes on the Virtualbox size (8 times 2^30 bytes), while the Ubuntu installer sees the same amount of bytes as 8.6 GBytes (8.6 times 10^9 bytes).
 The installation process is identical to that seen on a physical machine. We will see some network activity while the updated packages are pulled down from the repositories. The virtual machine is seamlessly using the host computer’s network connection, through a small virtual router set up within Virtualbox.
-Once installed, the new system can be rebooted, and configured to taste. We will be going for a colder look, and less icons cluttering up the Unity dock. Though I do like to set up multiple desktops.
+Once installed, the new system can be rebooted, and configured to taste. We will be going for a colder look, and less icons cluttering up the Unity dock. Though I do like to set up multiple desktops.**
-We now have a useful system populating our virtual machine. This is what we try out and tweak to our tastes. Once we are satisfied with the result, we need to find a way to clone it into our target computer. Several options are available to do this. For instance, we can take the VDI file of our virtual hard drive, and decompress it into a directory. The files would then need to be transferred to the target computer over some type of network connection. But, since we will need to do the network connection in any case, it may be less complex to directly use a network-oriented tool to make a copy of the virtual system. This is where Clonezilla comes in.
+Le disque dur de 8 Go suffira à nos besoins. Une seule partition ext4 sera utilisée pour notre exemple, même si des partitionnements plus complexes, avec un /home et un /swap séparés, peuvent être envisagés. Le disque virtuel est détecté par l’installeur d’Ubuntu comme « VBOX HARDDISK » avec la bonne taille. La petite différence est due à l’usage des Gbytes par Virtualbox (8 × 2^30 bytes) alors que l’installeur voit la même capacité comme 8,6 Gbytes (8,6 × 1^09 bytes).
-Clonezilla is a Live CD build upon either a version of Debian or of Ubuntu, by the National Center for High Performance Computing in Taiwan. It allows us to boot up the system to be cloned and then make a copy or image of its hard drive. In this case, we will be working on our virtual machine, but a clone of a physical computer can also easily be made. Once the image has been made and stored on a network server, the target computer can also be booted up from Clonezilla, and the image “restored” to the target hard drive, in essence making an identical clone of one computer onto the other. I downloaded the “alternative stable” version of Clonezilla, based on Ubuntu Wily, from the project web page http://clonezilla.org/downloads.php . This is a relatively small (235 MByte) download, since it contains only the base system and the actual Clonezilla software that works without a need for a graphical environment.
+Le processus d’installation est identique à celui d’une machine réelle. Nous constaterons une activité réseau quand les paquets seront chargés depuis les dépôts. La machine virtuelle utilise de manière transparente la connexion de la machine hôte via un petit routeur virtuel inclus dans Virtualbox.
-We will now halt our new virtual machine, connect the Clonezilla ISO file as the CD unit, and reboot. The GRUB interface is perhaps not as polished as Ubuntu’s, but it is functional.
+Une fois installé, le nouveau système peut être redémarré, puis paramétré suivant les goûts de chacun. Nous rechercherons une apparence plus neutre avec moins d’icônes se bousculant dans le dock d’Unity, même si j’aime paramétrer des bureaux multiples.
+**We now have a useful system populating our virtual machine. This is what we try out and tweak to our tastes. Once we are satisfied with the result, we need to find a way to clone it into our target computer. Several options are available to do this. For instance, we can take the VDI file of our virtual hard drive, and decompress it into a directory. The files would then need to be transferred to the target computer over some type of network connection. But, since we will need to do the network connection in any case, it may be less complex to directly use a network-oriented tool to make a copy of the virtual system. This is where Clonezilla comes in.
+**
+Nous avons maintenant un système utilisable sur notre machine virtuelle. Nous le testons et l’adaptons à nos préférences. Une fois satisfaits du résultat, nous devons trouver un moyen de le cloner sur l’ordinateur cible. Plusieurs solutions sont envisageables. Nous pouvons par exemple prendre le fichier VDI qui correspond à notre disque dur virtuel et le décompresser dans un répertoire. Les fichiers devront ensuite être transférés vers la cible via une connexion réseau. Mais comme nous devrons de toute façon établir cette connexion, il sera sans doute plus facile d’utiliser directement un outil orienté réseau pour effectuer la copie du système virtuel. C’est là qu’intervient Clonezilla.
+**Clonezilla is a Live CD build upon either a version of Debian or of Ubuntu, by the National Center for High Performance Computing in Taiwan. It allows us to boot up the system to be cloned and then make a copy or image of its hard drive. In this case, we will be working on our virtual machine, but a clone of a physical computer can also easily be made. Once the image has been made and stored on a network server, the target computer can also be booted up from Clonezilla, and the image “restored” to the target hard drive, in essence making an identical clone of one computer onto the other. I downloaded the “alternative stable” version of Clonezilla, based on Ubuntu Wily, from the project web page http://clonezilla.org/downloads.php . This is a relatively small (235 MByte) download, since it contains only the base system and the actual Clonezilla software that works without a need for a graphical environment.**
+Clonezilla est un Live CD, basé soit sur Debian, soit sur Ubuntu. Il est proposé par le National Center for High Performance Computing de Taiwan. Il permet de booter le système à cloner, puis de réaliser une image de son disque dur. Dans ce cas, nous travaillerons à partir de notre machine virtuelle, mais un clone d'ordinateur physique peut aisément être réalisé. Une fois cette image stockée sur un serveur réseau, la machine cible peut également être bootée avec Clonezilla et l’image être « restaurée » vers son disque dur, ce qui revient à cloner une machine à l’identique vers une autre machine. J’ai téléchargé la version « alternative stable » de Clonezilla, basée sur Ubuntu Wily, à l’adresse  http://clonezilla.org/downloads.php. C’est un téléchargement relativement léger (235 Mo) puisqu’il ne contient qu’un système de base et le logiciel Clonezilla lui-même, qui fonctionne sans nécessiter d’environnement graphique.
+**We will now halt our new virtual machine, connect the Clonezilla ISO file as the CD unit, and reboot. The GRUB interface is perhaps not as polished as Ubuntu’s, but it is functional.
 We will be storing our cloned image file on a network server. Perhaps the easiest option is to set up SSH on one of our computers, for example on the very same physical host on which the virtual machine is running. This SSH service allows one not only to access the computer from within a terminal across the network, but also to transfer files to and from our hard drive. If there is not yet an SSH server running on our host machine, OpenSSH can easily be installed from the repositories using a single command:
@@ Ligne 33: / Ligne 65: @@
 sudo apt-get install openssh-server
-The server will be installed and started up immediately.
+The server will be installed and started up immediately.**
-We can now get back to Clonezilla, and configure our host’s SSH service as the location of our cloned images. As you can see, if you prefer another type of disk-sharing service, this is also available. For instance, an existing Windows share can be accessed through SAMBA.
+Éteignons maintenant notre nouvelle machine virtuelle, connectons le fichier ISO de Clonezilla comme lecteur CD et rebootons. L’interface de GRUB n’est peut-être pas aussi élégante que celle d’Ubuntu, mais elle est fonctionnelle.
+Nous stockerons notre fichier image sur un serveur réseau. Le plus simple est peut-être de paramétrer le SSH sur l’un de nos ordinateurs, par exemple sur celui-là même qui sert d’hôte à notre machine virtuelle. Ce service SSH nous autorise non seulement à accéder à la machine en ligne de commande à travers le réseau, mais aussi à transférer des fichiers vers et depuis son disque dur. S’il n’y a pas encore de serveur SSH sur la machine hôte, OpenSSH peut être installé facilement à partir des dépôts grâce à la commande :
+sudo apt-get install openssh-server
+Le serveur sera installé et immédiatement démarré.
+**We can now get back to Clonezilla, and configure our host’s SSH service as the location of our cloned images. As you can see, if you prefer another type of disk-sharing service, this is also available. For instance, an existing Windows share can be accessed through SAMBA.
 The virtual machine is connected to its host using a NAT virtual connection. The host computer is seen from the virtual machine through private IP address 10.0.2.2, while the virtual machine uses address 10.0.2.15. Clonezilla has seen this and proposes the host’s address as default for the SSH server.
-When creating the SSH connection, a normal user on the SSH server can be used. A directory that exists and that the user can write to must be specified, for example a subdirectory within their home directory.
+When creating the SSH connection, a normal user on the SSH server can be used. A directory that exists and that the user can write to must be specified, for example a subdirectory within their home directory.**
-We now get to the business part of Clonezilla. We choose to create a new image from our virtualbox hard drive. The easiest option is to choose the complete unit as a basis for the copy. If desired, each individual partition can be cloned, although the process is more difficult and should be reserved for more complex installation layouts.
+Nous pouvons maintenant revenir à Clonezilla et désigner le service SSH de notre hôte comme destination de notre image clonée. Comme vous pouvez le voir, si vous préférez un autre type de partage, c’est également possible. Un partage Windows existant peut, par exemple, être accessible avec SAMBA.
-This is about it. Now Clonezilla accesses the host drive through SSH, and creates and verifies the disk image. It may not really be necessary to verify the image; if the verification stage is omitted, quite some time can be saved.
+La machine virtuelle est connectée à son hôte via une connexion virtuelle NAT. La machine virtuelle voit la machine hôte à l’IP privée 10.0.2.2, alors qu’elle-même utilise l’adresse 10.0.2.15. Clonezilla l’a détecté et propose par défaut l’adresse de l’hôte comme serveur SSH.
-As a side-note, the cloning process may be found to be rather slow. This is mostly due to the virtual network connection from Virtualbox. One way of making the cloning process a tad faster is by configuring our virtual machine to use a “Bridged Adapter” connection, instead of the default “NAT” connection. However, in this case the user must determine the host (server’s) IP address, for instance with the ifconfig command.
+Quand vous créez la connexion SSH, un utilisateur normal peut être utilisé sur le serveur SSH. Un répertoire existant et accessible en écriture par cet utilisateur doit être spécifié, par exemple un sous-répertoire situé dans le /home.
-Making a clone from a physical computer is generally much faster, as is restoring to our target (physical) computer. This is the next - and final - phase of the process. The target computer must be booted from Clonezilla, so a physical CD must be prepared, or the ISO file written to a USB stick in the usual manner. Once the target computer is up and running Clonezilla, the steps are the very same used to create the image. The only differences are:
+**We now get to the business part of Clonezilla. We choose to create a new image from our virtualbox hard drive. The easiest option is to choose the complete unit as a basis for the copy. If desired, each individual partition can be cloned, although the process is more difficult and should be reserved for more complex installation layouts.
+This is about it. Now Clonezilla accesses the host drive through SSH, and creates and verifies the disk image. It may not really be necessary to verify the image; if the verification stage is omitted, quite some time can be saved.**
+Nous allons maintenant passer aux choses sérieuses avec Clonezilla. Nous choisissons de créer une nouvelle image à partir du disque dur de notre machine virtuelle. L’option la plus simple consiste à choisir le lecteur entier comme base de la copie. Si vous le désirez, les partitions peuvent être clonées individuellement, mais le processus est plus compliqué et devrait être réservé à des installations plus élaborées.
+C’est à peu près tout. Maintenant Clonezilla accède au disque dur de la machine hôte via SSH pour y copier puis vérifier l’image du disque virtuel. L’étape de vérification peut éventuellement être omise, ce qui fera gagner beaucoup de temps.
+**As a side-note, the cloning process may be found to be rather slow. This is mostly due to the virtual network connection from Virtualbox. One way of making the cloning process a tad faster is by configuring our virtual machine to use a “Bridged Adapter” connection, instead of the default “NAT” connection. However, in this case the user must determine the host (server’s) IP address, for instance with the ifconfig command.**
+Notez que le clonage pourra vous paraître plutôt lent. Cela est principalement dû à la connexion virtuelle de Virtualbox. Une façon de rendre l’opération un poil plus rapide est de configurer la machine virtuelle pour qu’elle utilise une connexion « Bridge Adapter » au lieu de NAT. Dans ce cas, l’utilisateur devra déterminer lui-même l’adresse IP de l’hôte (le serveur) en utilisant, par exemple, la commande ifconfig.
+**Making a clone from a physical computer is generally much faster, as is restoring to our target (physical) computer. This is the next - and final - phase of the process. The target computer must be booted from Clonezilla, so a physical CD must be prepared, or the ISO file written to a USB stick in the usual manner. Once the target computer is up and running Clonezilla, the steps are the very same used to create the image. The only differences are:
 Configure Clonezilla to use the local network IP address of the SSH server, which will usually be something similar to 192.168.0.102 or 192.168.1.103.
-Instead of running the savedisk command, we will use restoredisk.
+Instead of running the savedisk command, we will use restoredisk.**
-Clonezilla will connect to the SSH server specified, and show a list of the saved images found on that server. We will simply choose the image required, and then the local hard drive to write it to.
+Obtenir un clone à partir d’un ordinateur physique est généralement plus rapide, tout comme la restauration vers notre machine cible physique. C’est l’étape suivante, et la dernière, de notre démarche. L’ordinateur cible doit être booté avec Clonezilla, il faut donc graver un CD réel ou écrire le fichier ISO sur une clef USB selon la méthode habituelle. Une fois que la cible est démarrée et qu’elle tourne sous Clonezilla, les étapes sont les mêmes que lors de la création de l’image. Les seules différences sont :
+Configurez Clonezilla en utilisant l’adresse IP locale du serveur SSH, qui est généralement similaire à 192.168.0.102 ou à 192.168.0.103.
+Au lieu d’utiliser la commande savedisk, nous utiliserons restoredisk.
+**Clonezilla will connect to the SSH server specified, and show a list of the saved images found on that server. We will simply choose the image required, and then the local hard drive to write it to.
 Once the image has been copied over, Clonezilla knows that a bootloader is required to make the new system bootable. It knows about GRUB 2 used in Ubuntu systems, and can detect and install the bootloader without any further ado.
-The new computer can then be stopped, the Clonezilla medium removed, and the computer rebooted. If all goes well, the system should come up and be indistinguishable from the way the virtual machine was set up.
+The new computer can then be stopped, the Clonezilla medium removed, and the computer rebooted. If all goes well, the system should come up and be indistinguishable from the way the virtual machine was set up.**
+Clonezilla se connectera au serveur SSH spécifié et affichera une liste des images disponibles sur celui-ci. Nous choisirons simplement l’image que nous souhaitons, puis le disque dur local où elle devra être écrite.
+Une fois l’image recopiée, Clonezilla tiendra compte du fait qu’un bootloader est nécessaire pour rendre le nouveau système amorçable. Il gère GRUB 2, utilisé par les systèmes Ubuntu, et peut le détecter et l’installer sans la moindre formalité.
+Le nouvel ordinateur peut alors être éteint, le support de Clonezilla enlevé et l'ordinateur redémarré. Si tout se passe bien, le système devrait fonctionner et sa configuration devrait être identique à celle de la machine virtuelle.
+**
 Now, for some final notes.
-In this article, I made a clone of a single partition that took up the complete virtual hard drive. Since most physical computers will have a hard drive with more than 8 GBytes of capacity, the clone will end up with a first partition (/dev/sda1) of this size, leaving a large part of the hard drive free for other uses.
+In this article, I made a clone of a single partition that took up the complete virtual hard drive. Since most physical computers will have a hard drive with more than 8 GBytes of capacity, the clone will end up with a first partition (/dev/sda1) of this size, leaving a large part of the hard drive free for other uses.**
+Quelques dernières remarques.
+Dans cet article, j’ai cloné une partition unique qui occupait la totalité du disque dur virtuel. Comme la plupart des ordinateurs ont un disque dur d’une capacité bien supérieure à 8 Go, le clonage résultera en une première partition de cette taille (/dev/sda1) et laissera une grande partie du disque disponible pour d’autres usages.
+**This space can be reclaimed through several strategies. One could extend /dev/sda1 to take up more space. It would, in fact, be preferable if more or larger programs will need to be installed in our new system. This can be done using the gnome-disks - though the partition will need to be unmounted before resizing, which means the target computer must be booted from a Live CD or similar to perform this task. Alternatively, command-line tools such as resize2fs can also do the job, but do require familiarity with command-line system administration and may be outside of many users’ comfort zone.**
+Cet espace peut-être récupéré de différentes manières. L’une serait d’agrandir /dev/sda1 pour qu’elle occupe plus de place. C’est en fait ce qui serait préférable si vous prévoyez d’installer un ou plusieurs programmes volumineux sur votre nouveau système. Cela peut être fait en utilisant le gnome-disks. La partition devra être démontée avant le redimensionnement, ce qui signifie que l’ordinateur devra être booté depuis un Live CD, ou équivalent, pour s’acquitter de cette tâche. Des outils en ligne de commande comme resize2fs feront également l’affaire, mais ils exigent d’être familiarisés à l’administration système avec un terminal et peuvent s’avérer délicats pour l’utilisateur novice.
-This space can be reclaimed through several strategies. One could extend /dev/sda1 to take up more space. It would, in fact, be preferable if more or larger programs will need to be installed in our new system. This can be done using the gnome-disks - though the partition will need to be unmounted before resizing, which means the target computer must be booted from a Live CD or similar to perform this task. Alternatively, command-line tools such as resize2fs can also do the job, but do require familiarity with command-line system administration and may be outside of many users’ comfort zone.
+**If a larger root partition is not required for the new system itself, an alternative approach would be to use the free space to set up a second partition and configure that for the /home directory. This will be the subject of a further article at a later time.**
-If a larger root partition is not required for the new system itself, an alternative approach would be to use the free space to set up a second partition and configure that for the /home directory. This will be the subject of a further article at a later time.
+Si le nouveau système n’a pas besoin d’une partition root plus grande, une solution est d’utiliser l’espace libre pour créer une seconde partition qui tiendra lieu de répertoire /home. Cela sera l’objet d’un prochain article.