This is a useful tool, but spinning it as a victory against vendor lock-in is disingenuous. VM formats are well-documented and do not constitute a barrier to migration by any stretch of the imagination.
I would love to hear more about the real barrier to migration: the cost and latency hit of cross-cloud network communication. Who cares if you can move your app server to VMWare, if it needs low-latency access to 10TB of data sitting in amazon-us-east?
I helped to write virt-v2v[1], and one difficulty is changing the kernel config / Windows registry config / drivers / etc so the guest can be booted on another hypervisor (Amazon is Xen-based, VMware and KVM are completely different and need different drivers). You have to delve into the filesystem using libguestfs, and make some pretty complex changes.
As you say, the other difficulty is copying gigabytes of data across clouds. My colleague at Red Hat wrote snap[2] which can turn Linux guests into digests (basically a base distro name and list of packages and list of config changes), so this can be reduced massively. We're currently extending this work to support Windows and more Linux guest types.
> the cost and latency hit of cross-cloud network communication.
AWS Direct Connect might help with that. Anyone have any experience with it?
"AWS Direct Connect makes it easy to establish a dedicated network connection from your premise to AWS. Using AWS Direct Connect, you can establish private connectivity between AWS and your datacenter, office, or colocation environment, which in many cases can reduce your network costs, increase bandwidth throughput, and provide a more consistent network experience than Internet-based connections."
Well, it does move the burden for maintaining compatibility from third-party import tools / glue code / adapters back to the original vendor, which I think is extremely sensible.
I'm a little unclear on the specifics of actually running a foreign VM on EC2 and vide versa. Don't AMIs usually contain special provisions for running on Amazon's infrastructure?
This is awesome - what would be the remaining use case/advantage for using an AMI when you can now snapshot to more widely supported formats and import them?
Edit: Oh, this is windows only, significantly less exciting. I wonder why linux isn't supported?
Linux runs on EC2 via Xen/PV, which is a kernel-hypervisor interface not provided by other (non-Xen) virtualization systems. Exporting linux AMIs would require reaching inside your filesystem and modifying your kernel, which is far outside of the scope of anything Amazon would want to do (both in terms of "really complicated" and "liable to accidentally break things"). The same applies to importing images, of course.
[I don't work for Amazon and I don't speak for Amazon. The above is speculation based on information published by Amazon about EC2.]
It's not really complicated. If you have, say, a RHEL 6.2 image booting on EC2 you can take the same root filesystem and boot it with a kernel from any other RHEL 6.2 installation with some editing of the grub configuration.
But you're right that Amazon isn't really interested in doing that work for you. Linux people who really need this are no doubt already doing it.
Sure, but if you're running a custom kernel you'd need to run a custom non-PV kernel. And there's no remotely sane way for Amazon to figure out what customizations people have made to their kernels.
Kernel isn't a big deal, Colin. An entire filesystem should boot the same when exported. If you rsync / elsewhere, twiddle a few knobs like network config then reboot, you should be able to move an Amazon image anywhere. I have successfully done this between disparate virtualization providers, and Xen to dedicated.
Amazon is unique in that they use PV-Grub everywhere to boot a customer filesystem kernel (newer behavior), whereas on other virtualization providers like Linode, the kernel is selected at domain creation time by the hypervisor, and loaded from the hypervisor's filesystem (not the customer). You can use PV-Grub but it's opt-in, not opt-out.
I would love to hear more about the real barrier to migration: the cost and latency hit of cross-cloud network communication. Who cares if you can move your app server to VMWare, if it needs low-latency access to 10TB of data sitting in amazon-us-east?