• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

ESX 4.0

Rampage1329

[H]ard|Gawd
Joined
Dec 5, 2006
Messages
1,774
Can yall help me? My file server has been down for six hours. When I log into the vsphere manager where the two hosts are I can see the data store that contain my other VMs. When I connect to the host directly with the vsphere client its not seeing this data store. I'm at a loss, and google has not been kind to me. I have rescanned my data stores, can anyone help or give me some direction on where to look. If i can get my hosts to see this one datastore, then I can load up all of my servers again.
 
what kind of storage? iSCSI or FC? And how many others have access to the management of these devices? Remember that vCenter only reports what the ESX hosts present.

if it's iSCSI is it on a separate switch from you public networks? if not it could be that someone is using the same IP as the target.

More info on the physical configuration would be helpful
 
its iscsi. It turns out our san was offline it had some message offline_nomore room to grow . We are running out of space. Pretty nerve racking experience. Its also on its on its own network.
 
lol. yeah, that'll happen sometimes. Check the VMs for corruption.
 
Don't keep snapshots for more than 24 hours. They are only meant for a quick backout when you make a change that could hose the VM.

In fact, I wrote a script a while back that would look for snapshots (both reported by the host and ghost snapshots) and send an email report every day. It's critical to make sure none of them are hanging around.
 
Thin provisioning strikes again. you should set up the alerting on your SAN so that you are notified when this sort of thing is going to happen.
 
Don't keep snapshots for more than 24 hours. They are only meant for a quick backout when you make a change that could hose the VM.

In fact, I wrote a script a while back that would look for snapshots (both reported by the host and ghost snapshots) and send an email report every day. It's critical to make sure none of them are hanging around.

I believe he is talking about snapshots at the SAN level, not through VMware. and you are spot on in that respect. We have had clients with layers of snapshots loose data do to poor management of snapshots and the inability to commit them.
 
Don't keep snapshots for more than 24 hours. They are only meant for a quick backout when you make a change that could hose the VM.

In fact, I wrote a script a while back that would look for snapshots (both reported by the host and ghost snapshots) and send an email report every day. It's critical to make sure none of them are hanging around.

I believe he is talking about snapshots at the SAN level, not through VMware. and you are spot on in that respect. We have had clients with layers of snapshots loose data do to poor management of snapshots, where they have had multiple snapshots over long periods of time that they could not delete.
 
Back
Top