fully confirmed. ;-(
host: gentoo with kernel 2.6.22
guest: debian etch
This is a real BIG problem. Also on OpenSuse 10.2 Buslogic Adapter (win2003 as host)!!!!
It searches for all sd* devices at boot time.
also here, gentoo 2.6.22 host, ESVA 1.7 appliance guest, which is 2.6.17-1.2142_FC4 i686.
booting with the parameter max_scsi_luns=1 does not help.
I can also confim this, rolling back to 1.0.3 fixed the error.
Host OS INFO (VM Server)
Debian 4.0 Etch
Client Info (VM machine)
Debian 4.0 Etch
client drive 8.0gb SCSI (Virtualized SCSI from the Host SATA)
I can confirm a similar problem with a Fedora 7 guest after upgrading to Server 1.0.4. The driver actually tries to iterate through all possible scsi device nodes -- it starts at /dev/sda, which is a valid device in my guest, but then continues through the alphabet to sdz and on to sdaa, sdab, etc. I gave up waiting at sdab.
My guest is also using the buslogic driver, since I experienced the problem (fixed in 1.0.4, ironically) of not being able to use the lsilogic driver with Fedora 7.
So, I edited my .vmx file to read
scsi0.virtualDev = "lsilogic"
and the guest now boots fine.
So, since this seems to be a confirmed bug, how do we notify the VMWare developers? Do they actually follow this discussions?
Can someone confirm this bug in other VMWare products which have been updated recently (VMWare Player, Workstation, ESX Server)?
I can confirm this as well with Fedora 7 Host and Guests. However if I change the virtual device to lsilogic, my VM's are not bootable...
I guess I can downgrade, or deal with the 30 minutes startup time while all the SCSI busses are scanned. So did they break a virtual terminator or something?
Same problem as well. I am using Slackware 12, tested a few kernels: 18.104.22.168/8 and 2.6.23-rc7/8 - all showing same symptoms.
Switching back to version 1.0.3 for now.
To answer my own question: This error doesn't occur with VMware Player 1.0.5 (released at the same day as VMWare Server 1.0.4) under Windows host with Debian Linux guest. So this bug seems to be specific to VMware Server 1.0.4.
Hi guys, is there a solution to this anywhere? I'm possibly being dense but I can't find anything via Google/this forum.
it's probably not a big problem to modify the BusLogic sources and hardcode it to only scan the first LU on the first device on the first chain/bus.
a similar patch was done by Petr to make LSI controller work with 2.6.22 and 1.0.3.
it might also be intersting to see what happens if you add some "scratch" disks to scsi slots 0:1 and 1:0, 1:1 etc...
Same problem here:
Same problem here on OpenSuse 10.1
Rolling back to 1.0.3 and VM sees only one disk again
The following solution is valid for openSUSE 10.2 (and perhaps older versions):
Change the BusLogic adapter to LSI by adding "scsi0.virtualDev = "lsilogic" to your machine.vmx text file. When VMware restarts the Machine, you will be asked to change the disk type. Confirm it. Then you will probably have to make a repair installation by booting from the CD/DVD in order to add the LSI driver to your initrd. Afterwards, the hard disk will be recognized again and the system will come up as usual.
Remember: Always perform a backup before editing the config of your VM or making a repair installation.