Any downside to large vdi (dynamically)

fctc · Post by **fctc** » 10. Dec 2008, 20:44

I intend to move my real XP platform to VB. I have created two dynamic VDIs, up to 70 GB a piece to accomodate the real drives.

From what I have read in the manual a scoured here in the forums, small boot partitions are recommended.

What, if any, is the downside of having a large boot VDI partition? I see that partitions can be up to 2T.

FCTC

Post by **mpack** » 10. Dec 2008, 20:53

The only downside I can think of is that if you really allowed a VDI to grow to those huge sizes then they would become difficult to move around (eg. for backup or to clone). Also, if the OS is giving you a false impression of having loads of unused space then you may not be encouraged to manage that space properly. Personally I would stick to good but manageable sizes - definitely not too small, but not silly-big either.

Post by **vbox4me2** » 10. Dec 2008, 21:37

All my vdi's are 60gb dynamic stored in a ntfs compressed folder, at the moment 10 vdi's using 24gb but only 6gb on disk. Copying them goes fast enough even to a compressed lan share in a 100mb lan and 3 switches.

Post by **Sasquatch** » 10. Dec 2008, 23:44

Another downside of having large boot partitions is that you tend to easyly use up it's space for useless data. Having a boot partition of 100 GB and you install some big apps, some games and so on, files needed for the OS are easily scrambled all over the drive, making it perform less and less over time. A defrag can put the files in one piece again, but it doesn't move the system file to the beginning of the drive.

Better to have a separate partition for all the non-vital programs and other data. That's how I keep my Windows lean and fast.

fctc · Post by **fctc** » 11. Dec 2008, 00:32

vbox4me2 wrote:All my vdi's are 60gb dynamic stored in a ntfs compressed folder, at the moment 10 vdi's using 24gb but only 6gb on disk. Copying them goes fast enough even to a compressed lan share in a 100mb lan and 3 switches.

Hmmm, I hadn't thought of a compressed folder. Total space on the host drive is 320 GB and I just wanted to alot half of that to my VDIs.

fctc · Post by **fctc** » 11. Dec 2008, 00:41

mpack wrote:The only downside I can think of is that if you really allowed a VDI to grow to those huge sizes then they would become difficult to move around (eg. for backup or to clone)...

Which brings up the question, will my Acronis image backup AND restore back to a real system if I do run into problems. So far, I used Acronis Migrate Easy to clone my original XP VM in 10 GB to the 60 GB Primary Master VM. I better tred slowly with this and research as much as I can on Acronis True Imaging in the VM world. However, correct me if I am wrong, but all of this trivial in that I need only copy the VDI as a backup.

However, what assurances do I have for data integrity if I simply copy or clone to a real drive? I am always concerned with single large files (a al MS Outlook) becoming corrupt. Would I not be better using Acronis with image validation? JTOL (just thinking out loud)

FCTC

Post by **TerryE** » 11. Dec 2008, 01:25

I would strongly recommend that you used a, say, 40Gb dynamic VDI for your C partition but with only 5-10Gb allocated to the C partition and the rest for growth. Only put Windows and your core apps in Program Files. Get it set up the way you like it and stable. Then clean it up by defragging, using sdelete and compact as I discuss in my tutorial All about VDIs.

If you want to use VDI based backup you can then snapshot it and now you only need to back up incrementally the snapshot (plus VBox and machine XMLs). I personally use at least 3 working partitions for XP: the C as discussed; D for Documents and Settings, etc. -- personal stuff that is really critical and E for all my temporary caches, replaceable downloads etc.

Regular backup of D is essential, E is a nice to have and C a convenience to avoid needing to redownload all those MS patches.

Using something like ACRONIS from within the VM is a sensible alternative because (i) it understands the difference between unallocated and allocated clusters and only backs up the latter; (ii) it (or at least the better versions use smart incrementals and on the fly compression.