zfs discuss - Feb 2010 - Mounting a snapshot of an iSCSI volume using Windows

I have a single zfs volume, shared out using COMSTAR and connected to a Windows
VM. I am taking snapshots of the volume regularly. I now want to mount a
previous snapshot, but when I go through the process, Windows sees the new
volume, but thinks it is blank and wants to initialize it. Any ideas how to get
Windows to see that it has data on it?

Steps I took after the snap:

zfs clone <snapshot> data01/san/gallardo/g-recovery
sbdadm create-lu /dev/zvol/rdsk/data01/san/gallardo/g-recovery
stmfadm add-view -h HG-Gallardo -t TG-Gallardo -n 1
600144F0EAE40A0000004B6B59090003

At this point, my server Gallardo can see the LUN, but like I said, it looks
blank to the OS. I suspect the ''sbdadm create-lu'' phase.

Any help to get Windows to see it as a LUN with NTFS data would be appreciated.

Thanks,
Scott
-- 
This message posted from opensolaris.org

On Thu, Feb 04, 2010 at 04:17:17PM -0800, Scott Meilicke
wrote:
> At this point, my server Gallardo can see the LUN, but like I said, it
looks blank to the OS. I suspect the ''sbdadm create-lu'' phase.
Yeah, try the import version of that command.

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100208/092a8a56/attachment.bin>

Thanks Dan.

When I try the clone then import:

pfexec zfs clone data01/san/gallardo/g at zfs-auto-snap:monthly-2009-12-01-00:00
data01/san/gallardo/g-testandlab
pfexec sbdadm import-lu /dev/zvol/rdsk/data01/san/gallardo/g-testandlab

The sbdadm import-lu gives me:

sbdadm: guid in use

which makes sense, now that I see it. The man pages make it look like I cannot
give it another GUID during the import. Any other thoughts? I *could* delete the
current lu, import, get my data off and reverse the process, but that would take
the current volume off line, which is not what I want to do.

Thanks,
Scott
-- 
This message posted from opensolaris.org

Use create-lu to give the clone a different GUID:

sbdadm create-lu /dev/zvol/rdsk/data01/san/gallardo/g-testandlab

--
Dave

On 2/8/10 10:34 AM, Scott Meilicke wrote:
> Thanks Dan.
>
> When I try the clone then import:
>
> pfexec zfs clone data01/san/gallardo/g at
zfs-auto-snap:monthly-2009-12-01-00:00 data01/san/gallardo/g-testandlab
> pfexec sbdadm import-lu /dev/zvol/rdsk/data01/san/gallardo/g-testandlab
>
> The sbdadm import-lu gives me:
>
> sbdadm: guid in use
>
> which makes sense, now that I see it. The man pages make it look like I
cannot give it another GUID during the import. Any other thoughts? I *could*
delete the current lu, import, get my data off and reverse the process, but that
would take the current volume off line, which is not what I want to do.
>
> Thanks,
> Scott

Sure, but that will put me back into the original situation.

-Scott
-- 
This message posted from opensolaris.org

Ah, I didn''t see the original post. If you''re using an old
COMSTAR
version prior to build 115, maybe the metadata placed at the first 64K 
of the volume is causing problems?

http://mail.opensolaris.org/pipermail/storage-discuss/2009-September/007192.html

The clone and create-lu process works for mounting cloned volumes under 
linux with b130. I don''t have any windows clients to test with.

--
Dave


On 2/8/10 11:23 AM, Scott Meilicke wrote:
> Sure, but that will put me back into the original situation.
>
> -Scott

That is likely it. I create the volume using 2009.06, then later upgraded to
124. I just now created a new zvol, connected it to my windows server,
formatted, and added some data. Then I snapped the zvol, cloned the snap, and
used ''pfexec sbdadm create-lu''. When presented to the windows
server, it behaved as expected. I could see the data I created prior to the
snapshot.

Thank you very much Dave (and everyone else).

Now,
-- 
This message posted from opensolaris.org

That sounds very interesting and for me it sounds like a bug. 

I expect this is what happened: 
1) Create a zvol with meta data in the first 64k (so data starts at 64k)
2) Updated to 124
3) Comstar propably still using the first 64k of the zvol no tmigrating the data
off (so data starts at 64k)
4) Created a snap+clone (still containing the meta data in the first 64k)
5) Created a new zvol (comstar now using the zfs property of the metadata, data
is starting at 0k. Thus the FS and Partitioning information is unaligned at
+64K)

I think this will cause problems for everyone updating to a later version,
because they can not create snapshotting / cloning. Even worse ! They can also
not use send/receive, because the metdata is also sent via rent/receive.

What is the migration path ? 

I think comstar should have auto-migration like this: 

If (my_comstar_version_uses_zfs_property &&
zvol_has_metadata_in_first_64lk) {
   migrate data off the first 64k to the zfs property
   set a flag in the 64k zvol on disk metadata that this has been migrated
   export migrated zvols with a 64k byte offset
}

Is this upgrade problem a "forgotten problem" by the Comstar guys ? 

I would say yes.
-- 
This message posted from opensolaris.org

I plan on filing a support request with Sun, and will try to post back with any
results.

Scott
-- 
This message posted from opensolaris.org

Hello, 

wanted to know if there are any updates on this topic ?

Regards, 
Robert
-- 
This message posted from opensolaris.org