"Device Test Failed" when mounting existing virtual disk

[Philip_B]

Greetings-

From teh Help -> About in the console I see we are running 5.6.1659 and are licensed for basic replication.

We have 4 LUNS presented and two have already been mirrored...two have not. One LUN that is not replicated was connected to by a Server 2008 server for many weeks and running fine, until teh drive connection disappeared yesterday. When I logged into the Starwind console I saw the scary yellow exclamation point over the target. I had no options but to delete the target and try and re-create it.

It failed with a "Device <target name> failed for ImageFile4" error.

I can create new targets if I create a new disk, but if I try to use the existing virtual disk it fails. Are there any tools for mounting the IMG file to recover data?

Any input would be greatly appreciated.

The log shows the following:

4/12 14:52:09.214 d78 S: SymId: 'ImageFile4': Assigned target name: 'iqn.2008-08.com.starwindsoftware:192.168.180.50-test', alias 'test'
4/12 14:52:09.214 d78 IMG: SscPort_Create: Opening device 'ImageFile4', image file 'My Computer\D\FTPData.img', buffering=0, async=1, readonly=0.
4/12 14:52:09.214 d78 IMG: *** ImageFile_Create: 'D:\FTPData.img': can't open the file (5).
4/12 14:52:09.214 d78 EventDB: Current timestamp is 1302641529
4/12 14:52:09.214 d78 IMG: *** SscPort_Create: Create('My Computer\D\FTPData.img') error (0xc0000001)!
4/12 14:52:09.214 d78 SCSI: Failed to create 'ImageFile4' device.
4/12 14:52:09.214 d78 Tgt: : *ERROR* cannot open the device 'ImageFile4'.
4/12 14:52:09.214 d78 Srv: * Device test failed for 'ImageFile4'.
4/12 14:52:09.214 d78 EventDB: Current timestamp is 1302641529

[Anatoly (staff)]

Greetings

What logs are saying, is that *.img file is busy by another process. Are you sure that you trying to use propper file?

[Philip_B]

Positive.

Rebooted server and there are no file locks on the file. Also was able rename the img file and then tried to connect with same error.

[Max (staff)]

Can you verify any possible file locks using filemon utility?
I have just tried this in my testlab and everything seemed to work fine after 2 reboots and resynchronization sessions.
The easiest way to get the data out of an img is to add it as a basic virtual->existing image file. Then connect it from 127.0.0.1 in local iSCSI initiator and it will appear in your HDD's list

[Philip_B]

I restored from backup and created another target that I dropped the data onto. Once I tested the data I deleted the old target out of frustration.

I have installed StarWind twice and have seen "funky issues" both times. The first time was with a pair of ESX boxes. Each ESX box was connecting to the same two LUNS. From either ESX box you could start any of several VMs without incident and as soon as you tried to boot a second it would bluescreen. As long as only one VM was running it was fine. I copied off the VMs and mounted them in a free iSCSI package on the same ESX boxes and they worked like a champ.

So I flushed the Starwind install and started over - this time all the VMs could start and everything was moving along happily. I added a second Starwind box and replicated (mirror) for the first two targets to the second machine and that went very smoothly until the latest "weird incident."

I saw weird as the other targets are just fine. There is only one physical host connecting to the troubled target and when it dropped it was never to be heard from again. I could see that there were no file locks against it - I could change it name and extension. I just seemed like an application bug.

Fortunately I had a backup of the data on that target taken within a few hours of the barf - so I was able to restore without any problems. This time that data is within a target that is mirrored so hopefully I'll be ok.

I am running the latest rev so I don't know how to explain the issues. The hard ware is dual socket SUperMicro running Server 2008 R2... all very reliable.

So far it is running smoothly and the replication says that it is synch'd - I haven't actually tried mounting the other mirrored targets to see if I have any issues. I'll try that in the next couple of weeks.

Thanks for the input.

[Anatoly (staff)]

Could you please doublecheck all the settings, especially CHAP?

[Philip_B]

Thanks for the input but the settings were correct.

The target was running without problems for a while and then one day just died. I killed it and re-created it with identical settings and restored data from backup and it is once again running fine. All settings are consistent (and I believe correct) and are "plain vanilla". I don't know how else to explain it but call it flaky.

I did mirror it this time around, but this is the second really flaky issue that I have seen. Makes me uneasy.

[Anatoly (staff)]

Could you please send log files of StarWind and vmkernel logs on the date of issue to sup at starwindsoftware dot com?

[Philip_B]

Thank you - I did send the logs when I ran into this issue with the multiple VMs. Nothing was apparent in the logs and we (a starwind support person and myself) never figured out the issue. I installed a free iSCSI target product on the server as a test (success) and then re-installed Windows and Starwind and that issue went away... so we just wrote it off as a "flaky issue".

The Starwind product has been fairly solid and stable - it was just strange that we have seen the two issues that were not recoverable or repeatable... basically the resolution was to flush and start over. I'll let you know if there are any other issues that crop up with this install. For now we have the targets mirrored to a second Starwind server and everything seems to be operating correctly.

Thanks again for your input.

[anton (staff)]

Hate things happening this way... OK, next time you'd see anything strange please don't hesitage to ask for remote session. Thank you very much for cooperation!

Thank you - I did send the logs when I ran into this issue with the multiple VMs. Nothing was apparent in the logs and we (a starwind support person and myself) never figured out the issue. I installed a free iSCSI target product on the server as a test (success) and then re-installed Windows and Starwind and that issue went away... so we just wrote it off as a "flaky issue".

The Starwind product has been fairly solid and stable - it was just strange that we have seen the two issues that were not recoverable or repeatable... basically the resolution was to flush and start over. I'll let you know if there are any other issues that crop up with this install. For now we have the targets mirrored to a second Starwind server and everything seems to be operating correctly.

Thanks again for your input.