Solved - Win VM migration between nodes and domain trust

[ieronymous]

Hi

Yesterday, I started the process of transferring all Vms from the old node to the new one.
Vms include a Domain Controller, a File Server, an SQL server, 2 win 10 & 11 machines for some services and a RDS server.
All servers are based on Win2019 OS. Hardware is different the servers, but as cpu host from the very start of the VMs creation
had chosen as cpu type x86-64-v2-AES for that particular reason and future licensing issues.

I thought to start only with one VM (RDS-Server) and see how it goes and continue from there with other VMs. The way of migration was an
intermediate Truenas server used for backup purposes connected to the nodes via a nfs share. So after backing up the VM, restored it
to the new server and of course watched NOT to tick unique option. Also let VM id the same.

The issue was and still remains that after starting the VM (RDS-Server) and trying to login with a user's credentials, I have a message of <<domain's
credential broken>> and I can only login as a local admin. Maybe it would be a Win issue, specially if we take into consideration how easily
Win and server OSes dislike changes and breaks validation keys quite easily, but here it is not the license the problem. It happens after migration,
so I felt this was the correct forum to ask for guidance / help , specially if others came across a similar issue.

Finally, everything remains the same inside the conf file of the VM and the network bridge except the vmgenid which is the only field that changes

agent: 1
boot: order=scsi0
cores: 4
cpu: x86-64-v2-AES
machine: pc-i440fx-8.1
memory: 16384
meta: creation-qemu=8.1.5,ctime=1719391962
name: WS2K19-RDS0
net0: virtio=BC:24:11:81:33:C8,bridge=vmbr1,firewall=1
numa: 1
ostype: win10
scsi0: HHprox3VM:vm-106-disk-0,cache=writeback,discard=on,size=120G
scsihw: virtio-scsi-pci
smbios1: uuid=2346700c-a342-4b27-9245-7c12b384e004
sockets: 1
vmgenid: 5eedff76-46fa-4086-83e6-07a89a2dc254          ->(differs after migration)

vmbr1 BD:24:17:56:788
Everything else (I believe so), remains the same except the vmgenid option.

 

[dcsapak]

hi,

maybe this link helps? https://learn.microsoft.com/en-us/w...dc/virtualized-domain-controller-architecture

i'm not too familiar with windows RDS virtualilzed, but the vmgenid must change after a restore, otherwise it won't take the necessary action e.g.
when there was a cluster of DCs and one was restored from an older backup (even if the 'unique' option was not checked)

EDIT: of course, if you're really sure what you're doing and know the vmgenid has to stay the same, you can edit the config after restoring before starting to the old one

 

[ieronymous]

maybe this link helps? https://learn.microsoft.com/en-us/w...dc/virtualized-domain-controller-architecture

Unfortunately not only helps but raises a hell more questions without them being necessary (one of them might be where the DcCloneConfig.xml is located since is being mentioned a lot(in the vm, in the hypervisor iteslf, which path...etc)). The article speaks of moving the DC itself rather than a server that is part of that domain.

i'm not too familiar with windows RDS virtualilzed, but the vmgenid must change after a restore, otherwise it won't take the necessary action e.g.
when there was a cluster of DCs and one was restored from an older backup (even if the 'unique' option was not checked)

Im pretty sure the same will happen whichever of the 7 server VMs I ll try to migrate to the new node. You say must change yet this change is like DC sees a new machine with the same computer name and different id. It's logical from a security perspective not to like it.

EDIT: of course, if you're really sure what you're doing and know the vmgenid has to stay the same, you can edit the config after restoring before starting to the old one

If I was sure i would do it. Since this must happen in a production system, I have to be sure.
I believe so many members in here, someone would have tried to migrate a domain joined VM to another node and have an experience so opinion about that.

 

[ieronymous]

Is vmgenid somewhere visible in the gui or only inside the .conf file of the VM?

 

[dcsapak]

no, it's not shown on the gui, but you can use either the api or the cli to change it

e.g.

qm set ID --vmgenid <the-new-id>

 

[ieronymous]

no, it's not shown on the gui, but you can use either the api or the cli to change it

e.g.

qm set ID --vmgenid <the-new-id>

If you want to see it before you change it wouldn 't that be something like qm get ID --vmgenid 106 assuming the VM has id of 106. Tired a couple of combinations to no effect

 

[dcsapak]

you can see it e.g. with

qm config ID

this prints the whole config, to filter you can e.g. use grep:

qm config ID | grep vmgenid

 

[ieronymous]

i'm not too familiar with windows RDS virtualilzed, but the vmgenid must change after a restore, otherwise it won't take the necessary action

Changing it back to it's initial number made the trick and the VM started and user be able to login to the domain.

Bottom line, issue was the automatic change of vmgenid value after restore.

New edit: Tried that with a VM having as extra an efi and a TPM storage and worked as well. Only change was the vmgenid value.