Sharing a single target to EWF-protected Windows initiators

[Anatoly (staff)]

Well, that is a good opinion. But there there is always at least one "but" .

Why would it be so difficult to have two targets pointing to the same LUN, one with read only or redirected writes and the other with normal write capabilities?

It is really hard to make the block device to accept more than one connection. It is much easier to configure the file-share. It is definitely possible to configure it basing it on SW device.
I don`t know if you know but CSV is actually not presented on all machines of MS cluster. If you don`t mind to put it simply, LUN is actually presented physically on one node only (owner node), and all the rest cluster machines have redirected access to it through the owner machine. So, as I told previously - NFS is the easiest way out for this scenario.

[anton (staff)]

That's a whole different story... These guys need to update "golden image" all other machines boot from. With our current ideology it's very much complicated.

Well, that is a good opinion. But there there is always at least one "but" .

Why would it be so difficult to have two targets pointing to the same LUN, one with read only or redirected writes and the other with normal write capabilities?

It is really hard to make the block device to accept more than one connection. It is much easier to configure the file-share. It is definitely possible to configure it basing it on SW device.
I don`t know if you know but CSV is actually not presented on all machines of MS cluster. If you don`t mind to put it simply, LUN is actually presented physically on one node only (owner node), and all the rest cluster machines have redirected access to it through the owner machine. So, as I told previously - NFS is the easiest way out for this scenario.

[digitalis99]

At this point, I'd accept not being able to update the golden image. I'm extremely curious, though, how (under your software) you create the golden image in the first place?

This scenario only takes me about 5 minutes to test and verify that none of the three non-normal write modes works with the current build. It still seems to me that you released code without having even tried to use it first. I noticed that read only LUN's are briefly mentioned in the docs, and neither of the two write redirect modes are mentioned at all. Nowhere is anything mentioned about how to create the image that's going to be offered read only or write redirected.

Allowing multiple initiators to access the same LUN has been part of iSCSI from the beginning. I did this with IET years and years ago. It seems to me that transparently redirecting writes for each initiator would be a little bit more complicated. Since it's a feature in your current software, though, that doesn't work at all...well, that needs to be addressed.

[Yuriy (staff)]

Hello, digitalis99!

We've found the reason of boot failures in ROW mode. Please wait for a few days until our QA team will test the update.

--
Best regards,
Yuriy.

[digitalis99]

Hello, digitalis99!

We've found the reason of boot failures in ROW mode. Please wait for a few days until our QA team will test the update.

Cool, did this bug affect all three write modes (read only, redirect write, and redirect write with discard)?

[Yuriy (staff)]

digitalis99,

When new initiator connects to the target with IBV device that works in one of ROW modes, we automaticaly create a linked clone device.
This issue (boot failure) was caused by the fact that we do reset of disk signature when 1) we mounting a snapshot in readonly mode and 2) when we create a child device (linked or full clone) from snapshot.

Our solution is deactivating of disk signature reset for the cases when we create a linked clone for use in ROW modes.

And we still do reset of disk signature when we mount a snapshot in readonly mode. It is needed to avoid disk collisions when you mount several snapshots of same device on same machine.

So, in your iSCSI boot solution you should use one of the ROW modes. You shouldn't use readonly mode.
We will discuss the possibility to add additional tweak setting to our GUI, that can give you a chance to configure readonly mode (with or without reset of disk signature). But this will be in the future.

--
Best regards,
Yuriy.

[anton (staff)]

1) You create an image file, convert it into IBV in "discard" mode.

2) It's not production features. Not something we sell and charge money for. It's intended for geeks playing with iSCSI client boot. We did not test Windows 7 insisting on preserved disk signatures this time.

3) Of course you can have multi-connect. But you need to have cluster-aware file system for this. Or distributed lock manager.

At this point, I'd accept not being able to update the golden image. I'm extremely curious, though, how (under your software) you create the golden image in the first place?

This scenario only takes me about 5 minutes to test and verify that none of the three non-normal write modes works with the current build. It still seems to me that you released code without having even tried to use it first. I noticed that read only LUN's are briefly mentioned in the docs, and neither of the two write redirect modes are mentioned at all. Nowhere is anything mentioned about how to create the image that's going to be offered read only or write redirected.

Allowing multiple initiators to access the same LUN has been part of iSCSI from the beginning. I did this with IET years and years ago. It seems to me that transparently redirecting writes for each initiator would be a little bit more complicated. Since it's a feature in your current software, though, that doesn't work at all...well, that needs to be addressed.

[digitalis99]

digitalis99,

When new initiator connects to the target with IBV device that works in one of ROW modes, we automaticaly create a linked clone device.
This issue (boot failure) was caused by the fact that we do reset of disk signature when 1) we mounting a snapshot in readonly mode and 2) when we create a child device (linked or full clone) from snapshot.

Our solution is deactivating of disk signature reset for the cases when we create a linked clone for use in ROW modes.

And we still do reset of disk signature when we mount a snapshot in readonly mode. It is needed to avoid disk collisions when you mount several snapshots of same device on same machine.

So, in your iSCSI boot solution you should use one of the ROW modes. You shouldn't use readonly mode.
We will discuss the possibility to add additional tweak setting to our GUI, that can give you a chance to configure readonly mode (with or without reset of disk signature). But this will be in the future.

That's fine with me. Read only mode wasn't too interesting to me anyway. ROW with discard is what interests me most at the moment. Is the discard done in real-time, or after the session ends?

[digitalis99]

1) You create an image file, convert it into IBV in "discard" mode.

2) It's not production features. Not something we sell and charge money for. It's intended for geeks playing with iSCSI client boot. We did not test Windows 7 insisting on preserved disk signatures this time.

3) Of course you can have multi-connect. But you need to have cluster-aware file system for this. Or distributed lock manager.

1) Great, I was creating the image in IBV mode to start, so I'll adapt my procedure.

2) Any software company that releases features in a paid version of their software but then explains they are not for production when people try to use them...I can't even begin to debate why that is a bad idea. I couldn't, and still can't, think of any use of the ROW modes other than booting multiple machines from the same image, so it seemed silly to me that this hadn't been tried. Since it hadn't been tried, in what scenario(s) did you test the ROW modes? I'm curious.

3) ...or you support redirecting writes on a per-session basis like you are trying to do. It's your feature, play it up!

[anton (staff)]

It's called experimental features. A lot of companies do this (including VMware) and I don't see any issues with this approach.

Yes, but it's very different from having concurrent read-write access.

[digitalis99]

It's called experimental features. A lot of companies do this (including VMware) and I don't see any issues with this approach...

The difference being they flag the experimental features as such in their GUI, release notes, or documentation (or all of the above). They don't leave people to install the software, try a particular feature, have it fail (hopefully not resulting in data loss), and wait for a support ticket/forum post to tell that one user it's experimental. Telling me that something is experimental after the fact is a cop-out response at best.

If I had paid money for the software in order to get this feature, I'd be pretty upset, and rightfully so. Fortunately, I'm only testing with the free version, so I don't have the right to be bothered. Surely wording features in the GUI as experimental wouldn't take much work. Just a little constructive criticism.

[anton (staff)]

That's right. That's why with a minor update we'll have about Windows 7 we'll put our usual mark say it's experimental. And there's no reference in the docs yet...

It's called experimental features. A lot of companies do this (including VMware) and I don't see any issues with this approach...

The difference being they flag the experimental features as such in their GUI, release notes, or documentation (or all of the above). They don't leave people to install the software, try a particular feature, have it fail (hopefully not resulting in data loss), and wait for a support ticket/forum post to tell that one user it's experimental. Telling me that something is experimental after the fact is a cop-out response at best.

If I had paid money for the software in order to get this feature, I'd be pretty upset, and rightfully so. Fortunately, I'm only testing with the free version, so I don't have the right to be bothered. Surely wording features in the GUI as experimental wouldn't take much work. Just a little constructive criticism.

[Yuriy (staff)]

It's called experimental features. A lot of companies do this (including VMware) and I don't see any issues with this approach...

The difference being they flag the experimental features as such in their GUI, release notes, or documentation (or all of the above).

ROW modes are undocumented for now. This fact in itself suggests that they should be treated with caution as long as they will not be documented.
In any case, we thank you for showing interest in them, and for the fact that you pointed us to a problem with Windows 7 iSCSI boot.

[digitalis99]

ROW modes are undocumented for now. This fact in itself suggests that they should be treated with caution as long as they will not be documented.

Omissions suggest nothing at all.

Any progress with this bug now that you've known the cause and the fix?

[anton (staff)]

It's not a bug it's a workaround for standard Windows 7 behaviour

Yes, works fine now. QA completing some tests before we'll leak the version to public.