host ran out of disk space, guest virtual disk got corrupt help please
Linux - Virtualization and CloudThis forum is for the discussion of all topics relating to Linux Virtualization and Linux Cloud platforms. Xen, KVM, OpenVZ, VirtualBox, VMware, Linux-VServer and all other Linux Virtualization platforms are welcome. OpenStack, CloudStack, ownCloud, Cloud Foundry, Eucalyptus, Nimbus, OpenNebula and all other Linux Cloud platforms are welcome. Note that questions relating solely to non-Linux OS's should be asked in the General forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
It is not clear to me if you moved the VMDK while the VM was still running. What do 'qemu-img info -f vmdk Win.Xp.Pro-0.vmdk' (requires qemu) and 'vmware-mount.pl -p Win.Xp.Pro-0.vmdk' return? Can you make the disk read-only and attach it to another VM and run that?
You could try copy the VMDK to a raw disk and see if you can loop-mount it and use standard GNU/Linux tools after the conversion: 'qemu-img convert -f vmdk -O raw Win.Xp.Pro-0.vmdk Win.Xp.Pro-0.img'. Please ensure there's enough disk space to make the copy as I'm not sure if it will expand the virtual size of the 59GB VMDK to be actually 105GB.
Please run and post output of 'file Win.Xp.Pro-0.img; fdisk -l Win.Xp.Pro-0.img; disktype Win.Xp.Pro-0.img'. ('disktype' is http://disktype.sourceforge.net/ and the RPM is at the DAG repo).
Originally Posted by fedora.linux.64
mount -o loop Win.Xp.Pro-0.img /mnt/vmware
mount: you must specify the filesystem type
Mounting a whole disk this way isn't useful. Run 'losetup -f' to find an empty slot then run 'losetup /dev/loop0 Win.Xp.Pro-0.img' (substitute "loop0" if necesary) to loop-mount the disk as a whole. If that works OK try 'kpartx -l /dev/loop0; kpartx -a /dev/loop0' to list partitions to be added and add them. If that works OK try 'disktype /dev/mapper/loop0p*' to see where you can access partitions separately.
file Win.Xp.Pro-0.img; fdisk -l Win.Xp.Pro-0.img; disktype Win.Xp.Pro-0.img
Win.Xp.Pro-0.img: x86 boot sector, mbr; partition 1: ID=0xf, starthead 0, startsector 16065, 220170825 sectors, code offset 0xc0
You must set cylinders.
You can do this from the extra functions menu.
You forgot to fill in the device name or use an asterisk as in: 'disktype /dev/mapper/loop1p*'. In any case now 'ntfsinfo -vfm /dev/mapper/loop1p5' or 'mkdir /mnt/rescue; ntfs-3g /dev/mapper/loop1p5 /mnt/rescue -o force,ro' should work.
Why don't you just enlarge the VMWare virtual disk to give yourself some room, then see if you can repair it? I've never had a VMWare virtual disk become completely full because when it gets close I either remove some stuff or enlarge the disk. Just two weeks ago I enlarged a disk using Workstation 7.1 and it was a painless operation.
After enlarging the disk you also have to enlarge the filesystem. I don't know what you'd get into trying to do this with a corrupted disk. Using Windows 7 guest, the process was borderline trivial. Using an XP guest, I think you would have to boot the VM into a Linux Live CD and use GParted. In fact, you could try this anyway and see if GParted (and other tools such as testdisk) could give you insight into what, exactly, is wrong with the disk. You might even find you could access and recover from the disk that way, though I wouldn't put too much hope into that...
Lots of Linux software fails in a most unfriendly fashion when the disk is completely full; could be that VMWare Workstation is one of these.
I am now making a full backup of the ntfs virtual disk now. Is this disk going to be able to be used in VM or should I just delete it after I get my backup and start with a fresh virtual disk?
Depends on how you make the backup. If the file system is backed up cleanly or can be fscked to clear any corruption and the "dirty" flag then you could try to re-convert it back to a VMDK and see if VMware is willing to recognize it. If you backed up only the partition and not the partition table this might require adding the new VMDK to a working VM guest so see if it's readable slash usable.