Does FOG work with iSCSI?

[ManofValor]

@Wayne-Workman When you say blast I assume you mean delete? Just making sure its not another term or something…lol.

[Wayne Workman]

@ManofValor yes. Blast sounds so much more exciting than delete.

rm -rf NameOfFileOrDirectory

[ManofValor]

@Wayne-Workman Haha, I agree.

[ManofValor]

This post is deleted!

[ManofValor]

@Wayne-Workman Still the same error.

[Wayne Workman]

@ManofValor I have no earthy idea why that page is being requested then. If you have time to do a TeamViewer session I can try to figure out why.

[ManofValor]

@Wayne-Workman Ok, check your PM.

[ManofValor]

OK, so I started to image and got this:

Tried to Google but no luck.

[ManofValor]

Got a strange thing happening. I’m on my Win7 machine, my usual work space, when I go to FOG management and storage node the password is the same as my login. When I look at it from my FOG server it’s the usual randomly generated password. When I try to update it back to random password it won’t change. The password under .fogsettings is the random password. What am I missing?

[Quazz]

@ManofValor This is detailed on the wiki, it’s because of the browser auto fill feature. Turn it off for fog website.

[ManofValor]

@Quazz Thanks, that worked.

[Wayne Workman]

I remoted in with TeamViewer and figured out why it was redirecting to that /static/index.html page.

There were two nodes configured (incorrect in this particular scenario), one pointing to the fog server, another to the iSCSI device’s IP.

So, in FOG Configuration, it’s written to report the kernel and other info on all attached nodes. A web query was being made to that second (incorrect) storage node, and the NAS was redirecting to the aforementioned page.

Since iSCSI is a block device, and mounts like a local HDD, the secondary node was incorrect.

After deleting that incorrect node, all started working fine, and the main server which has the iSCSI device mounted as a local HDD is correctly displaying the available space on the dashboard so all should be fine now.

Tom had hinted at this, and that’s what I was looking for. Storage Management was literally the last place I looked for problems (of course). I actually ran a WireShark capture during the redirect and figured out the server was talking to the iSCSI device’'s IP via port 80, and that led me to find the issue.

[ManofValor]

So this post can be solved, everything is working. I created an image and then redeployed it. Now on to looking into sysprep. Thanks guys.