VCB - want to present 'extra' LUN to just VCB server and not ESX (EMC SAN)

[os82]

Afrenoon all.

I hoping someone may be able to shed a little light on this. Currently we have a VCB server able to see the same LUNs as the ESX servers. All backups seem to work OK, but I have a little probelm as I don't actually have anywhere to store the vm backups. I'm hoping to present an extra LUN to the cluster so the VCB proxy server can mount this as an NTFS volume and use it as a tmp storage ground.

In doing this this I will obviously be presenting the same LUN to the ESX server cluster (all be it a NTFS volume). I assume that as long as I don't actually assign this LUN to the cluster etc. they will ignore it (or at least see that the LUN is there but in a format that cannot be read by ESX) and it will leave it well alone? I can fully understand why you wouldn't want to mount a VMFS volume on the VCB proxy, but mounting an NTFS volume setup in this way would be OK, wouldn't it?

Thanks in advance.

[depping]

It's not really obvious that you are presenting the same LUN to the ESX hosts. There's absolutely no need to do so and I would strongly advise against it. if someone makes a mistake you will lose your backup LUN. You are right that you can do this, but again I wouldn't... There's no need for these servers to see the LUN as it's only the VCB proxy that writes and reads from the LUN.

Duncan

VMware Communities User Moderator

-

---

Blogging:

Twitter:

If you find this information useful, please award points for "correct" or "helpful".

[os82]

Thanks for the response depping.

From you response I assume you'd add the VCB proxy into another storage group that hosts just this 'backup' LUN then? This would seem sensible as it avoids all other ESX servers having contact with the extra LUN in question.

[os82]

After playing around with this for the last day or so I now understand that a host (on an EMC SAN) can be a member of only one storage group at any one time. This is going to cause a few issues. I think I may have to present the 'backup' LUN to the whole ESX cluster (including the VCB proxy) and then mount it on the VCB proxy whilst leaving the LUN unassigned in the ESX cluster - as was the 1st idea. The only way I can see of doing this 'safely'(i.e. so I don't later assign this LUN as a VMFS volume) is to make it of an odd size i.e. 507GB so it stands out form the usual LUN sizes. I'll get down to this Monday, so if anyone else has any more ideas in the meantime they'd be much appreciated...

Many thanks,

[Sean321]

I am in the same boat with an EMC SAN and the restriction of being able to add a host to only one storage group at a time. I did the same thing and made the NTFS LUN for the backups on the proxy an oddball size but I would love to hear of a better way to do this. I can see where it could be easily overwritten by someone else unknowingly.

Sean

[depping]

Why not create a seperate storage group for the vcb proxy and add all apropriate LUNs? A host can only be member of 1 datastore group but a LUN can be member of multiple datastore groups...

Duncan

VMware Communities User Moderator

-

---

Blogging:

Twitter:

If you find this information useful, please award points for "correct" or "helpful".

[Sean321]

Thanks for your reply Duncan. I am a bit embarrassed at not knowing LUNS could be in multiple storage groups. With hosts having the strict limitation I didn't think to go the other route. I reconfigured it all this morning and of course that is a much better solution. Thanks for your great blog as well, it is one of my favorites to follow for sure.

Sean

[depping]

No need to be embarrassed, these are the kind of things you will need to run into once... and when you do you will never ever forget it

Duncan

VMware Communities User Moderator

-

---

Blogging:

Twitter:

If you find this information useful, please award points for "correct" or "helpful".

[os82]

Ditto!

Many thanks for this Duncan - seems to be working nicely!

[depping]

No problem!

Duncan

VMware Communities User Moderator

-

---

Blogging:

Twitter:

If you find this information useful, please award points for "correct" or "helpful".