|
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. 
|
|
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 |
.
