Ceci est une ancienne révision du document !
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
sudo apt-get install openssh-server
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.
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.
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.
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.
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.
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.
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.
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.