Hi, migrating an existing installation to hosted engine may be done in several ways.
The first way may be using p2v, creating a VM from the physical host in an existing export domain. Then creating an OVF of the VM will allow hosted engine setup to import it. Fedora seems to have all needed packages, I've not verified it on CentOS. If I've understood correctly how it works, the required packages are: On Fedora >= 20: rubygem-virt-p2v-0.9.0-4.fc20 http://koji.fedoraproject.org/koji/buildinfo?buildID=453540 providing the client on >20 It's designed to be run from a live iso, not to be installed on an host On Fedora <= 20: virt-v2v (not sure if needed also on >20 but it seems so) providing the client and server on <= 20 provides the p2v server, receive data from v2v/p2v and save them on the export domain. However we need to test the whole process in order to be sure on requirements. Cons: - I don't think it will work if the export domain is on the same host we're going to convert to a VM. This may be solved with a release note telling the user to use another export domain. - The host running engine may also be used fot iso domain storage. p2v may generate a quite big image of the physical host, moving a storage domain to a VM. We can warn the user about it or add a release note. - if the physical host is an all-in-one system, migrating it as-is inside a VM need to use it as nested VM, and I'm not sure if it works at all with the hosted engine VM. Maybe such kind of migration will never be supported. Pros: - it will preserve the host configuration, including FQDN, firewall, database and so on. The second way is just create a fresh new hosted engine VM, backup everything needed from the physical host and then restore it inside the new VM Cons: - you've to install a new system and a new engine and anything else you wanted to migrate to the VM - you've to do the backup / restore instead of having already everything in place - you've to set FQDN and other configs manually - It will not handle the host name if the VM and you'd still need to add the hypervisor and then deal with it again after the restore part. Pros: - the VM may be smaller - the environment will be clean - the storage may stay on physical host and not migrated in a VM Maybe we can start with the p2v solution for 3.3 and look at the backup/restore for 3.4. What do you think? Thoughts and comments are welcome. Thank you, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
