Well, we actually had to force kill the process of committing snapshots, which likely caused major corruption to the vm. We are now investigating data recovery techniques for vm's. I'll post any good solutions here for people in the future. I have an entire post on Experts Exchange that if you google search, Vmware esx 3.5 help!!!!!!!!!!! Crisis!!!!, and click on the Experts Exchange link and on teh "Cached" button with google, you will be able to read the entire post and all comments. There were some pretty good solutions posted but unfortunetely we did not get to implement them intime before we ran out of space.
Vmware esx 3.5 help!!!!!!!!!!! Crisis!!!!
Hello, we currently have a setup with 1 esx host running 2 vm's on it. This is a production esx host and production vm's.
on wed. we decided we needed to expand the virtual disk for one of the vm's due to lack of space... so we did so, without committing the snapshots first..
we have about 32 snapshots currently (i know i know, wasn't my doing) and we have taken the necessary steps to change all of the CID's etc so taht everything is lined up correctly. we are now manually committing the snapshots to the flat file via ssh.. and it has been doing this since thursday morning around 4:30am. we have both vm's turned off to help with disk usage.
here comes the problem. the host has a RAID5 setup internal that has about 930 somthing GB usable space. We are running out of room very quickly now and we are afraid of what might happen when it does. the vm that we are committing is only about half way through the process, and is already taking up about 570GB and teh other vm plus its 32 snapshots (again, not my doing) are taking up about 220GB. as you can see, this is a problem.
My question is, what can we do to prevent this catastophe-in-the-making? We would normaly just move the second vm to another location temporarily, but to do this you must unregister the vm before moving. the problem is that unregistering it only works if you commit the snapshots, and we have 32 snapshots, and this will undoutably use more than the available space left.
How can we move this vm off of the esx host without damaging it, and then move it back on afterwards?
One of our tech's had the idea to simply not unregister the vm, but to move the entire /vmfs/storage/vm directory to another storage box (non-esx)temporarily, and them move it back to teh original location after the coast is clear. will this dmg anything?
is there anything else we can do before we have a real crisis!?!?!?!?!?!
PLEASE HELP!
on wed. we decided we needed to expand the virtual disk for one of the vm's due to lack of space... so we did so, without committing the snapshots first..
we have about 32 snapshots currently (i know i know, wasn't my doing) and we have taken the necessary steps to change all of the CID's etc so taht everything is lined up correctly. we are now manually committing the snapshots to the flat file via ssh.. and it has been doing this since thursday morning around 4:30am. we have both vm's turned off to help with disk usage.here comes the problem. the host has a RAID5 setup internal that has about 930 somthing GB usable space. We are running out of room very quickly now and we are afraid of what might happen when it does. the vm that we are committing is only about half way through the process, and is already taking up about 570GB and teh other vm plus its 32 snapshots (again, not my doing) are taking up about 220GB. as you can see, this is a problem.
My question is, what can we do to prevent this catastophe-in-the-making? We would normaly just move the second vm to another location temporarily, but to do this you must unregister the vm before moving. the problem is that unregistering it only works if you commit the snapshots, and we have 32 snapshots, and this will undoutably use more than the available space left.
How can we move this vm off of the esx host without damaging it, and then move it back on afterwards?
One of our tech's had the idea to simply not unregister the vm, but to move the entire /vmfs/storage/vm directory to another storage box (non-esx)temporarily, and them move it back to teh original location after the coast is clear. will this dmg anything?
is there anything else we can do before we have a real crisis!?!?!?!?!?!
PLEASE HELP!
