wsaxon wrote:
I realize none of the SCO products are officially supported, but I do have several OpenServer 5.0.x and UnixWare 7.1.4 guests running in my ESX cluster. For the most part they work fine, except in two situations:
1. storage network congestion results in 'unrecoverable errors' reading/writing from the virtual disk
2. any vmotion event, storage vmotion event or 'pause' of the guest results in a panic and memory dump.
It's tricky but not impossible to get both of these OSs running under ESX with the buslogic scsi adapter and flexible network adapter. Unfortunately, having them in my cluster either limits my ability to do vmotion or aggravates my users (usually the latter). Are there any special setup tricks or advanced/undocumented options people are aware of that will allow these guests to work better?
My understanding is that they work fine in VMWare Server - with the IDE adapter. It sure would be nice if ESX provided an IDE adapter for virtual disks.
ESX 4.0 and ESXi 4.0, which were recently released, do support virtual IDE disks. They also officially support the following SCO OS releases: OpenServer 5.0.6, OpenServer 5.0.7 MP5, UnixWare 7.1.1 MP5, UnixWare 7.1.4 MP4.
I believe both of your issues are caused by the same problem, which is that ESX sends a SCSI BUSY error to guest SCSI requests under certain circumstances when I/O completion will be delayed. SCO OpenServer SCSI drivers are documented as being optionally allowed to retry a BUSY, but neither the BusLogic "blc" nor LSI Logic "lsil" drivers actually do so. After all, it's optional. Meanwhile the next layer up, the OSR5 HTFS filesystem, sees any BUSY as a hard I/O error. Other guest OSes know that BUSY means "retry this I/O, it will go through soon".
LSI was working on an "lsil" driver update whose version was going to be at least 1.04.10 (probably higher). This was supposed to do internal retries. I do not know what eventually became of that, I've never been able to find a public version higher than 1.04.09.
In my own testing I have not found it quite that easy to trigger the errors. To get a reliable reproduction of the problem, I had to badly contort my ESX networking -- deliberately routing vmotion through a 10Mbps router, stuff like that. Actually one of my best reproduction scenarios was where I had the OSR5 virtual disk stored on an NFS mount, where the NFS server was a VM on the same ESX host and its CPU resource was limited to about 100 MHz. But I digress.
For your current setup I recommend making sure the vmotion network is fast and uncongested; and try to shake loose a newer "lsil" driver from LSI Logic, then switch the VMs to that adapter.
I also generally had better luck using the Intel e1000 virtual adapter and the corresponding OSR5 "eeG" driver (which you have to download from ftp.sco.com -- links are given in the above VMware docs).
I've experimented less with UnixWare. I was never aware of a disk problem like with OSR5, so I'm surprised to hear you describe the two as behaving so similarly. The OSR5 and UW7 kernels are only distantly related (like Win98 to NT 4.0).
This is new territory, please update this thread with any improvements you achieve by changing drivers, going to ESX/ESXi 4, improving network connectivity, etc.
>Bela<
