I ran into a frustrating issue the other day when attempting to add multiple new virtual disks to an existing VM. Upon doing so, I received the dreaded “Operating System not found” message when the VM was started. While the underlying issue was easy to discover, the way to fix the problem became tedious due to issues with the vSphere web client. This post contains some tips and tricks to make the process easier.
I started with a VM that had a single 100GB virtual disk:
I wanted to add multiple new virtual disks to this VM. To simplify things for this post, let’s assume I add a single new datastore:
Everything looks good, but when the VM is powered on I received the “Operating System not found” message. So what went wrong? Well, since I knew the only change I had made was adding a second virtual disk it seemed logical that adding the second virtual disk caused the problem. Upon expanding the new virtual disk’s properties I discovered something odd:
You will notice under Virtual Device Node that the virtual disk was listed under SCSI(0:0). This is odd because the VM already has a virtual disk that should occupy SCSI(0:0). When I checked the initial virtual disk, I saw it was listed under SCSI(0:1):
The reason why this is a problem is that the VM is attempting to boot from the first SCSI device and since the new, blank virtual disk I added was the first SCSI device the system could not be booted. Now, this problem can be addressed by changing the BIOS settings for the VM, but I wanted to address the underlying issue and renumber the initial virtual disk as SCSI(0:0) and the new virtual disk as SCSI(0:1).
To do this, I change the new virtual disk from SCSI(0:0) to SCSI(0:2) as each SCSI device must occupy a unique SCSI number and in the same operation changed the initial virtual disk from SCSI(0:1) to SCSI(0:0). Before applying the changes my screen looked like the following:
I applied the changes, noticed that the operation was successful, and started the VM. Again I received “Operating System not found”. When I checked the settings of the VM, I found that the first operation I had performed, changing the second virtual disk, had taken effect, but the second operation, changing the initial virtual disk, had not. What I learned is that only one change operation ever took effect. I am not sure, but I believe this to be a bug in the vSphere web client (I am using vSphere 5.5).
While having to perform the edit operation was a minor inconvenience, in my real example, I was adding four new virtual disks to the VM at the same time. What happens, in this case, is that not only does a single operation occur, but sometimes the order of the hard drives gets changed during the operation and it is near impossible to get the order back. In my case, the initial hard drive became hard drive 5 and I could find no way to make it become hard drive 1 again even through SCSI renumbering.
With multiple new virtual disks in a state of mis-numbering, I found that removing the new virtual disks, fixing the numbering issue on the initial virtual disk, and re-adding the new virtual disks was the simplest course of action.
© 2014 – 2021, Steve Flanders. All rights reserved.
Thanks so much for this. Always the little things that get us bogged down. thanks for the help!
Thanks for the comment and I am glad this post helped!
Thank you a lot. This post saved me dozen of hours. Nuno Cabrita
Happy to help!
Same issue in VSphere 6.5. The second added disk become the first and the VM obviously won’t boot. Added a secondary scsi controller and moved the second disk on it. That solved the issue. Tested with multiple reboots. Hope it helps. 🙂
Hey Cornel — thanks for the comment and workaround!
My solution was changing Boot order in BIOS, but adding a new controller for new disks looks much better to me. Thank you for this article. I will link it to friends.
Thanks for the comment!
Steve,
You posted this almost exactly 5 years ago, but it saved my day today! Your post still rocks. Thanks so much.
Glad to hear and happy to assist!