----- Original Message ----- This document assumes the most trivial settings, where the only thing you care about is simplicity, stability and minimizing downtime. It specifically does not try to use the minimum hardware possible. Not necessarily. I can definitely tell you that I stumbled into various problems during testing when trying to deploy a "dirty" host. Current deploy assumes a clean host, and might or might not work on an existing, in-use one. You probably mean a new VM managed by your existing oVirt engine, not a new libvirt VM on host A. More important is to disable relevant services (ovirt-engine, maybe others) from starting on reboot. It would be rather bad if you start it up after the new engine is up and two engines try to manage the same resources. No need to change hostname (also on the old host, for that matter). You just have to make sure that the dns points at the new machine's IP address. That's the tough part. How are you going to do that? 'hosted-engine --deploy' will not help you here, it's not designed for this scenario. It creates the VM by itself. I can think of several different directions: Direction 1 =========== Most similar to what you intended. 0. Upgrade to 3.4 1. Run 'hosted-engine --deploy' on C . As I said, this has a good chance to not work and/or cause other problems - do not try this if you care about uptime and without good backups. This will create a VM for you. Install OS+engine inside it, use backup and restore to migrate the engine itself, with the dns/disabling/etc as you described (and as described in the wiki). That's an interesting direction to take, but will probably require some manual fixes etc., if successful at all. Direction 2 =========== If you do not care about uptime - the simplest. Backup everything(!) - engine VM, other VMs, etc., then start from scratch: Reinstall OS on host C, install and deploy hosted-engine there, restore actual engine data from backup as described in the wiki. Direction 3 =========== Most complex, but might be quite risk-free, and require less downtime. 1. Create a new oVirt VM on C, install OS+engine on it, and backup/restore engine data from B to this new machine. Let's call it TempEngine. Technically speaking, at this poing, you'll get a self-hosted engine. But nothing will know about that except you. So now you want to migrate to "real" hosted engine. Now that you freed up machine A, you can use it as a temporary host to do that. For the future, it might make sense to add some tool/function to allow doing that without more migrations - just somehow tell the engine that it's running in a VM hosted by a host it manages itself, and that it should treat it as expected (including adding HA and whatever). You are welcome to open an RFE bug if you care... 2. Reinstall host A with a supported OS, install and deploy hosted-engine on it. This will create a new VM. Let's call it NewEngine. Install OS+engine on NewEngine, backup/restore engine from TempEngine to it (dns, disable old, etc.). 3. Migrate your existing VMs from host C to host A. 4. Put host C into maintenance, carefully clean up libvirt/vdsm there. If you do that carefully, you might manage to keep your existing VMs up all the time. You'll probably want to (at least) uninstall libvirt and vdsm, and remove: /etc/init/libvirtd.conf /etc/libvirt/* /etc/vdsm/vdsm.conf /etc/pki/vdsm/*/*.pem /etc/pki/libvirt/*.pem /etc/pki/libvirt/private/*.pem 5. Now run 'hosted-engine --deploy' on host C. Supply the existing path, deploy will identify this as a "second" deploy and will add the host to the existing engine etc. 6. Now Migrate back your VMs to host C and free up host A. Important notes: ================ 1. This was not tested. Thoroughly test and backup if you value your data. 2. Data/ISO domains are _not_ backed up or restored by engine-backup, whether you configured them by yourself or as part of engine-setup. So, in your case, you'll need to manually take care of the ISO domain on VM B. Indeed, but Bob did not mention he is going to use the F20 machine for the engine, so that does not seem relevant. I don't know if F20 is supported for hosted-engine, and know of no reasons why it should not be. Still irrelevant if eventually only rhel6 is left for both the host (C) and VM. Indeed! -- Didi

----- Original Message ----- 1. You are probably right :-) 2. You are still left with a machine to be reused in the end. 3. Another group of users is those who do not care about the extra machine but want the High Availability feature. 4. Please realize that this feature is still rather new, and while we hope it works well, there is still not very much experience with it. When it matures we can obviously write more documentation for more interesting use cases. You can, too :-) Not sure I really can. Please, if at all possible, take a complete backup of all relevant machines, just in case you miss something. A partial list: 1. The engine - using engine-backup 2. The ISO domain - not sure how, should be easy to reconstruct (just keep the images, and when you create the new iso domain you can simply copy them back in). 3. The VMs - probably using an export domain, not sure if that's the best way. http://www.ovirt.org/Ovirt-engine-backup I agree there is a bit of mess regarding this. Searching for 'site:www.ovirt.org engine backup' returns quite many pages - I now looked at the first few. Some are user pages. Some refer to backing up VMs. And some refer to the engine. One specifically talks about the engine db only, not sure it should be touched. One was created to help organize this subject, and it has a link to the previous one I mentioned: http://www.ovirt.org/Backup_And_Restore_Engine Sorry, I don't know. I think that should be enough. Adding Liron and Maor for that - can you please comment? IIRC you can't connect a Storage (Data) domain to a different engine. You should use an Export domain for that. That's really appreciated. I'll try to help mainly with the things I know more about (setup, engine-backup, hosted-engine). If you need specific help with other issues, it might be better to ask them in different threads with suitable subjects, to help people help you... -- Didi