Extend the C-drive for Windows XP with 1-click

[pevm2008]

You should download and try fatVM BETA

fatVM is a reliable, robust, and safe, 1-click solution for extending the C drive of your VMware Fusion virtual disk that is becoming full.

• It provides a simple, intuitive, interface and a reliable process that hides the technical complexity of extending a virtual disk.

• It is robust because it can extend virtual disks having snapshots and clones.

• It is safe because it preserves your original disk, which remains available to you for when the need ever arises.

Try the fatVM BETA download , it is free.

[ab_lal]

Just took a tour of the product however will try it later.

[continuum]

1. It is robust because it can extend virtual disks having snapshots and clones.

</div>

I just tried the Windows version: it really worked nice for a powered off VM without snapshot.

I then tried it against a VM with 4 snapshots in a single branch. It failed and corrupted the original.

Repeated the test with a similar VM - which failed again with original messed up.

I would not call this robust !

But the function against a simple VM without snapshots was really nice ... looks promising.

For anybody who wants to know how the partitions are expanded ...

The tool runs a small Linux-iso in the background which does the work under the hood.

!kaside (fatvm)-2010-02-05-00-17-58.png|thumbnail=true!

Ulli

___________________________________

VMX-parameters- Workstation FAQ -[ MOA-liveCD|http://sanbarrow.com/moa241.html] - VM-Sickbay

[continuum]

some time later ....

the tool creates snapshot-descriptors like this one

#Disk DescriptorFile
version=1
CID=94fd7675
parentCID=94fd7675
createType="twoGbMaxExtentSparse"
parentFileNameHint="fatvm-24.vmdk"

# Extent Description
RW 14475264 SPARSE "N:\p2v\vdisk-000006.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-000.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-001.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-002.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-003.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-004.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-005.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-006.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-007.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-008.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-009.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-0010.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-0011.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-0012.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-0013.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-0014.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-0015.vmdk"
RW 4192256 SPARSE "fatvm-34-ext-0016.vmdk"
RW 239616 SPARSE "fatvm-34-ext-0017.vmdk"

# The Disk Data Base
ddb.encoding ="windows-1252"

IMHO using absolute paths mixed with relative paths in a vmdk descriptor means asking for trouble.

At the moment I would recommend this tool for very experienced users only - which defeats the one-click idea :-(




___________________________________

VMX-parameters- Workstation FAQ -[ MOA-liveCD|http://sanbarrow.com/moa241.html] - VM-Sickbay

[rosensharma]

---

[continuum]

The goal is never to touch an existing file.

Hmm - but you reference the original snapshot in the new expanded snapshot-descriptor.

That means if you start the newly created VM you will break the CID-chain of the original.

IMHO you should try to create a completely new VM in a new directory that needs no reference at all to the original.

If you do not do that - every failure during expand action will mess up the original.

And you really should not run that risk if you want happy users :smileywink:

By the way - how do you plan to handle hot snapshots ? - If I looked right you completely ignore the vmsn files ?

Where do I find the logs you need ?

Ulli




___________________________________

VMX-parameters- Workstation FAQ -[ MOA-liveCD|http://sanbarrow.com/moa241.html] - VM-Sickbay

[GG42]

Ulli ... original thought was to not have to copy all the VM files over, as that could be large.

Maybe giving the user an option to copy or just link may be the best compromise (especially during beta).

Is your original VM monolithic sparse?

[GG42]

first of all, thanks for trying this.

We are currently in beta. Sorry this should be highlighted more prominently, its only in the installer. We will put more prominently in the UI.

- it should not have corrupted the original files, we are looking into that. The goal is never to touch an existing file.

- In the final release we can create all the extension files in the same directory as the original files, so will not need to mix the relative and absolute paths

- yes we can create the vmx in a different directory

I will get back to you on the snapshot case. Would you be willing to share your logs? If yes please send me email: at gg42 at gudgud dot com

[admin]

- In the final release we can create all the extension files in the same directory as the original files

I'd suggest using a different directory, as there are ambiguities if there's more than one .vmx file in a directory. Remember that Mac users expect to operate on bundles (i.e. directories), not .vmx files. It's also possible for the .vmx file to not match the bundle name, e.g. A.vmwarevm/b.vmx. If you then add c.vmx, there's nothing to tell Fusion which .vmx to prefer, so we may choose the wrong one. If there is only one .vmx per .vmwarevm bundle (or if a name matches), there is no ambiguity.

[GG42]

Good point. We will change it to create another bundle in a different directory

[siginfo]

@Ulli:

What do you mean when you say that the original one was messed up? The tool creates a new vmx and new vmdk's to mirror the original chain. It only references the original extents as parents, which means they are never modified, hence their CID's remain unchanged. Therefore any other snapshots or linked clones which reference these VMDK's should be unaffected.

When you booted via the original vmx did you see any issues?

On what step did the tool fail when you tried it on the VM which had a big snapshot chain?

It would help us improve the product greatly if you could explain your actions step by step and the issues you encountered.

Thanks for trying it out!

[continuum]

first VM with snapshot s I had tired yesterday was a monolithicSparse basedisk with 4 cold and one hot snapshot. GuestOS = windows 2000

The tool failed with a message like /dev/hda1 could not be mounted or something like that.

Then I looked at the original and the snapshotmanager lost all info and only displayed YAH point.

To most of the users this means VM is messed up.

Well it is no big problem for experienced users but for noobs or the expected audience for your tool this means the VM is messed up.

You asked for the disktype: Workstation uses monolithicSparse as the default when creating a new VM - so you MUST be able to handle this one.

Have you seen that the vmdk I posted has CID = parentCID ?

This should never happen - please fix this as well

Ulli

___________________________________

VMX-parameters- Workstation FAQ -[ MOA-liveCD|http://sanbarrow.com/moa241.html] - VM-Sickbay

[siginfo]

Thanks for your response. We are looking at the CID = parentCID problem.

However, we still don't understand why you lost your original snapshots. The resize could have failed with an error if the original machine wasn't powered off cleanly and NTFS was unclean. We will fix this in the upcoming release. However, this should still leave the original machine, disks and snapshots unaffected.

Can you please check once again what happened to the snapshots. Originally if you had a vmx like win2k.vmx, its associated snapshot meta data would be in win2k.vmsd. When our product extends this VM, it creates a new vmx file like win2k-fatvm.vmx, an associated .vmsd is also generated which is called win2k-fatvm.vmsd. This file is 0 byte in size. However, the original vmx and the vmsd are still intact.

In your case do you see the original vmx and vmsd files? Does the original vmsd still contain all the snapshot information?

Thanks for all your help.

[rosensharma]

--

[GG42]

Ulli,

we incorporated your suggestions in the updated build. It creates a separate directory and use relative links. thank you for your help.

Regards

GG

You can get the updated build by registering again (http://www.gudgud.com/fatvm/download.php?id=1)

[continuum]

Hi

I tried the new build.

Good: existing VM still works after usage of the tool

Bad: no new directory created at all and then the tool failed with this error:

I tried twice against the same VM - no success - lost interest on testing with a second VM then :smileywink:

By the way - how much do you plan to charge for this tool ?

Ulli




___________________________________

VMX-parameters- Workstation FAQ -[ MOA-liveCD|http://sanbarrow.com/moa241.html] - VM-Sickbay

[GG42]

Ulli,

can you ship upload the logs: Tools->Export Log will create a zip file.

Also can you confirm that u:\machines\mini2k3.fatvm directory is not created.

Regarding charging we have not thought about it much. Want to make sure it is useful for people first.

thanks

[continuum]

You will see that I used a mean example for testing :smileywink:

But noobs will use that tool for similar VMs and you should prepare for it :smileywink:

see attached logs




___________________________________

VMX-parameters- Workstation FAQ -[ MOA-liveCD|http://sanbarrow.com/moa241.html] - VM-Sickbay

Attachment(s)

fatVM.logs.zip   17 KB 1 version

[GG42]

Holy Smokes!!!

Mean VM it is & thanks for putting fatVM through the grind. I really appreciate it.

Would it be possible for you to zip the contents of the u:\machines\mini2k3.fatvm?

[continuum]

Hehe - if you want me to test expect that I use some mean examples :smileywink:

Hey - I had notr even noticed the new directory ... somehow I expected you would create a subdir inside the original.

Can't you ask the user where to create the new VM ?

IFrom a quick check I noticed that there are still issues with CID=parentCID

Find the zipped directory attached - I removed the iso to reduce size

Ulli




___________________________________

VMX-parameters- Workstation FAQ -[ MOA-liveCD|http://sanbarrow.com/moa241.html] - VM-Sickbay

Attachment(s)

mini2k3.fatvm.zip   83 KB 1 version

[siginfo]

cid = parentCID problem: While investigating this issue we found that vmware workstation while creating a cold snapshot makes the cid = parentCID. Is this is a BUG or deliberate?

We think it is such because on boot when the child is modified the CID will change anyways, hence they did not bother generating a new CID anyways.

However, for people who have been used to manually tracking CID links, a sequence of cold snapshots could mean a lot of disks which have CID = parentCID, which is something a lot of people are not accustomed to.

CID's don't have to be globally unique, it is ok if they are unique/file (sort of like generation counts/inode), but it would definetly help having them globally unique because it will create less confusion.

@Ulli: Thanks for the logs. We are looking at your complex VM and have found some issues at our end.

Your cid=parentCID problem is not caused by fatVM. It is just that we mirror those CID's in the files in our directory. Your original VM should also have cid=parentCID for some cold snapshots (see above)

Also could you please tell us what kind of paritioning scheme (MBR, GPT etc.) did you use while creating the Windows 2003 VM? Does it use basic or dynamic disks? Also, how many paritions does your ide0 disk have?

Thanks once again for all your help!

[continuum]

Hi

you are right about the CID=parentCID behaviour.

never noticed this before - need to update my site.

This VM only uses straight MBR partition-tables. All vmdks were partitioned with 2k3 diskmanagement.

IDE0:0 uses one NTFS partition - starting at sector 63.

By the way - how do you proceed if a VM has ide0:0 and scsi0:0 ?

Which one do you expand ?




___________________________________

VMX-parameters- Workstation FAQ -[ MOA-liveCD|http://sanbarrow.com/moa241.html] - VM-Sickbay

[siginfo]

In your case we are trying to extend ide0:0 which is the right disk to extend.

In general want to have our code mimic the vmware BIOS type device enumeration which is scsi followed by ide, but there are some issues with it which we are working on.

We will release a new build soon, would be great if you could test it once again :smileyhappy: Thanks in advance.

BTW on one of your simpler VM's where fatVM worked fine, did you try browing the apps and files in the bottom panes? Do you think that functionality could be useful to people? Any other suggestions on things to add/improve in fatVM would be highly appreciated.