On Sun, Sep 12, 2021 at 10:35 AM Yedidyah Bar David <d...@redhat.com> wrote:

>
> >>
> >> It was the step I suspect there was a regression for in 4.4.8
> (comparing with 4.4.7) when updating the first hosted-engine host during
> the upgrade flow and retaining its hostname details.
>
> What's the regression?
>

I thought that in 4.4.7 there was not this problem if you use the same
hostname but with different (real or virtual) hw as the first host during
your SHE upgrade from 4.3.10 to 4.4.7.
But probably it was not so and I didn't remember correctly....


> >> I'm going to test with latest async 2 4.4.8 and see if it solves the
> problem. Otherwise I'm going to open a bugzilla sending the logs.
>
> Can you clarify what the bug is?
>

The automatic mgmt of host adding during the "hosted-engine --deploy
--restore-from-file=backup.bck" step if you have different hw and you want
to recycle your previous hostname.
In the past it often happened to me to combine upgrades of systems with hw
refreshing (with standalone hosts, rhcs clusters, also ovirt/rhv from 4.2
to 4.3 if I remember correctly, ecc.) where you re-use an existing hostname
on new hardware
More than a bug it would be an RFE perhaps....



> > As novirt2 and novirt1 (in 4.3) are VMS running on the same hypervisor I
> see that in their hw details I have the same serial number and the usual
> random uuid
>
> Same serial number? Doesn't sound right. Any idea why it's the same?
>

My env is nested oVirt and my hypervisors are Vms.
I notice that in oVirt if you clone a VM it changes the uuid in the clone
but it retains the serial number...

> Unfortunately I cannot try at the moment the scenario where I deploy the
> new novirt2 on the same virtual hw, because in the first 4.3 install I
> configured the OS disk as 50Gb and with this size 4.4.8 complains about
> insufficient space. And having the snapshot active in preview I cannot
> resize the disk
> > Eventually I can reinstall 4.3 on an 80Gb disk and try the same,
> maintaining the same hw ... but this would imply that in general I cannot
> upgrade using different hw and reusing the same hostnames.... correct?
>
> Yes. Either reuse a host and keep its name (what we recommend in the
> upgrade guide) or use a new host and a new name (backup/restore
> guide).
>
> The condition to remove the host prior to adding it is based on
> unique_id_out, which is set in (see also bz 1642440, 1654697):
>
>       - name: Get host unique id
>         shell: |
>           if [ -e /etc/vdsm/vdsm.id ];
>           then cat /etc/vdsm/vdsm.id;
>           elif [ -e /proc/device-tree/system-id ];
>           then cat /proc/device-tree/system-id; #ppc64le
>           else dmidecode -s system-uuid;
>           fi;
>         environment: "{{ he_cmd_lang }}"
>         changed_when: true
>         register: unique_id_out
>
> So if you want to "make this work", you can set the uuid (either in
> your (virtual) BIOS, to affect the /proc value, or in
> /etc/vdsm/vdsm.id) to match the one of the old host (the one you want
> to reuse its name). I didn't test this myself, though.
>
>
I confirm that I reverted the snapshots of the 2 VMs used as hypervisors
taking them again at initial 4.3 status and remade all the steps, but right
after the install of the OS of 4.4.8 oVirt node I created /etc/vdsm/vdsm.id
inside novirt2 with the old 4.3 value (the file was not there at that
moment) and then all the flow went as expected and I was then able to reach
the final 4.4.8 async 2 env with both hosts at 4.4.8, cluster and DC
updated to 4.6 compatibility level and no downtime for the VMs inside the
env, because I was able to execute live migration after upgrading the first
host


Perhaps, if you do want to open a bug, it should say something like:
> "HE deploy should remove the old host based on its name, and not its
> UUID". However, it's not completely clear to me that this won't
> introduce new regressions.
>
> I admit I didn't completely understand your flow, and especially your
> considerations there. If you think the current behavior prevents an
> important flow, please clarify.
>
> Best regards,
> --
> Didi
>
>
My considerations, as explained at the beginning, were to give the chance
to reuse the hostname (often the oVirt admin is not responsible for
hostname creation/mgmt) if you want to leverage new hw in combination with
the upgrade process.

Thanks for all the other considerations you put into your answer.

Gianluca
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KXSZHEPQSHTFS3VSB25TUZ7DNFFVBHYB/

Reply via email to