zfs discuss - Jul 2010 - Move Fedora or Windows disk image to ZFS (iScsi Boot)

I''ve found plenty of documentation on how to create a ZFS volume, iscsi
share it, and then do a fresh install of Fedora or Windows on the volume.

What I can not find is how to take an existing Fedora image and copy the
it''s contents into a ZFS volume so that I can migrate this image from
my existing Fedora iScsi target to a Solaris iScsi target (and of course get the
advantages of having that disk image hosted on ZFS).

Do I just zfs create -V and then somehow dd the Fedora .img file on top of the
newly created volume?

I''ve spent hours and have not been able to find any example on how to
do this.
-- 
This message posted from opensolaris.org

On 07/18/10 17:39, Packet Boy wrote:
> What I can not find is how to take an existing Fedora image and copy
> the it''s contents into a ZFS volume so that I can migrate this
image
> from my existing Fedora iScsi target to a Solaris iScsi target (and
> of course get the advantages of having that disk image hosted on
> ZFS).
>
> Do I just zfs create -V and then somehow dd the Fedora .img file on
> top of the newly created volume?
Well, you could simply mount the iscsi devices and choose any method
that is suitable to copy the existing volume. For example Fedora will
create /dev/sd* for each iscisi device it knows about, so you see an
empty drive at that point and the problem simply devolves to whatever
you would do if you wanted to use a new physical drive. nftsclone
works for MSWindows, I suppose dd might work for Linux, although
the disk geometries would have to be identical and you''d have to
copy the entire disk. It might be safer to create new file systems
on the new disk, and use cpio or even tar to copy everything. Shame
it''s so hard to do mirroring with Fedora, so the ZFS mirror trick
might be too difficult.
> I''ve spent hours and have not been able to find any example on how
to
> do this.
Making the new drive bootable is the real problem since it will probably
not have the same identifier. For sure you''d have to edit grub ion the
new drive and perhaps run grub interactively to install a boot loader.

Hope this helps -- Frank

> I''ve found plenty of documentation on how to create a
> ZFS volume, iscsi share it, and then do a fresh
> install of Fedora or Windows on the volume.
Really?  I have found just the opposite: how to move your functioning
Windows/Linux install to iSCSI.

I am fumbling through this process for Ubuntu on a laptop using a Frankenstein
mishmash of PXE -> gPXE -> menu.cfg -> sanboot -> grub -> initrd
-> Ubuntu.

The initial install is through Ubuntu''s netboot pxelinux.0 files which
make iSCSI installs fairly painless as long as there are no initiator
restrictions on the LUN.

I couldn''t find the magic formula in dnsmasq (on my router) to set the
target and initiators which is needed to allow multiple devices to see their own
iSCSI volumes, so I used a ${uuid} suffix for both in a gPXE menu.cfg file.

Stranger still, it seems that only one LUN can be allocated system-wide, so I
can''t map LUN0 to target iqn.foo and another LUN0 to target iqn.bar,
which means each initiator gets a non-zero LUN.  It doesn''t seem to
bother the iSCSI stacks, but it bugs me.

The other poster is correct, all of this has to match in gPXE, initrd and
Ubuntu.

Either I am more daft than I thought (always a safe choice), or the same thing
is very difficult in Windows.  To be honest, I have not braved a raw Windows
install to iSCSI yet, but will once I conquer Ubuntu.

The advantage of going straight to iSCSI is that the zvol can be arbritrarily
large and you only allocate the blocks which have been touched.  If you install
to a disk then do the dd if=localdisk of=iSCSIdisk approach, the zvol will be
completely allocated.  Worse, the iSCSI volume is limited to the size of the
original disk, which kind of misses the point of thin provisioning.

Good luck.
-- 
This message posted from opensolaris.org

OK...decided to do a fresh install of Fedora (FC12)...install completed to iScsi
target...now trying to boot it.

Fedora is finding the target, then then throwing an "I/O error".  When
I snoop on the ZFS server I see the following:

1) Initiator connects and logs into the target OK
2) Initiator issues a iScsi opcode 0x25 (Read Capacity)
3) Target responds with a ''Illegal Request'' response (see
below).

Based on my read of the Iscsi RFC on a *target* is supposed to use opcode 0x25
and here we have the Fedora initiator doing it so it seems like the Solaris
target is responding properly and the Fedora initiator seems broken...anyone
understand this?

[code]
[Reassembled TCP Segments (72 bytes): #122(48), #123(22), #124(2)]
    [Frame: 122, payload: 0-47 (48 bytes)]
    [Frame: 123, payload: 48-69 (22 bytes)]
    [Frame: 124, payload: 70-71 (2 bytes)]
iSCSI (SCSI Response)
    Opcode: SCSI Response (0x21)
    Flags: 0x82
        ...0 .... = o: No overflow of read part of bi-directional command
        .... 0... = u: No underflow of read part of bi-directional command
        .... .0.. = O: No residual overflow occurred
        .... ..1. = U: Residual underflow occurred
    Response: Command completed at target (0x00)
    Status: Check Condition (0x02)
    TotalAHSLength: 0x00
    DataSegmentLength: 0x00000016
    InitiatorTaskTag: 0x00000002
    StatSN: 0x00000003
    ExpCmdSN: 0x00000001
    MaxCmdSN: 0x0000000f
    ExpDataSN: 0x00000000
    BidiReadResidualCount: 0x00000000
    ResidualCount: 0x00000000
    Request in: 121
    Time from request: 0.000300000 seconds
    SenseLength: 0x0014
SCSI: SNS Info
    [LUN: 0x0001]
    Valid: 0
    .111 0000 = SNS Error Type: Current Error (0x70)
    Filemark: 0, EOM: 0, ILI: 0
    .... 0101 = Sense Key: Illegal Request (0x05)
    Sense Info: 0x00000000
    Additional Sense Length: 0
    Command-Specific Information: 00000000
    Additional Sense Code+Qualifier: Unknown (0x2009)
    Field Replaceable Unit Code: 0x00
    0... .... = SKSV: False
    Sense Key Specific: 000000

[/code]
-- 
This message posted from opensolaris.org

Grrrrr...I finally figured out I was specifying the wrong LUN (I was using 1 in
earlier testing but current targets are Lun 0).

I also mispoke...this is actually Etherboot''s gPXE''s Iscsi
logic, NOT fedora.

Here it is working now:

iSCSI (SCSI Data In)
    Opcode: SCSI Data In (0x25)
    Flags: 0x81
        1... .... = F: Final PDU in sequence
        .0.. .... = A: Acknowledge not requested
        .... .0.. = O: No residual overflow occurred
        .... ..0. = U: No residual underflow occurred
        .... ...1 = S: Response contains SCSI status
    Status: Good (0x00)
    TotalAHSLength: 0x00
    DataSegmentLength: 0x00000008
    LUN: 0000000000000000
    InitiatorTaskTag: 0x00000002
    TargetTransferTag: 0xffffffff
    StatSN: 0x00000003
    ExpCmdSN: 0x00000001
    MaxCmdSN: 0x0000000f
    DataSN: 0x00000000
    BufferOffset: 0x00000000
    ResidualCount: 0x00000000
    Request in: 487
    Time from request: 0.000332000 seconds
SCSI Payload (Read Capacity(10) Response Data)
    [LUN: 0x0000]
    [Command Set:Direct Access Device (0x00) (Using default commandset)]
    [SBC Opcode: Read Capacity(10) (0x25)]
    [Request in: 487]
    [Response in: 489]
    LBA: 41943039 (19 GB)
    Block size in bytes: 512
SCSI Response (Read Capacity(10))
    [LUN: 0x0000]
    [Command Set:Direct Access Device (0x00) (Using default commandset)]
    [SBC Opcode: Read Capacity(10) (0x25)]
    [Request in: 487]
    [Time from request: 0.000332000 seconds]
    [Status: Good (0x00)]

Note the LUN change from 1 to 0.

Still confusing though...even looking a packet level, error codes are
non-obvious...and also seems to violate RFC....maybe I''m reading an old
version of the RFC or something.
-- 
This message posted from opensolaris.org