What linux distro for the guest? Reason I ask is because I have seen something simular and to resolve it I just had to shutdown the haldaemon and smartd daemons. Also, sometimes disconnecting the CDROM drive can fix strange errors.
This is just what I have seen and done to fix it, why it happens I do not know.
Guest Linux distribution is basically Ubuntu 6.10.
As you see, the problem starts while booting. There's no hald/smartd loaded. Virtual IDE CDROM is disconnected.
Booting process takes quite a long time compared to the time it took before the problem appeared with Vmware Server 1.04.
I wonder what these accesses to non-existant devices (sdd, sde, ...) mean.
After booting, these errors continue with device names constantly increasing (..., sdj, sdk, ... ).
Output of dmesg is attached.
dmesg.log 123.1 K
Come on, someone! Same problem with Fedora 7.
There are a few posts here, but I could not find any other info anywhere else.
My system runs on XP host and Fedora 7 is the guest. I just don't know why I upgraded. If it ain't broke don't fix it. Right!
I hope someone from VMWare is reading this.
I finally solved this problem by adding scsi0.virtualDev = "lsilogic" (as this seems to be the default SCSI hostadaptor when adding a new vm) to my configuration file.
On the first boot of the VM, Vmware warned that disks used to be on a BusLogic adaptor. Accepted this warning, started up the vm, everything runs fine now.
I tried that and it did not help me :(. After doing it, Fedora is not able to find the filesystem /dev/root and so on...
I have the same problem with Fedora 7. I have seen a lot of threads suggesting 'chage to lsilogic' which doesn't work, 'change to ide' which doesn't work, changes to any part of the vm config process hasn't had an effect. Each iteration of the test has the same error, takes an hour or two, there's two of us here that have been looking for the right config combination since last Thursday.
As an extra piece of info, every time Fedora 7 fails to see a (nonexistant) SCSI device due to this, a line appears in vmware.log on the host machine:
Oct 15 15:30:54: vcpu-0| SCSI: TEST UNIT READY (0x00) for LUN.
Same line, over and over, nothing but the timestamp changes. The failure counts through /dev/sda(a-z), sdb(a-z), sdc(a-z), and sdd(a-z) before counting through the rest of /dev/sd(e-z) with no fourth character and then finally continuing to boot. It takes roughly ten seconds between each failure. It seems to have no effect on the OS once running, but it makes rebooting a twenty minute process. Updating to the newest kernel has no effect.
In my case I can reproduce this on a Windows XP box running vmware server 1.0.4 with Fedora 7 as the guest and a Red Hat ES Linux 4 box running vmware server 1.0.4 with Fedora 7 as guest.
I have a paid license for an ESX server, but I can't replace the rest of my dev environment with the other 4 planned ESX boxes until I'm sure I can run Fedora on it, since the execs here chose to standardize on RHEL4 and Fedora 7.
I'm seeing very similar issues with a CentOS 4.4 Host and Ubuntu 7.10 Server guest. The installer takes forever to boot due to the scanning of every single sdX device, then the detection of the CD-ROM drive fails for some reason. The installer craps out with a "No common CD-ROM drive was detected" error -- funny this is I'm using an ISO !
FYI, I just downgraded VMware server to 1.0.3 and the problems all went away. Looks like I'll steer clear of 1.0.4 until these bugs (features?) are ironed out.
I had the exact same problem running VMWare-server on Ubuntu 6.06 LTS. I choosed Ubuntu 6.06 because it worked perfectly on all my other machines with WMware 1.03.
But with 1.04 the performance was horrible and i also got thet "sddd" thing loding problem, and also alot of other strange errors when booting of linux vm's..
Simply downgraded to 1.03 and everything is workign like a charm! And the performance boost i AMAZING!! (and I don't mean the difference for time spent waiting for all the /dev/sdx things to load..)
Thank you for the tip!
Moved a vm from 1.0.3 ubuntu 64 bit host to a 1.0.4 windows 64 bit host and started having this problem. scsi0.virtualDev = "lsilogic" seems to have fixed it but I'd really like to know more about why it happened.
>I'd really like to know more about why it happened.
it`s because programmers are not perfect.
some things get fixed, some things get added - and some things get broken. it`s called regression and that always happens. take a look at the linux kernel mailing list and you get a clue
wow, that was a bunch of random comments...
I am a programmer
It's only regression if it's happened before, otherwise it's just a bug. Regression doesn't "always happen", it's really the most preventable type of software flaw, so I really hope it's not a regression.
Sending anyone but a kernel developer to the kernel mailing list is like telling someone to read a physics book when they ask how to put gas in their car. I came here for my clue and actually found most of it. Maybe the rest isn't available here but it seemed worth asking about.
I'm just interested in some details, not finger pointing. They might
give me ideas for working around the problem in the future, or they
might just satisfy my curiosity while making me more confident in the
software I'm using since the explaination demonstrates that they at
least understand the problem themselves.
>It's only regression if it's happened before, otherwise it's just a bug.
sure? for me, a regression is a bug which has been introduced and which didn`t exist before.
new software release: new features, fixed bugs and - new bugs caused by the new features and by the bugfixes.
maybe i`m wrong, so please someone correct me.
Regression doesn't "always happen"
race conditions don`t always happen, too. you didn`t meant these?
>Sending anyone but a kernel developer to the kernel mailing list
i only wanted to point out to see what regression means. that word is somewhat popular there - so just search the lkml archive for regression. sure it wasn`t meant that they should post there....
>I'm just interested in some details, not finger pointing.
we can`t get into the details because we don`t have the sourcecode !
I have upgraded VMWare 1.0.3 Server on a linux System to 1.0.4 and the same error comes,
now i readed the configs and saw that there was scsi0.present=true.
after changing this to false everything was ok ( i only had ide0:0 -- hda1 and ide1:0 cd-rom)
maybe someone help this
in a client with scsi hdd´s i think the bus option helps ...