Disable SCSI-Reservation at the driver level ?

Hello !

i have a "problem" with VMWare ESX (not big one, but interesting one - at least for me).

If you dont know VMware ESX - ESX is sort of its own operating system with Linux as a management console OS on top of a hypervisor (vmkernel), just similar to XEN hypervisor with and attached dom0. Besides the drivers in the console OS, the vmkernel loads it´s own drivers, which are derived from Linux drivers.

VMWare ESX refuses to create VMFS Filesystem on SATA disk, attached to a onBoard SAS controller (lsi1068).
When i raid1 two SATA disks, it works, if i use a single SATA disk, the controller seems to "expose" the disk differently to the operating system and creation of a VMFS fails due to missing ability to issue SCSI reservation command.

Ok there is no official SATA support for now, but some controllers work with SATA, because you can either attach SAS and SATA disks to that (LSI1068). Furthermore there are SATA-controllers which can be used with the driver of some SCSI-model (LSI Megaraid 150-4)

Afaik, SCSI reservations being used/needed in shared storage environment (SAN, Shared local attached storage), so i wonder, why it's also being used on local attached disk. Only vmware may give an answer here.

Maybe i can can "workaround" this somehow ?
I couldn`t find a way to stop the vmkfstools (which is used to format blockdevice with VMFS) issueing a SCSI reservation command, but i assume this can probably be done via filtering some syscall (ioctl?) via LD_PRELOAD library - i.e. wrapping vmkfstools - or maybe i can hack this at the driver level, since source of the ESX storage drivers is available for download and can be recompiled. :)

if somebody like to help hacking this - there is a thread at:
http://www.vmware.com/community/thread.jspa?messageID=518182&#518182
thread begins with some related iSCSI issues and discusses SATA issues later on.

regards
Roland

ps:
yes, i know this is somhow "evil" and i shouldnt do that, because something could badly fail - but its for private purpose, for proof of concept and for personal satisfaction. :) i´m not going to use such hack on any production system.

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

There's no SCSI fix for this ... the SAT has no translation for the SCSI reservation commands, largely because there's no corresponding ATA equivalent and even for SCSI devices they may fail anyway. The application should cope with such a failure, so in this case it's the application that needs fixing.

It's most likely done via a SG_IO ioctl() but you should trace the application to be sure.

James

yes, sure i cannot translate a SCSI reservation command into SATA equivalent because SATA doesn`t support.
but i`m unsure, what sense does SCSI reservation does make with local storage, anyway - because there is no concurrent access in this scenario.
ESX is very SAN oriented, and in nearly all cases SCSI is being used as storage, so SCSI reservation will ususally "just work", regardless if being needed or not.
I assume its not really needed with local storage, but im not sure here.
So if the application issues SCSI reservation and i cannot fix the application due to mising source, the only way to fix this is to "fake" a successful SCSI reservation, maybe via syscall modification (LD_PRELOAD) or via driver reporting success on every SCSI reservation command.

thanks, this is a good hint for what i should search for. i will see if i can find a suitable strace package for ESX (ESX doesn`t come with strace) and investigate

regards
roland

----- Original Message ----- From: "James Bottomley" <[email protected]>
To: "roland" <[email protected]>
Cc: <[email protected]>
Sent: Sunday, November 26, 2006 6:46 PM
Subject: Re: Disable SCSI-Reservation at the driver level ?

SAT originally did have persistent reservations and it was dropped and is back on the agenda for SAT-2. A SAT layer (such as the one found in libata) can do more that just translate command, it may also emulate SCSI commands.

And PERSISTENT RESERVE IN and OUT (and maybe the older RESERVE and RELEASE) would be very good candidates for emulation. To do this however libata would need to be a lot more transport aware than it is now. To do such an emulation a SAT layer needs to know:
a) whether it has full control over the SATA device (i.e. there is no other path to it) and failing that, it has some other mechanism such as affiliations in SAS with SMP available to control them
b) the identity of the initiator (port) asking for the reservation.

If libata could do this it would add a lot of value over and above simple command translation.

Doug Gilbert

And more. It's in fact one of the most blatant violations of the Linux 2.4 kernel copyrights. Don't expect support if you use such an illegal product.