Bug 54195 - takeover using VMware not reliable
takeover using VMware not reliable
Status: NEW
Product: UCS
Classification: Unclassified
Component: AD Takeover
UCS 5.0
amd64 All
: P5 critical (vote)
: ---
Assigned To: Samba maintainers
Samba maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-12-06 14:56 CET by Telirand
Modified: 2021-12-06 14:56 CET (History)
0 users

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telirand 2021-12-06 14:56:41 CET
At the end of the take over and the "old" ad is switched off.

Univention goes on to configure a repointing of the interfaces in the new server.
however the system is flawed.

you take the network interface, then bum in an "alias" to match the old ip address of the replaced AD server.

This works fine, inside the vm, but if the actual server hosting the  AD vm is not in the same subnet, then the  "multi-homing" of the network card cannot be routed.

VMware does not allow multiple ip addresses in the same subnet to be routed via the correct gateways.

so what actually happens, is the "Alias" address does not reliably function.

What should happen is the option to "leave the network ALONE", tehn allow the user to manually reconfigure the base ip address to the new one.
THEN reboot.

I have not been able to reliably back out the changes on a completed install for the alias