deasyp
Enthusiast
Enthusiast

Is Server 2019 Supported on v6.5 build 11925212 ?

Jump to solution

I'm running into a strange one.. be interested in knowing if anyone has encountered this...

I have a new VM on which I've installed Server 2019.  All appears to be fine on the install, domain join, etc..

I left the VM to apply updates, rebooted the host and on restart..and ....  Operating system not found

My ESXi host is running v6.5 build 11925212, but our vCenter is a little behind on updates (due to some challenges in getting my vcsa to upgrade to 6.7)

I deployed the VM as a Server 2016 on the OS selection drop-down.. all seems ok there.

My VM has two HDD's - an 80Gb OS disk, and then a secondary 1Tb (D:) drive.

When I boot off the windows media, going via the repair procedure it will see both disks.

I then compared this VM against a working 2019 VM.. the SCSI controller appears to have flipped the disks the C:\ drive on 0:1 and the D:\ on 0:0

I set them back to C:\ => 0:0 and D:\ => 0:1 powered up the VM, and it's reset back to the 'wrong way'

Any ideas, on what's causing this (and how to correct) would be much appreciated.

0 Kudos
1 Solution

Accepted Solutions
deasyp
Enthusiast
Enthusiast

Hi ThompsG​..  thanks for the feedback..

It was a case that the SCSI ID was changing, despite me going back into the VM and setting the C:\ disk to 0:0 and D:\ disk to 0:1

Using your line of thinking I am back in action.. never crossed my mind to disconnect the disk and retry...but the first try to reconnect didn't work!
This had me scratching my head for a bit..So I'm wondering if I've found a 'feature' arising from a unique sequence of events ??

This VM for a new deployment of SCCM. I use PowerCLI and used a customization spec to deploy the VM.. the OS gets setup with hostname, etc.

Standard practice would be that if I provide a vmhostname in the powershell code: "New-VM -Name $vmhostname -Template $mySourceTemplate...." then the VM will get created as say 'server1' with the hostname 'server1'.

So VM was deployed, joined to the domain (as 'server1') with just the C:\ drive, windows updates deployed.

After the updates where deployed, I renamed the VM , adding a suffix  '-sccm' suffix to the VM name. (We add a suffix so others can quickly see what the VM does, given we've a lot of VMs). I then added the disk to the VM (I don't think I actually powered down the VM when I did the rename & disk addition).

I then added some windows features and SCCM roles to the sever - which added content to the second (d:\) disk.  I then rebooted the VM and discovered the missing OS scenario.

The C:\ disk (disk 0:0) had the file name 'vmname.vmdk' and when I checked this morning (prior to disconnecting the disk) the D:\ disk (0:1) was called 'vmname-sccm.vmdk'  (i.e. it got the filename with the new name suffix added and not 'vmname_1.vmdk' which is what I've seen with other VMs).   

So I wonder is there some code/function that assumes the 0:0 disk is the vmdk file which has the name which matches the vmname

(i.e. as I'd changed the vm name to 'server1-sccm' and there was a disk present called 'server1-sccm.vmdk' that it assumed that this was disk 0:0)

This morning I powered down the VM, disconnected the 😧 disk (after my first attempt to add didn't work), I then renamed the disk to servername_1.vmdk (and did the same for the '-ctk.vmdk' file (not sure if i needed to do that).. and powered up the VM with just the C: drive, then added the second disk (which I'd renamed) , made sure that windows disk manager was showing C: as the boot disk, and rebooted the host.. bingo, back in business !

View solution in original post

0 Kudos
4 Replies
iiliev
VMware Employee
VMware Employee

According to VMware Compatibility Guide, Server 2019 is supported on ESXi 6.5

https://www.vmware.com/resources/compatibility/search.php?deviceCategory=software&details=1&partner=...

ThompsG
Virtuoso
Virtuoso

Hi deasyp​,

Windows Server 2019 has been supported since 6.5 according to here so you should be okay: VMware Compatibility Guide - Guest/Host Search

When you mention that the SCSI ID changes, is that inside the guest or within the VM configuration?

Also so try disconnecting (not deleting!) the second drive so that there is only one option to boot?

Kind regards.

deasyp
Enthusiast
Enthusiast

Hi ThompsG​..  thanks for the feedback..

It was a case that the SCSI ID was changing, despite me going back into the VM and setting the C:\ disk to 0:0 and D:\ disk to 0:1

Using your line of thinking I am back in action.. never crossed my mind to disconnect the disk and retry...but the first try to reconnect didn't work!
This had me scratching my head for a bit..So I'm wondering if I've found a 'feature' arising from a unique sequence of events ??

This VM for a new deployment of SCCM. I use PowerCLI and used a customization spec to deploy the VM.. the OS gets setup with hostname, etc.

Standard practice would be that if I provide a vmhostname in the powershell code: "New-VM -Name $vmhostname -Template $mySourceTemplate...." then the VM will get created as say 'server1' with the hostname 'server1'.

So VM was deployed, joined to the domain (as 'server1') with just the C:\ drive, windows updates deployed.

After the updates where deployed, I renamed the VM , adding a suffix  '-sccm' suffix to the VM name. (We add a suffix so others can quickly see what the VM does, given we've a lot of VMs). I then added the disk to the VM (I don't think I actually powered down the VM when I did the rename & disk addition).

I then added some windows features and SCCM roles to the sever - which added content to the second (d:\) disk.  I then rebooted the VM and discovered the missing OS scenario.

The C:\ disk (disk 0:0) had the file name 'vmname.vmdk' and when I checked this morning (prior to disconnecting the disk) the D:\ disk (0:1) was called 'vmname-sccm.vmdk'  (i.e. it got the filename with the new name suffix added and not 'vmname_1.vmdk' which is what I've seen with other VMs).   

So I wonder is there some code/function that assumes the 0:0 disk is the vmdk file which has the name which matches the vmname

(i.e. as I'd changed the vm name to 'server1-sccm' and there was a disk present called 'server1-sccm.vmdk' that it assumed that this was disk 0:0)

This morning I powered down the VM, disconnected the 😧 disk (after my first attempt to add didn't work), I then renamed the disk to servername_1.vmdk (and did the same for the '-ctk.vmdk' file (not sure if i needed to do that).. and powered up the VM with just the C: drive, then added the second disk (which I'd renamed) , made sure that windows disk manager was showing C: as the boot disk, and rebooted the host.. bingo, back in business !

View solution in original post

0 Kudos
deasyp
Enthusiast
Enthusiast

Thanks for the feedback.. I had checked a similar compatibility guide, and assumed it was, but having run into bit of a unique scenario (explained in the other response) I wasn't sure if the fact I was deploying server 2019 as a server 2016 VM that I make have found something that wasn't supported.. 

0 Kudos