VC 2.5 does not show /dev/cdrom

[wilson94t]

We've had a long practice of using /dev/cdrom as the host device setting for the VM CDROM's on our ESX servers. Recently, since upgrading to ESX 3.5 Update2, we have noticed that our servers do not offer this setting anymore by default. We've also noticed that some of our servers default to /dev/hdb instead of /devhda.

The thing is, /dev/cdrom is a valid selection in all cases, so why can't I use it?

This field is also no longer a free text field, we can only use the drop downs. I guess i can understand the reasoning behind not wanting someone to make a mistake, but this is turning into yet another thing that vmware is taking away from the product. Anyone have a similar situation or work around?

[Texiwill]

Hello,

CHeck /dev for a link from a device to cdrom. The VIC is not reading links anymore. What it is showing is the possible CDROMs that you could use based on the devices found on the host.

hda/hdb are IDE, the others are SCSI. I would claim this is a bug more than anything. Open up a support case with your VMware Support Representative as the link still exists.

However, I tend to use ISOs and client side drives these days more than the local CDROM drive.

Best regards,

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.

Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links

[wilson94t]

Sure, I'm familiar with links... and they are there. Anyone know if this happens on U3? I'm on U2 at the moment.

I find stuff like this all the time but don't report it since i have this silly agreement with HP - they give me only X number of requests each year. if i went direct to VMware, i'd have unlimited requests like anyone else with an ELA.

I hate to burn tickets for which the HP guys do no work, and just pass along our findings.

Can someone confirm this is the case on the latest ESX 3.5 / VC 2.5 patch release?

[Texiwill · Accepted solution]

Hello,

Yes it is the same way on ESX 3.5U3 w/VC2.5 U3. It is up to you on whether you want to burn a ticket on this. You could try open an SR off the VMware Website and bypass HP. If it is really important to you, I would make the call but since you can get the link to where /dev/cdrom points you can pick that out of the list instead of using /dev/cdrom..... Relatively simple work around.

Best regards,

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.

Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links

[wilson94t]

Ed,

The problem with not having /dev/cdrom has little to do with actually using the CD-ROM and more to do with problems with the hypervisor and VMotion. If the setting for the "CD-ROM" is set to client device, 99% of the time, this works out OK. It's that 1% that really get our attention and vmotion fails to operate. We've had open cases with VMware about this before. Sometimes a mgmt-vmware restart can help, sometimes it's too bad so sad, down your VM's and bounce ESX.

As such, we had a policy with 3.0.1 that we would always use /dev/cdrom as the default setting. We've about 5000 VM's at this point, I assume that some smaller environment may never see such occurance, and unless someone is really keeping track of larger ones, getting down to this as a consistent symptom may not be all too regular. Depending on the tech at VMware you get, you'll get anything from "yeah, i've seen that... " to " what? that never happens, it must be something else."

[wilson94t]

Thanks for confirming this is the same on VC2.5/ESX 3.5 with U3.

[Texiwill]

Hello,

I see your concern. My default settings are 'not connected' and the other is unimportant.... As long as the CDROM is 'not connected' then VMotion will have no problems.

Best regards,

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.

Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links

[wilson94t]

I understand why you say that, and in most cases, i really would agree. The problem is, after working with a large enivornment, things break that are not supposed to. Things that are supposed to work , sometimes fail. I can't tell you why vmotion fails with client device selected - even if there is no active connection to the client device. I can only tell you that there are times when this gets hung up (for days, we've tried to let it time out) and it simply will not recover. I fwe get the client device setting reconfigured to point back at the local CDROM drive - magic happens and it begins to work again.

keep in mind that we have verified that the client device is not connected. we can disconnect and reconnect to it and we can observe the disconnection and reconnection within the VM. That part works! the observable condition is that it can break vmotion on occasion.

As you say, it is unexpected, and normally, using client device does not cause a problem, vmotion works fine. Problems are often found at volume.

Anyway, i'll do the case with VMware. Thanks for your replies.