Arik Hadas

How many times did you need to start a virtual machine and either provide it with a directory on the host or use some file-sharing service (e.g., dropbox) or your email, just to copy a resource that resides within the virtual disk? In this session, Arik presents the upcoming integration between the muCommander file-manager and libguestfs. This produces an alternative to that complex process by enabling to browse/copy-from/copy-to various virtual disk formats directly using a user-friendly interface. Come to see the planned functionality and hear about the technical complexity of this integration.

muCommander is an open source cross-platform file manager that supports a variety of file formats (e.g., zip, tar) and file protocols (e.g., sftp, smb). These days muCommander is extended with a pluggable framework to ease the process of supporting more file formats and protocols.

This session focuses on a specific plugin for virtual disks. The plugin wraps the libguestfs library that provides an API for accessing and modifying various formats of virtual disks, such as vmdk and qcow. Libguestfs is a powerful library that is used by a variety of tools, e.g., the conversion utility virt-v2v. However, libguestfs lacks a user-friendly interface for those who wish to inspect and modify virtual disks as ordinary archive files. The plugin for muCommander aims to provide that via a dual-pane graphical interface.

The on-going development of this plugin exposes some of the complexity of integrating virtual disks, and libguestfs in particular, into a file-manager. For instance, unlike ordinary archive files, the operating system needs to be inspected in order to produce the tree structure of the file system(s). As another example, muCommander uses a stream based approach to copying files while libguestfs assumes local files or standard input/output. This session would cover not only the functional side of the integration, that will be demonstrated with images that resides on oVirt's storage domains, but also interesting sides of its implementation.

Suppose you want to import virtual machines you already have into oVirt to enjoy a features-rich open sourced management system. You will soon figure out that the conversion of virtual machines running on different hypervisors or managed by different management systems into oVirt is not an easy task. The next major version of oVirt is going to introduce an integrated process that will simplify import of virtual machines not being managed by oVirt into oVirt. This session gives a heads up for the feature: we will go over the design and see how it solves issues that we had before to provide better way for import virtual machines to oVirt.

Until now from oVirt one could only import virtual machines (VMs) that were managed once by oVirt, either VMs that were exported from oVirt or VMs that reside on storage that was attached once to oVirt. In order to import VMs that run on different hypervisors or managed by different tools/management solutions, one had to use external tool, such as virt-v2v, separately to convert the VMs so they will fit to oVirt and then import the VMs from oVirt. This results in a slow, tedious and error-prone process. An important feature in oVirt 3.6 is going to be the extension of import VMs capabilities to provide users with a process that is integrated within oVirt web-admin ui for import VMs from external environments, i.e VMs that run on different hypervisors and managed by different management solutions. We produce a process based on integration with virt-v2v, for import such VMs to oVirt which is better in terms of usability, performance and monitoring. The new process will ease migration of existing VMs into oVirt, encouraging people to have their existing virtual environments replaced with oVirt. In this session we will analyse the problems with the previous process, go over the design of the new one and see how it address the problems we used to have, producing a better way for migrate existing virtual environments to open source virtualization platform.