<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 24, 2017 at 10:59 PM, Ben Bradley <span dir="ltr"><<a href="mailto:listsbb@virtx.net" target="_blank">listsbb@virtx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 23/09/17 00:27, Ben Bradley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 20/09/17 15:41, Simone Tiraboschi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Wed, Sep 20, 2017 at 12:30 AM, Ben Bradley <<a href="mailto:listsbb@virtx.net" target="_blank">listsbb@virtx.net</a> <mailto:<a href="mailto:listsbb@virtx.net" target="_blank">listsbb@virtx.net</a>>> wrote:<br>
<br>
Hi All<br>
<br>
I've been running a single-host ovirt setup for several months,<br>
having previously used a basic QEMU/KVM for a few years in lab<br>
environments.<br>
<br>
I currently have the ovirt engine running at the bare-metal level,<br>
with the box also acting as the single host. I am also running this<br>
with local storage.<br>
<br>
I now have an extra host I can use and would like to migrate to a<br>
hosted engine. The following documentation appears to be perfect and<br>
pretty clear about the steps involved:<br>
<a href="https://www.ovirt.org/develop/developer-guide/engine/migrate-to-hosted-engine/" rel="noreferrer" target="_blank">https://www.ovirt.org/develop/<wbr>developer-guide/engine/migrate<wbr>-to-hosted-engine/</a> <br>
<<a href="https://www.ovirt.org/develop/developer-guide/engine/migrate-to-hosted-engine/" rel="noreferrer" target="_blank">https://www.ovirt.org/develop<wbr>/developer-guide/engine/<wbr>migrate-to-hosted-engine/</a>> <br>
and<br>
<a href="https://www.ovirt.org/documentation/self-hosted/chap-Migrating_from_Bare_Metal_to_an_EL-Based_Self-Hosted_Environment" rel="noreferrer" target="_blank">https://www.ovirt.org/document<wbr>ation/self-hosted/chap-<wbr>Migrating_from_Bare_Metal_to_<wbr>an_EL-Based_Self-Hosted_<wbr>Environment</a> <br>
<<a href="https://www.ovirt.org/documentation/self-hosted/chap-Migrating_from_Bare_Metal_to_an_EL-Based_Self-Hosted_Environment" rel="noreferrer" target="_blank">https://www.ovirt.org/documen<wbr>tation/self-hosted/chap-<wbr>Migrating_from_Bare_Metal_to_<wbr>an_EL-Based_Self-Hosted_<wbr>Environment</a>> <br>
<br>
However I'd like to try and get a bit more of an understanding of<br>
the process that happens behind the scenes during the cut-over from<br>
one engine to a new/hosted engine.<br>
<br>
As an experiment I attempted the following:<br>
- created a new VM within my current environment (bare-metal engine)<br>
- creating an engine-backup<br>
- stopped the bare-metal engine<br>
- restored the backup into the new VM<br>
- ran engine-setup within the new VM<br>
The new engine started up ok and I was able to connect and login to<br>
the web UI. However my host was "unresponsive" and I was unable to<br>
manage it in any way from the VM. I shut the VM down and started the<br>
bare-metal ovirt-engine again on the host and everything worked as<br>
before. I didn't try very hard to make it work however.<br>
<br>
The magic missing from the basic process I tried is the<br>
synchronising and importing of the existing host, which is what the<br>
hosted-engine utility does.<br>
<br>
<br>
No magic up to now: the host are simply in the DB you restored.<br>
If the VM has network connectivity and the same host-name of the old machine you shouldn't see any issue.<br>
If you changed the host-name moving to the VM, you should simply run engine-rename after the restore.<br>
</blockquote>
<br>
Thank you for the reply.<br>
I tried this again this evening - again it failed.<br>
<br>
The host is present within the new engine but I am unable to manage it.<br>
Host is marked as down but Activate is greyed out. I can get get into the "Edit" screen for the host and on right-click I get the following options:<br>
- Maintenance<br>
- Confirm Host has been Rebooted<br>
- SSH Management: Restart and Stop both available<br>
The VMs are still running and accessible but are not listed as running under the web interface. This time however I did lose access to the ovirtmgmt bridge and the web interface, running VMs and host SSH session were unavailable until I rebooted.<br>
Luckily I left ovirt-engine service enabled to restart on boot so everything came back up.<br>
<br>
The engine URL is a CNAME so I just re-pointed to the hostname of the VM just before running engine-setup after the restore.<br>
<br>
This time though I have kept the new engine VM so I can power it up again and try and debug.<br>
<br>
I am going to try a few times over the weekend and I have setup serial console access so I can do a bit more debugging.<br>
<br>
What ovirt logs could I check on the host to see if the new engine VM is able to connect and sync to the host properly?<br>
<br>
Thanks, Ben<br>
</blockquote>
<br></div></div>
So I tried again to migrate my bare-metal host to a hosted VM but no luck. The host remained in unresponsive state in the engine web UI and I was unable to manage the host in anyway. Although all VMs continued to run.<br>
<br>
I did capture some logs though.<br>
>From the new engine VM... engine.log<br>
<a href="https://p.bsd-unix.net/view/raw/666839d1" rel="noreferrer" target="_blank">https://p.bsd-unix.net/view/ra<wbr>w/666839d1</a><br>
<br>
>From the host...<br>
mom.log <a href="https://p.bsd-unix.net/view/raw/ac9379f0" rel="noreferrer" target="_blank">https://p.bsd-unix.net/view/ra<wbr>w/ac9379f0</a><br>
supervdsm.log <a href="https://p.bsd-unix.net/view/raw/f9018dec" rel="noreferrer" target="_blank">https://p.bsd-unix.net/view/ra<wbr>w/f9018dec</a><br>
vdsm.log <a href="https://p.bsd-unix.net/view/raw/bcdcdb13" rel="noreferrer" target="_blank">https://p.bsd-unix.net/view/ra<wbr>w/bcdcdb13</a><br>
<br></blockquote><div><br></div><div>Sorry but no one of that links is working right now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The engine VM is complaining about being unable to connect to the host, though I can see from tcpdump communication is fine. I believe this is backed up by the pings seen in mom.log<br>
<br>
Though I can see the following in vdsm.log... [vds] recovery: waiting for storage pool to go up (clientIF:569)<br>
So I wonder if this is blocking the engine bringing the host up.<br>
<br>
The host is running local storage, which I believe is a pretty recent addition to ovirt. So I could see how trying to run an engine VM on a host's local storage might cause weird issues.<br></blockquote><div><br></div><div>Maybe I lost a piece here.</div><div>Are you trying to migrate an old 3.6 all-in-one setup (where ovirt-engine - the manager - and vdsm - the agent on the host are running on the same host) to hosted-engine in a single step?</div><div>In that case it will not work for sure since when you will power-down the old engine machine you will also power-down your old host and so the new engine running on the VM is not able to contact the host since the old host is down.</div><div><br></div><div>In hosted-engine idea, the engine runs on a VM running on the host that its managing.</div><div><br></div><div>In that case probably the most effective way is to:</div><div>within your old engine:</div><div>- create a datacenter with shared storage (please avoid using NFS in loopback)</div><div>- add your new hosts there</div><div>- migrate all of your VMs to the new dataceter</div><div>- only now you can migrate to hosted-engine</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I realise that there won't be HA with this setup, until I create my second host and configure HA on the VM.<br>
<br>
If I am unable to migrate from bare-metal -> engine VM then it doesn't give me any confidence that I would be able to restore a setup from a backup onto a bare-metal host and recover host state.<br>
<br>
So is the only supported method of migrating from bare-metal engine to hosted engine by...<br>
1) Migrating to the appliance<br>
2) Using a new host to migrate to VM<br>
3) Using shared storage between hosts<br>
<br>
Thanks, Ben<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The only detail is that hosted-engine-setup will try to add the host where you are running it to the engine and so you have to manually remove it just after the restore in order to avoid a failure there.<br>
<br>
<br>
Can anyone describe that process in a bit more detail?<br>
Is it possible to perform any part of that process manually?<br>
<br>
I'm planning to expand my lab and dev environments so for me it's<br>
important to discover the following...<br>
- That I'm able to reverse the process back to bare-metal engine if<br>
I ever need/want to<br>
- That I can setup a new VM or host with nothing more than an<br>
engine-backup but still be able to regain control of exiting hosts<br>
and VMs within the cluster<br>
<br>
My main concern after my basic attempt at a "restore/migration"<br>
above is that I might not be able to re-import/sync an existing host<br>
after I have restored engine from a backup.<br>
<br>
I have been able to export VMs to storage, remove them from ovirt,<br>
re-install engine and restore, then import VMs from the export<br>
domain. That all worked fine. But it involved shutting down all VMs<br>
and removing their definitions from the environment.<br>
<br>
Are there any pre-requisites to being able to re-import an existing<br>
running host (and VMs), such as placing ALL hosts into maintenance<br>
mode and shutting down any VMs first?<br>
<br>
Any insight into host recovery/import/sync processes and steps will<br>
be greatly appreciated.<br>
<br>
Best regards<br>
Ben<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a> <mailto:<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a>><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
<<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailma<wbr>n/listinfo/users</a>><br>
<br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
</div></div><a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
</blockquote><span class="">
<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
</span><a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
</blockquote></div><br></div></div>