Yuriy (staff) wrote: We plan to release new build on monday (Oct 1 2012).
New build will be available for download from our site.

Cool. Is there any way to know what the build number is before I download the installer entirely and check it?

Yuriy (staff) wrote:

digitalis99 wrote:

anton (staff) wrote: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?

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 ...

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...

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 cre...

Yuriy (staff) wrote: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)?

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 cu...

As regards 2), I understand how it currently works...I'm just saying that's very difficult to work with from an administrative perspective. 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?...

Believe me, I'll stay tuned. I need this thing to work!

Anton, I already followed your steps, since that's the only way to generate the image to be shared out in read only or write redirected mode. The problem is that when I shut down the initiator that I use to setup the image, delete the device, create a new device pointing to the same .ibv with the wr...

Tried all three CDP modes (read only, redirect write, and redirect write with discard), and I couldn't get anything other than a botched target. I don't know how, but the target itself gets corrupted, and then nothing can boot from it citing an inability to find winload.exe. Further, the cited step ...

I'm going to try read-only and redirect on write with discard, but I have another question. How am I supposed to easily update the image? It would be nice to have the read only or write redirect defined on the *target* rather than on the *device*. That way, I could have two targets pointed to the sa...

I'm going to try a read-only target to see if that's even possible to boot from when EWF is enabled. On paper, it should be, but I have a feeling that the EWF driver is being loaded too late in the boot process to filter *all* of the writes.

I'm running the latest free build to share out a single target to multiple initiators. The initiators all use the target as a boot volume, and they're running Windows 7 Embedded with the EWF filter driver filtering out the writes to the volume. My initiator names are specified by iPXE, and I'm only ...