Is there a plan to allow VM migration?
As per the subject, is there a plan to allow VM migration? By that I don't mean the current idea of detaching the export storage and attaching it to another compatible system. I mean a real migration to something external to the system the VM is currently on. At least in my universe, there are times when it is highly desirable or even necessary to take an Ovirt/RHEV VM and move or copy it to another system, such as between completely separate Ovirt/RHEV systems or to other systems such as KVM/Qemu or VirtualBox. The nearest I can manage right now is to use an imaging tool to make a copy of the drive and import that into the destination machine. That's slow, cumbersome and still requires the VMs configuration to be manually duplicated. regards, John
On Wed, 6 Aug 2014, John Gardeniers wrote:
As per the subject, is there a plan to allow VM migration? By that I import that into the destination machine. That's slow, cumbersome and still requires the VMs configuration to be manually duplicated.
The problem we have run into when trying to implement automated assistance on image migrations between different backing store, is that the bootloader / initrd fixups are not deterministic and 'doable' as between grub, grub2, and other 'first stage' I would love a solution, but after much experimentation, I just don't see a good path to solving this in a general form. (it is not a many spokes to one common interchange format, and then one to new spoke transition, but rather a many to many problem) Perhaps the libguestfs uplift mentioned for a few months from now with the RHEL 7.1 updates will help -- Russ herrold
Hi Russ, Could it be that you're over-thinking this? Why can't Ovirt simply export VMs to a standard format, preferably of course one already used elsewhere, such as ovf? That way it's a straight one-to-one. regards, John On 06/08/14 08:57, R P Herrold wrote:
On Wed, 6 Aug 2014, John Gardeniers wrote:
As per the subject, is there a plan to allow VM migration? By that I import that into the destination machine. That's slow, cumbersome and still requires the VMs configuration to be manually duplicated. The problem we have run into when trying to implement automated assistance on image migrations between different backing store, is that the bootloader / initrd fixups are not deterministic and 'doable' as between grub, grub2, and other 'first stage'
I would love a solution, but after much experimentation, I just don't see a good path to solving this in a general form. (it is not a many spokes to one common interchange format, and then one to new spoke transition, but rather a many to many problem)
Perhaps the libguestfs uplift mentioned for a few months from now with the RHEL 7.1 updates will help
-- Russ herrold
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
On Wed, 6 Aug 2014, John Gardeniers wrote:
Could it be that you're over-thinking this? Why can't Ovirt simply export VMs to a standard format, preferably of course one already used elsewhere, such as ovf? That way it's a straight one-to-one.
Life is not so neat not a thought experiment here, but rather a summary of real life, in practice issues hit in working toward a generally applicable, FOSS based solution The testing grid, to make it interesting is to be able to gobble in and use [examples still in production for ome reason or another]: RHL 5.2 RHL 7.2 Windows 95 Windows NT 3.51 Windows 2000 Windows XP --- all above this line are legacy and out of support -- we know this, but our customers are indifferent to such, so long as it does not 'see' the internet at large -- RHEL / CentOS 5 (Xen hooks) RHEL / CentOS 6 (KVM hooks, with grub) RHEL / CentOS 6 (KVM hooks, with grub2) assorted Fedora assorted (but largely recent) Ubuntu Assorted Debian Testing and Stable OpenBSD -- various NetBSD -- various We have automation for parts, but not all of that grid -- Russ herrold
participants (2)
-
John Gardeniers -
R P Herrold