[Users] Migrate simple configuration to self-hosted

[Yedidyah Bar David]

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Bob Doolittle" <bob at doolittle.us.com>
> Cc: "users" <users at ovirt.org>, "Sandro Bonazzola" <sbonazzo at redhat.com>, "Yedidyah Bar David" <didi at redhat.com>
> Sent: Thursday, March 13, 2014 9:23:03 PM
> Subject: Re: [Users] Migrate simple configuration to self-hosted
> 
> 
> 
> ----- Original Message -----
> > From: "Bob Doolittle" <bob at doolittle.us.com>
> > To: "users" <users at ovirt.org>
> > Sent: Thursday, March 13, 2014 8:25:51 PM
> > Subject: [Users] Migrate simple configuration to self-hosted
> > 
> > Hi,
> > 
> > I want to migrate my existing deployment to self-hosted. I have a simple
> > deployment:
> > 
> > A: Machine Fedora 20
> > B: libvirt VM (hosted on A) RHEL 6.5 running Engine 3.3.4-1
> > C: Machine RHEL 6.5 acts as Hypervisor/Host/Node (VDSM 4.13.3-4)
> > 
> > ISO NFS Domain is on B
> > Data (Master) NFS Domain is on C
> > 
> > I want to migrate VM B to Machine C, as self-hosted, and free up Machine A
> > 
> > When I look at these instructions:
> > http://www.ovirt.org/Migrate_to_Hosted_Engine
> > 
> > It starts with "I installed a new host with fedora 19".
> > 
> > I don't understand this. Won't most people doing this migration want to
> > start with their existing Hypervisor/Host/Node, and migrate their Engine
> > to it? Do I really need a new 3rd machine, when my goal is to free up
> > one of my 2 existing machines?

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.

> > 
> > Or can I go ahead and assume these instructions are fine to apply to an
> > existing Host already running VDSM 4.13.3-4?

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.

> > 
> > I would have (naively?) imagined that the typical migration would be
> > something like:
> > 
> > 0. Upgrade Engine and Host to 3.4
> > 1. Create a new VM

You probably mean a new VM managed by your existing oVirt engine, not a
new libvirt VM on host A.

> > 2. Install OS on new VM, start it up
> > 3. Backup current Engine
> > 4. Stop current Engine (leave Host and VM running), change hostname
> > (local and DNS), maybe power off for good luck until done

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.

> > 5. Login to new VM (probably using ssh unless there's a way to connect
> > directly to the VM via Spice/VNC while the Engine is down) to:
> >      A. Assign previous Engine hostname to it (local and DNS), possibly
> > reboot

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.

> >      B. Set it up as a self-hosted Engine

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.

> >      C. Restore backup to it
> >      D. Start up new engine
> > 
> > What am I missing?

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.

> > 
> > Thanks,
> >      Bob
> > 
> 
> Hi Bob,
> first of all F20 is not fully supported for the engine due to the JBoss
> version it uses.

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.

> 
> As for your questions, as any admin will tell you fresh start is usually much
> better
> than keeping old files and configurations which may or may not effect what
> you're
> trying to install.
> Since you're about to free a server to become a hypervisor, you can use one
> of
> your other hypervisors as the first hosted engine node. The current engine
> machine
> is not a hypervisor (missing vdsm, and probably other packages) so you'll
> need
> to add it as a host anyway to your hosted engine setup eventually.
> 
> Having said that, you can try going your own way. This is something which may
> be technically possible nut we did not try or tested it before.
> 
> Keep us updated,

Indeed!
-- 
Didi