12:20 p.m.
----- Original Message -----
From: "Bob Doolittle" <bob(a)doolittle.us.com>
To: "Yedidyah Bar David" <didi(a)redhat.com>, "Doron Fediuck"
<dfediuck(a)redhat.com>
Cc: "users" <users(a)ovirt.org>, "Sandro Bonazzola"
<sbonazzo(a)redhat.com>
Sent: Sunday, March 16, 2014 11:01:42 PM
Subject: Re: [Users] Migrate simple configuration to self-hosted
Thanks for the careful reading. First to repeat my start point and goals:
> 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
Comments inline:
On 03/16/2014 04:12 AM, Yedidyah Bar David wrote:
> 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.
I see two demographics interested in migrating their current Ovirt
deployment to self-hosted:
1 Those interested in freeing up a machine to use as another hypervisor.
2 Those (like me) interested in freeing up a machine to use for another
purpose.
Both groups want to free up a machine, presumably because they need more
resources. So I don't think our primary How-To should involve requiring
a new machine in order to migrate. I think many (like me) will find such
a solution intractable.
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 :-)
For those who have resources to spare, the current How-To seems fine,
but that might not be the majority.
> I can think of several different directions:
> 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.
This sounds like the most interesting approach for my needs. I like
simple, and I can live with some downtime.
Can you give me a complete list of things I should back up please?
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.
Also (and this gets back to my comment about the usefulness of some kind
of date on pages visible to people who are not logged in) there are many
pages regarding backup/restore. Is there one in particular you are
thinking of/recommend?
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
For backing up VMs I imagine it will not be
sufficient for me to export my VMs to an export domain somewhere remote
to host C (which I'll be scratching/reinstalling OS in order to target
self-hosted). Later if I restore actual engine data, and then import my
VMs, I imagine the UUIDs won't match? Or is the UUID preserved across
export/import?
Sorry, I don't know. I think that should be enough. Adding Liron and Maor
for that - can you please comment?
What if I were to create a new temp NFS Storage Domain with my current
oVirt, someplace other than host C, and then move my VMs to it? Then,
after I set up self-hosted and restore my engine data, I could move them
back and nuke my temp domain?
IIRC you can't connect a Storage (Data) domain to a different engine.
You should use an Export domain for that.
I'm willing to be a guinea pig here, and report back what I find, if I
can get a little more guidance as to avenues that might be useful to pursue.
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