Thanks for that appliance, I've been trying to do the same with something with a little larger footprint. However, on boot it just continually scans for devices and returns...
sda Asking for cache data failed
sda Assuming drive cache: write through
Rejecting I/O to offline device.
I'll let it run through (most likely 255 devices) to see if it continues to boot.
Thanks anyway.
it seems that moving the VM from windows (where i originally created it) to a linux host, switches the scsi adapter from buslogic to lsilogic. and since there's no lsilogic driver in the VM it will see something scsi-like but no scsidisks. so it starts a brute scan and asks every device if it's present or not. I'm gonna have to dive a little deeper as to why this happens. if it's somehow possible to force the buslogic driver (which it should if you put that in the .vmx file but somehow it doesn't) it should work ok. if anybody out there knows how to fix this it would save me some time debugging 
.
.
I've been asked by private message to comment on this thread by Brugh...
Although I have no experience directly of this problem or this appliance - I think I can explain what is going with regards to this BusLogic or LSIIogic issue.... because I've had this happen in Windows (Window 2000 default to BusLogic in ESX, and Windows 2003 defaults to LSILogic).
A quick overview of why there is two adapters in ESX and what determines their use and where this information is stored might help clarify this issue.
Firstly, the Virtual Machine's "Monitor" (AKA BIOS) is based on Intel BX440 Motherboard, inside this motherboard VMware present a virtual BusLogic adapter or LSIogic adapter. I believe these were selected based on two criteria. Firstly, VMware have to select a motherboard/adapter which is compatibale with many different operating systems (Windows, Linux, Novell, Solaris). Secondly, as the guest operating system (GOS) is unmodified in the VM (i.e its not paravirtualized) the BusLogic or LSIogic Driver is actually used by the GOS then the driver must be a good one - that offers good I/O instead the GOS, even though in the end those R/W are redirected and intercepted (binary translation) by the hypervisor. Indeed Scott Herold's website - vmguru.com even did performance analysis that showed that under certain circumstances LSIogic out performed BusLogic. The compatiably argument doesn't always hold water. For instance Windows XP lacks both an BusLogic and LSIogic driver, and one must press F6 and supply the driver on a virtual floppy disk (.flp) file....
Secondly, In VMware products the selection dictated in two ways. If you use typical then VMware make the choice for you (LSIogic is the default for most Windows distributions, with exception of Windows 2000 which defaults to Buslogic). Most Linux distributions default LSIogic. I've not install ALL the different distrubutions of Linux in a VM. I'm enthusastic - but that not enthusastic! This default behaviour can be over-ridded by using the "custom" option. So it is entirely possible to give Windows 2000 an LSIlogic controller - but you would have to download the driver from LSIogic website, and provided it as a floppy to the GOS. Just like in the Windows XP situation decided earlier.
Where is this configuration stored? In two places. The VMX file would contain references to the controller type. Additionally, the first file that makes up a virtual disk. The first file that makes up a virtual disk is actually just a txt file (metadata file) which also includes a descriptor of the type of controller used with that disk.
Once you know this - perhaps you guest of some of the gotchas associated with this... Say you only have the virtual disk - and not the VMX file. THen you would have to create the VMX wizard with the Create New VM Wizard using the "Use an existing disk" option. If the VMX file has "use BusLogic" but the virtual disk has "use LSIogic". Then some unpleasant pop-ups can be created (especially in ESX 3.x.x). You might not get these prompts in other VMware products (I don't know VMware Workstation/Server well enough to comment). Secondly, this difference is enough to cause a kernel panic in Linux or BSOD in Windows - in fact instructors like myself will often create this error in troubleshooting section of the course - to see if the student can work out the solution to problem.
Another reason it could occour is if you use "typical" for creating the VM. Using typical does not show what controller type is being used. So you could be selecting a GOS from the pull down list that default to LSIogical but the virtual disk has in its metadate "use BusLogic"...
Another reason is that one Linux distribution might default to BusLogic and another to LSIogical. So selecting the wrong distribution from the pull-down list could cause the problem...
This is what I think is happening....
There are couple of work arounds and solutions.....
1. Appliance vendors should clearly outline how to create the VMX file - appropriate to the virtual disks. Virtualization vendors should select disk formats that work across VMware Platforms - such as not using IDE drives - which work just fine in VMware Workstartion but are not supported in ESX (Please, Please let not start any flames on this old chestnut!). Where possible the appliance should offer all the files (vmx, nvram, vmdk, log) that make up a VM or use the OVT format that allows for the downloading of virtual appliance direct into things like Virtual Infrastructure 3.5. The only problem I see with me saying this is that VMX files and VMDK files in Workstation differ greatly from ESX. I speak from personal experience with the "Ultimate Deployment Appliance" which I host on RTFM. It comes in both an ESX and Workstation format....
2. CAT or type the contents of the metadata file. This will at the very least tell you what type of controller was used to create the virtual disk.
3. Read prompts properly when powering on the VM. Admittedly, these are often quite cyptic and won't help novices resolve these kind of boot/controller problems...
Hope you have found this useful...
I hope have added something to discussion - and not got hold of the wrong end of the stick. If I have - sorry!
Kind Regards
Mike Laverick
RTFM Education
http://www.rtfm-ed.co.uk
http://www.vi3book.com
Although I have no experience directly of this problem or this appliance - I think I can explain what is going with regards to this BusLogic or LSIIogic issue.... because I've had this happen in Windows (Window 2000 default to BusLogic in ESX, and Windows 2003 defaults to LSILogic).
A quick overview of why there is two adapters in ESX and what determines their use and where this information is stored might help clarify this issue.
Firstly, the Virtual Machine's "Monitor" (AKA BIOS) is based on Intel BX440 Motherboard, inside this motherboard VMware present a virtual BusLogic adapter or LSIogic adapter. I believe these were selected based on two criteria. Firstly, VMware have to select a motherboard/adapter which is compatibale with many different operating systems (Windows, Linux, Novell, Solaris). Secondly, as the guest operating system (GOS) is unmodified in the VM (i.e its not paravirtualized) the BusLogic or LSIogic Driver is actually used by the GOS then the driver must be a good one - that offers good I/O instead the GOS, even though in the end those R/W are redirected and intercepted (binary translation) by the hypervisor. Indeed Scott Herold's website - vmguru.com even did performance analysis that showed that under certain circumstances LSIogic out performed BusLogic. The compatiably argument doesn't always hold water. For instance Windows XP lacks both an BusLogic and LSIogic driver, and one must press F6 and supply the driver on a virtual floppy disk (.flp) file....
Secondly, In VMware products the selection dictated in two ways. If you use typical then VMware make the choice for you (LSIogic is the default for most Windows distributions, with exception of Windows 2000 which defaults to Buslogic). Most Linux distributions default LSIogic. I've not install ALL the different distrubutions of Linux in a VM. I'm enthusastic - but that not enthusastic! This default behaviour can be over-ridded by using the "custom" option. So it is entirely possible to give Windows 2000 an LSIlogic controller - but you would have to download the driver from LSIogic website, and provided it as a floppy to the GOS. Just like in the Windows XP situation decided earlier.
Where is this configuration stored? In two places. The VMX file would contain references to the controller type. Additionally, the first file that makes up a virtual disk. The first file that makes up a virtual disk is actually just a txt file (metadata file) which also includes a descriptor of the type of controller used with that disk.
Once you know this - perhaps you guest of some of the gotchas associated with this... Say you only have the virtual disk - and not the VMX file. THen you would have to create the VMX wizard with the Create New VM Wizard using the "Use an existing disk" option. If the VMX file has "use BusLogic" but the virtual disk has "use LSIogic". Then some unpleasant pop-ups can be created (especially in ESX 3.x.x). You might not get these prompts in other VMware products (I don't know VMware Workstation/Server well enough to comment). Secondly, this difference is enough to cause a kernel panic in Linux or BSOD in Windows - in fact instructors like myself will often create this error in troubleshooting section of the course - to see if the student can work out the solution to problem.
Another reason it could occour is if you use "typical" for creating the VM. Using typical does not show what controller type is being used. So you could be selecting a GOS from the pull down list that default to LSIogical but the virtual disk has in its metadate "use BusLogic"...
Another reason is that one Linux distribution might default to BusLogic and another to LSIogical. So selecting the wrong distribution from the pull-down list could cause the problem...
This is what I think is happening....
There are couple of work arounds and solutions.....
1. Appliance vendors should clearly outline how to create the VMX file - appropriate to the virtual disks. Virtualization vendors should select disk formats that work across VMware Platforms - such as not using IDE drives - which work just fine in VMware Workstartion but are not supported in ESX (Please, Please let not start any flames on this old chestnut!). Where possible the appliance should offer all the files (vmx, nvram, vmdk, log) that make up a VM or use the OVT format that allows for the downloading of virtual appliance direct into things like Virtual Infrastructure 3.5. The only problem I see with me saying this is that VMX files and VMDK files in Workstation differ greatly from ESX. I speak from personal experience with the "Ultimate Deployment Appliance" which I host on RTFM. It comes in both an ESX and Workstation format....
2. CAT or type the contents of the metadata file. This will at the very least tell you what type of controller was used to create the virtual disk.
3. Read prompts properly when powering on the VM. Admittedly, these are often quite cyptic and won't help novices resolve these kind of boot/controller problems...
Hope you have found this useful...
I hope have added something to discussion - and not got hold of the wrong end of the stick. If I have - sorry!
Kind Regards
Mike Laverick
RTFM Education
http://www.rtfm-ed.co.uk
http://www.vi3book.com
hey mike,
thanks for replying. i think the buslogic/lsilogic issue is clear. always helps if somebody writes down the whole story and not just a statement or two
as for your suggestions, i think i followed them pretty close. i originally created the base JeOS on a windows workstation 6 and set compatibility with vmware server 1. installed the os, stripped it down and saved all 5 base-files (vmdk, vmx, vmxf, vmsd, nvram) into the package. i created the VM using buslogic since the kernel i wanted to use doesn't hold LSI drivers. now in workstation it worked perfectly but when put on vmware server (windows and linux host both! also vmware server 1 and 2 both!) it does see some sort of scsi, but can't index the disks.
i tried creating a new vm in vmware server, setting buslogic as scsi adapter type but got the same error. then i took the jeos installdisk from ubuntu (which doesn't have lsilogic drivers either!), created a new vm, booted the CD and to my great surprise, it got the same error! no disks. this makes one wonder about the buslogic implementation of vmware server.
so i created a new VM in vmware server again, did a new install of the ubuntu OS, switched kernel, removed lsi logic and *blink*blink* it worked. moved it to workstation and it still worked.
now this was late at night but i think i noticed that when i moved the WS created VM to VS (yay abbrevs!) it asked me if it would switch the scsi adapter to lsilogic for me. i answered no. when the VS created VM moved to WS, it asked me if it would switch the adapter type to buslogic.. i answered yes. hmm curious.
seems that dispite all compatibility of a VM between the different vmware versions and products, there's still things different between them that in (proably) rare occasions makes things fail.
i have yet to test these appliances on esx, but so far the other ones import without problems (not using vmware converter, but create a new vm, import disk and attach it). regarding this whole story i'll go give that a try soon and see what happens. i'll post the results here.
leason learned: create your VM on vmware server. moving from workstation to server induces more problems than the other way round. at least for me it did.
Well, it was a stab in the dark...
You clearly I have more experience of this than me - in fact I have never even installed or used VMware Server - so I really have zero knowledge of the product and its peculairities...
One of the annoyances I think with VMware is this. They trumpet how things like virtualization free from your physical hardware - especially ESX. It really doesn't matter if the VM executes on a Dell or HP box... The trouble comes not with that difference - but when you come to move VMs from one virtual platform to another (I've done this quite a bit to and from workstation ESX). So you get the IDE Vs SCSI difference - and you also get differences in the VMX file. True - much of these difference are there for good reason such as compatiability or performance - but the perception in the user base is "the VM should be portable from any VMware virtual platform to another VMware virtual platform...."
VMware convertor to some degree has addressed this - for example I could successfully move a Windows XP VM on IDE drives on Workstation to ESX using SCSI drives with a few simple clicks of the most. This is certainly much easier than old method that involved using the vmware-virtualdiskmanger tool and text editors to convert IDE to SCSI... However, when I came to do the same test with a Linux VM... convertor failed....
Anyway, now I have replied to this post - I will see all subsequent posts - so I will keep an eye on this issue...
Kind Regards
Mike
You clearly I have more experience of this than me - in fact I have never even installed or used VMware Server - so I really have zero knowledge of the product and its peculairities...
One of the annoyances I think with VMware is this. They trumpet how things like virtualization free from your physical hardware - especially ESX. It really doesn't matter if the VM executes on a Dell or HP box... The trouble comes not with that difference - but when you come to move VMs from one virtual platform to another (I've done this quite a bit to and from workstation ESX). So you get the IDE Vs SCSI difference - and you also get differences in the VMX file. True - much of these difference are there for good reason such as compatiability or performance - but the perception in the user base is "the VM should be portable from any VMware virtual platform to another VMware virtual platform...."
VMware convertor to some degree has addressed this - for example I could successfully move a Windows XP VM on IDE drives on Workstation to ESX using SCSI drives with a few simple clicks of the most. This is certainly much easier than old method that involved using the vmware-virtualdiskmanger tool and text editors to convert IDE to SCSI... However, when I came to do the same test with a Linux VM... convertor failed....
Anyway, now I have replied to this post - I will see all subsequent posts - so I will keep an eye on this issue...
Kind Regards
Mike
