John, > When I expose a ZFS volume as an iSCSI LUN block zero on the initiator > appears at offset 0x10000 on the actual volume. I've confirmed this using > hexedit at both the initiator (CentOS and Windows) and the target (osol) ends. > > This is a pain. If I mirror a remote disk to an iSCSI target I can't then > attach the volume to a VirtualBox VM and boot it.
Prior to snv_126, COMSTAR stored its volume metadata within the first blocks of any backing store. From snv_126 on, for newly created LUNs on ZVOLs, COMSTAR stores its volume metadata in ZFS properties. An iSCSI LUN when presented to an iSCSI initiator using COMSTAR, is just a collection of unformatted blocks. Before most OSes can use an iSCSI LUN for the first time, the LUN needs to be partitioned, likely with fdisk (http://en.wikipedia.org/wiki/Fdisk) before the LUN can used. This is likely the cause of the offset you are seeing above. When the same ZVOL is presented to VirtualBox, it is just a collection of blocks, no therefore no partitioning is needed, so the existing partition data is the problem. VirtualBox has direct support of iSCSI LUNs using "VBoxManage addiscsidisk ...", so VirtualBox can access iSCSI LUNs from COMSTAR, same as the virtual host. - Jim > > Is there any way to force an iSCSI LUN to start at offset 0x00000 rather than > 0x10000? > -- > This message posted from opensolaris.org > _______________________________________________ > storage-discuss mailing list > storage-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
