We have P2V'd Windows 2003 servers. Each is configured to have a C: (O/S) and a D:(data) drive, one VMDK/drive.
We are seeing some servers "lose" their mapping to D:. We have to go into disk management and re-assign the drive letter. The data is all there and accessible after this. While I cannot say for certain it appears to drop during a reboot.
Does anyone know the root cause of this? Or seen it?
what kind of W2K3 you're talking about, Standard or Enterprise?
On a Standard W2K3 automount is enabled while it's disabled on Enterprise (or Datacenter).
And when you're using C: and D:, I assume that you simply accept the default drive letter assignment.
If so, it could happen that the drive letter assignment isn't stored correctly in the registry.
Easiest way would be to choose a different drive letter, but you're talking about a running and not a new installation.
Therefor it might not be possible to change the drive letter.
Other option would be diskpart which does allow you to control the automount behaivior on a W2K3 Enterprise system.
This would enable the automount feature and removes volume mount point directories and registry settings for volumes that are no longer in the system.
Hope this helps a bit.
Is there a cd drive in the vm settings as well? You may have some hidden devices which are causing drive letters to shift, and in your case, drop. Go into device manager, and click view, show hidden devices. Make sure something there isn't conflicting with your setup.
to build on kjb's post...on all P2V'd VM's you should
At a command prompt, type the following command , and then press ENTER:
Click Show hidden devices on the View menu in Device Managers before you can see devices that are not connected to the computer.
Remove any devices not on the system..especially hardware specific ones.
Remove any software installed into the VM to support that hardware.
You should also make sure that if you configured your VM as a single CPU VM (as normally recommended) then also make sure you have changed the HAL to be a uniprocessor or else you are going to get higher utilization.
Moved to VI: Virtual Machine and Guest OS Forum.
Edward L. Haletky
VMware Communities User Moderator
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354
As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
Greg - I guess your D-drive is a not a primary partition but a logical inside an extended one - is that right ?
If yes - very likely the CD-drive will claim 😧
Either check your mapping in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
or convert the logical into a primary one - that can be done with partitionmagic for example
You are correct about the logical inside the extended. This is what the conversion process created. We are not seeing consistent results during our P2V activities. Most are coming over with 2 primary partitions but a handful come across with a primary and an extended partition. This is a secondary issue now brought to light. Anyone out there know why this would be?
The first issue we have is that the virtual instance was running fine with a 😧 drive and then one day 😧 simply disappeared. The CD was still listed as E: Going into disk management and assigning 😧 back to the partition was successful. We need to understand why the mapping dropped. It may be related to the extended partition but at this point we can not draw a straight line conclusion between the two.
Thanks for all the feedback so far.
Message was edited by: BlackHawk-VM
We had another drive dropped on a reboot last night. This server had two primary partitions.
The CD-ROM retained it's mapping as Z:.
Re-mapped the second partition to 😧 and rebooted. Mapping was retained.
A little too intermittent for my liking.
Nothing in the event logs are showing up at all when this happens? This is something within Windows itself as ESX only presents the disk files...its doesn't know anything about the partitions inside the VM. I've seen this before on different systems, but it usually related to corruption of the MFT
Personally i would be creating a new VMDK, copying that data to the new drive and remove the logical partition so that C: and 😧 are each physical vmdk's.
I'd probably also ghost my C drive into a new disk so I could get its size reduced to what it needs to be.
I had the same problem just this week on a machine with primary partions on separate vmdk files.
I have been running Acronis True Image Echo for Windows very successfully for months, but for some reason the job did not copmplete. It was configured to use MS Volume Shadow Copy Services as the snapshot provider.
During the attempted snapshot, all the volume attributes were changed making the drive letter not re-map. even when i did it manually I could not write to the volume, getting a "Media is write protected error"
So next time it happens, fire up diskpart, list the volumes, select the volume in question, and then check the volume attributes with the detail volume command. If they are not all set to no, there is your problem.
Hope this helps.