VM Harddrive full, won't reboot

[khenry567]

Hey guys, need some of your advice. I have a vm that the users filled the harddrive up to capacity. I first noticed a problem with it when I saw that the CPU was maxed out. I rebooted it so that the vm would continue working since the users had to have it working, and everything seemed fine. I told them that I would have to have this machine so that I could increase the harddrive size. I rebooted it last night again so that it could be used and figured in the morning(today) that I would run Converter on it and it would be OK. Well, I rebooted it again this morning because I wanted it functioning normally, CPU wise, and I wanted to delete as many files as possible once again(We did that two days ago and got 666mbs of free space, which must have filled up). Anyways, it would not come back up. Saying something about API error. I decided to run Converter on it anyway and did so. I have another machine that seems to be working now with a harddrive that is twice the size of the old one but when I tried to defrag it worked to some degree but I still have about 32% of the files unable to be defragged. The machine seems OK but I am not happy.

My questions: Was there a better way to do this? (I still have the old vm and can do whatever to it, if I can get it to boot) Could I increase the vmdk file size on the original vm somehow, defrag it, and get a better result that way?

Anyone have some opinions?

[wila · Accepted solution]

Every error will at least touch some API so I would say that your error is too general to give useful info.

The 32% defragmentation really depends on NTFS features, I suspect there are a lot of small files on that drive?

Another variable is the defrag utility used.

Anyways, when you need to increase the drive, Converter isn't such a bad choice, unless it fails to work properly.

Normally I just clone a VM using this script and then use the clone to work on.

This way I can always go back, much like you in this case.

Then for extending a vDisk, I use the command line, as root:

vmkfstools -X 25G /vmfs/volumes/volume1/sizematters/smalldisk.vmdk

This will expand the vDisk smalldisk.vmdk from the VM "sizematters" if (and only if) the disk was smaller as 25Gb

That will increase the disk afterwards you will still have to resize the partition(s) in the disk to actually make more space.

See also this page for steps on that.

http://www.vmware-land.com/Resizing_Virtual_Disks.html

--

Wil

[Yattong]

A quicker way to resize the harddisk could be just to use the vmkfstools and diskpart.

A link to do so... http://vmware-land.com/Resizing_Virtual_Disks.html

Good Luck

[khenry567]

thanks for the replies, to both you Yattong, and to wila

My real question, I guess, is this: If I use the methods that the two of you have suggested will I get any better results than I already have, as far as the defragmentation of the drive is concerned. In other words will I be able to defrag the drive completely. I am asking this as I haven't done much defragging of vm drives and therefore don't have the experience to know how well these drives actually defrag. Maybe what I am seeing is normal. Maybe I won't be able to defrag the "new" drive no matter how I "copy" it. Any ideas here?

My other suspicion is that using Ghost may be the best way. I think Ghost will give me a duplicate of the orginal drive only on a larger drive. Therefore I would then have the extra space and it would then boot.

Can I create another larger drive on another vm, connect a Bart's PE to the vm cdrom as iso, boot the offending vm, Ghost the smaller drive to the larger drive, then I should have a bootable vm with a larger drive.

Points will be awarded to both of you.

[khenry567]

wila, I just replied to Yattong, and I included thanks to you in that reply. Can you look at that and give your advice based on my response to Yattong. I was just looking at vmland stuff when your reply came in. Thanks, Kieth

[wila]

There is no difference between a virtual drive and a physical drive in terms of defragmentation. Let me say that differently, the software doesn't know it is defragmenting a virtual drive. So for troubleshooting you should treat it as a physical drive.

The NTFS defragmentation algorithm needs free space on the disk in order to remove the fragments. The standard internal algo in windows is not optimal as in that you sometimes must give it more free space as you would expect. As an example I had a physical WinXP machine over here with similar issues as you and still it had gigabytes of free space. It wasn't until I moved some more large files off the box until it completely defragmented the drive.

Ghost has a few ways of copying a drive. You can tell ghost to copy bit for bit and make an exact clone. In that case you really are better off using vmkfstools as it gives you no extras then. However if you use Ghost's knowledge about the NTFS filesystem (I think this is the default, but I don't use ghost as much as I used to) then ghost will copy the files smart out of the original, so you end up with a defragmented volume after the clone.

--

Wil

[khenry567]

Hey wila, Yes, I agree with your last statement about Ghost.

I have resolved the problem and this is how I was able to do it. First, I took a clone of the vm to work on so that I would not mess with the original. I then connected the W2K3disk1.iso to the vm's cdrom, I then ran the Repair, and used checkdisk on the vm's harddrive. Once this was done I was then able to boot the vm successfully into Safemode. With the vm in safemode I could then delete some of the files that were causing the problem. It turned out that the logs were building up and there was one log out of about 50 that was 13.6gig. This log had been created the same day that I noticed the original problem with the high CPU count. Once I was able to delete this particular log the vm worked fine. I could then defrag the drive.

You assumption about there being one large file that would not allow defrag I am sure was correct. I will try to remember that one in the future.

After doing all this to the clone I did it to the original vm. All is well now.

One question: What did you mean by vmkstools doesn't give you any extras?

[wila]

What did you mean by vmkfstools doesn't give you any extras?

Erm, if I'm not mistaken then I was stating the opposite, ghost doesn't give you anything extras over vmkfstools when doing a bit for bit identical copy.

If you're going to clone a VM and want a copy that is exactly the same (not looking at the filesystems underneath), just use vmkfstools as it is much faster and easier to use from the command line.

Oh and thanks for those points!

--

Wil