The idea of migration by emulation assumes the injection of digital objects into their native environments where they can be migrated using environment- and object native applications and the extraction of the resulting migrated objects from the corresponding environments after the process is finished.
The injection/extraction requires the usage of containers (like floppy devices), which could transport digital objects to/from the emulated environments. Currently the floppyImageHelper service within Planets provides with the ability of creating containers in form of floppy image files.
However, in cases when the size of digital objects exceeds the size of standard floppy disks the injection/extraction of the data using them becomes a problem. Even in cases when the objects do not exceed standard floppy disk size the injection/extraction of big amounts of such objects in one turn (i.e. case of unattended large-scale migrations) becomes impossible. In order to overcome this problem the ability of creating containers of arbitrary size should be provided.
Currently we are working on the migrate implementing service, which has a similar mechanism as floppyImageHelper but instead creates HDD image files. Its responsibilities are:
- creating hdd images of a desired capacity and filesystem
- injecting digital objects into the existing hdd image file
- extracting digital objects from the existing hdd image file
Versatile Transport Containers
A hard disk container definitely makes object transport more flexible. As floppy disk containers (in opposite to ISO images) it works both ways: Objects could be mounted to emulation of original environments and modified versions of them could be extracted after shut down. The only downside (which is not an issue in most cases) is that there is no loading and unloading during runtime. Such a service should cope with the different container file types of QEMU, Virtual Box, … and others. In most cases a simple FAT filesystem is sufficient but for non-X86 architectures other filesystems and container layouts might be required. But those could be implemented through a similar service (if this could not be added to this one). For unidirectional service an ISO creating service might be a simpler solution as ISOs are understood by many different emulators.
OVF
Hello,
In my work with developing virtualization solutuions for digital preservation, I have found that saving virtual machines in the Open Virtualization (OVF) format to be extremely helpful. OVF was created to be a cross platform standard and is recognized by VirtualBox, VMware, AbiCloud, and IBM POWER server AIX, Linux z/VM, IBM Systems Director
My standard practice is to now save a copy of my virtual machines in VMX, OVF, and ISO formats.
Regards,
MB