If you ever thought of uploading your local VMs to OpenStack, perhaps you have come across OpenStack’s support for importing single virtual disk images. However, this cannot be used to deploy complicated VM setups, including network configurations and multiple VMs connected to each other.
We at ICCLab have therefore decided to develop a tool that will allow anyone to upload their VM setups from their local environments directly to OpenStack. We call it OpenStack VM onboarding tool and it’s available as open source.
VM onboarding tool features:
- Easy to run – the tool comprises of simple frontend, backend and Openstack client libraries to access Openstack APIs. All these components can be easily run with one command.
- Easy to Import – to import an OVA file the user needs to provide only the basic Openstack credentials (username, password, tenant, region, keystone URL) and an OVA file.
- Full infrastructure import – the tool imports virtual machines, external networks, internal network connections and security groups.
You can check out a quick demo of VM onboarding functionality, workflow and interface.
The tool comprises of simple frontend, backend and Openstack client libraries to access Openstack APIs. The figure below shows a high level architecture of this tool.
Once a user tries to “Log in”, a new session is created through “keystoneauth” library. This session is needed to access all openstack client services.
Import OVA file to Openstack consists of different actions:
- Chosen the OVA file uploaded to the backend server
- OVA file transforms into the simple .tar archive. The images (vmdk) and the OVF file are extracted from this archive disk.
- The OVF file parser extracts valid information.
- The images are uploaded to the glance endpoint.
- All information then transforms to the heat template and is uploaded to the heat client.
In future VM onboarding tool will be integrated with the Openstack Horizon dashboard for seamless user experience.
There’s also virt-v2v [1], which is part of libguestfs, and it’s actively developed and used in production already. Among the input options there’s also OVA (not to mention the possibility to connect to vCenter directly), and among the output options there’s also Glance. virt-v2v is used also by oVirt / RHV for importing guests from VMware.
virt-v2v, like the rest of libguestfs, is GPL v2+ already (since its beginning), and we welcome contributions of any kind (for example, recently Virtuozzo people contributed various improvements for the v2v conversion of Windows guests).
What do you think about making use of virt-v2v?
[1] http://libguestfs.org/virt-v2v.1.html
Ping? Any ideas/concerns about what I wrote few days ago?
Good day Pino! Glad to hear that you are interested in our tool. I am very sorry for the very late answer.
Our team took a look on virt-v2v and we found this tool very powerful and well developed but unfortunately we don’t think that it would fit our goal perfectly.
First of all the vmdk support is already implemented in Glance and there are no needs to convert an image.
Second reason that VM onboarding tool is basically a tool to import whole virtual infrastructure(security groups, networks, etc) through heat client, while virt-v2v is just a image uploader through glance client.
And third reason that virt-v2v has only VMware support and our tool is developed to support all software platforms.
due to the above reasons, we do not believe that the implementation of the VM onboarding tool by the virt-v2v is inexpedien
Hi serh,
I’d like to reply to your points, since there seems to be some misunderstanding about what virt-v2v is and does.
1) Glance supports also standard raw and qcow2, and if you are using KVM as hypervisor for OpenStack then raw & qcow2 are much better options compared to vmdk (especially in qemu)
2) no, virt-v2v is not just a “image uploader”: it also takes care to adapt the guest so it can run better on the destination hypervisor. Operations done include: removing of drivers used to run in the source hypervisor (so vmware tools, in case of VMware), on Windows installation of virtio drivers, on Linux selection of the proper kernel to boot, and so on.
3) no, virt-v2v can:
– import from existing OVA
– import from a local disk image
– import from a libvirt instance
– import from Xen (RHEL 5 Xen and SUSE Xen are tested, upstream Citrix not much but we do accept patches)
– and import also physical machines, using virt-p2v
I’d really recommend you to consider again the usage of virt-v2v for your tool — see the online documentation here: http://libguestfs.org/virt-v2v.1.html — instead of homebrew code. Also, I’d recommend you to contact us to our mailing list, libguestfs@redhat.com, so we can openly discuss this, and provide better feedback. I’d really hope that in an “open” world like OpenStack is supposed to be, this kind of decisions would be more open, and not something discussed behind closed doors and then publicized.
Thanks again for your time.