-ctk and -flat files - attach restored vmdk to existing VM

[KARMA2018]

I am trying to upgrade an O/S of a huge server.
And so my approach was to restore the C:\ of the source server that we backup daily using Veeam.

Once restored with another name, upgrade O/S and re-attach the upgraded C:\ drive to the existing server.
If things go sideways, I can always revert back to original.

But what's confusing is the file structure I see in datastore for the source server. It's sowing three files for each drive - vmdk, -ctk.vmdk and -flat.vmdk

The C:\ is on S_14

and looks like the -ctk and -flat are coming from backup.

What is the best way to attach my newS_14.vmdk (upgraded o/s drive) to my current server? Do I rename it to S_14 or S_14-flat ?

Or should I get rid of -ctk and -flat files first?

thanks

[daphnissov]

I am trying to upgrade an O/S of a huge server.

Ok, got it. Fairly straightforward.

And so my approach was to restore the C:\ of the source server that we backup daily using Veeam.

Do what?

Once restored with another name, upgrade O/S and re-attach the upgraded C:\ drive to the existing server.

Wait. What now?

You are really trying to make this process quite complicated. Why not just ensure you have a full backup of this VM before beginning. Snapshot the VM as-is and perform your OS upgrade. If it goes sideways, you revert the VM to the latest snapshot.

[KARMA2018]

Thanks for the reply and sorry to jolt you out of your chair.

I understand the snapshot and that path to upgrade - but we have zero downtime for this box.

Hence, approach was to upgrade o/s in a separate environment first, test it with current data drives - could have taken a clone, v2v or backup restore...there are several ways.

Trying to understand the ctk, flat files, what is the best was to swap another VM's - vmdk to an existing VM's primary o/s drive.  Given that it's coming from a copy of it.

And, to test- another way is to attach the data drives to this new VM : it would be simple and adding vmdk path of existing drives, but with all the extra ctk,-flat files (the heaviest of all), not sure if this would work.

thx.

[daphnissov]

I think it's pretty unrealistic to be asked to upgrade the operating system of a VM with no redundancy and not have downtime. The plan you're proposing could go all sorts of sideways with ample opportunity for human error. If you want to accurately gauge if the upgrade could be successful or not, you could always backup then restore that VM to a sandbox and try the upgrade there. If using Veeam, for example, this can all be done with SureBackup and give you the level of confidence needed that it'll work on the live VM.

[KARMA2018]

daphnissov​

Let'sleave the upgrade aside.

If I need to attach the data disks of my source VM to another VM, how to go about that in this case?

Case being, that every disk on this vm, has a -ctk and -flat file. and the actual diskname.vmdk size is negligible.

[a_p_]

You'll attach the .vmdk descriptor file only, the associated data (flat.vmdk), and CBT (ctk.vmdk) files will be handled by ESXi.

André

[KARMA2018]

Thanks!

1. So say I remove the source - o/s disk S_14.vmdk

2. Add new drive

3. Select new Drive = NewS_14.vmdk  (which was a copy for S_14, but now with upgraded O/S)

4. Curious, if it would boot ok? Or I need to rename it as S_14.vmdk after attaching.

5. The current .ctk and -flat associate with disk in #1 above are not impacted?

[a_p_]

In this case, I'd use a new name for the upgraded OS disk (all 3 files). Once everything works as expected with the upgraded disk, you may then delete the old . now obsolete - one, and rename the new one (e.g. through selective storage vMotion, which will not require downtime).

Regarding the files:

• NewS_14.vmdk - is the descriptor file
• NewS_14-flat.vmdk - is the data file, which the descriptor file points to
• NewS_14-ctk.vmdk - is the changed block tracking (CBT) file. If it gets lost, it will be recreated, and e.g. a VM based backup application will do a full backup instead of incremental/differential.

André

[KARMA2018]

Thanks its much clear now.

I only have one vmdk for the upgraded o/s Disk - as it was restored (only C:) from Veeam .

So I believe you mean that I can simply attac the new upgrade-o/s drive - .vmdk to the current server (and remove it's current o/s drive)

Do I need to do anything on the current vmx file - since newly attached disk - has a different name?

Anything else , before I can successfully boot.

[a_p_]

I only have one vmdk for the upgraded o/s Disk - as it was restored (only C:) from Veeam.

You should at least have two .vmdk file, the descriptor, and the data/flat file!

Once the OS update is done, and you are sure that the data disks will work properly with the new OS disk, you may then shutdown the VM, and replace the C: drive's virtual disk name in the VM's configuration.

Note: I'd replace the virtual disk name from the command line by editing the VM's .vmx file directly. Note that in this case you will have to reload the VM after the change is done (see https://kb.vmware.com/s/article/1026043​)

André

[KARMA2018]

Checked twice, have only one .vmdk file for upgraded VM (restored C; using Veeam) which is powered up - the O/S is now upgraded as well.

So to be clear here are the files with .vmdk on my source and Upgraded VM. 
Plan is to boot Source with disk under: Upgraded .

Source - 2008 Server	Upgraded - 2012 R2
S_14.vmdk (.57kb)	New_S_14.vmdk (178,250,900.00)
S_14-ctk.vmdk (5440.50kb)
S_14-flat.vmdk (178,257,900.00)

[a_p_]

Not sure why, but that .vmdk disk format is not supported on ESXi.

Please attach the current 2008 VM's, and the new 2012 VM's latest vmware.log files to a reply post.

André