virtualbox.org

The mouse over for the flag in the settings just says the guest system will see the virtual disk as a solid-state device. I'm not sure what that does to improve performance or how if it does.

The guest OS would potentially organize data differently, and e.g. not spend time defragmenting. You would set this flag for the VM when the VDI is located on a real SSD, it isn't an emulation feature.

Actually, I've found both the "--nonrotational" and "--discard" flags now, as part of "VBoxManage storageattach". The former is the SSD flag. No mention of what the latter does.

FWIW, I have two SSD laptops, one a Mac and one a Windows 10 Asus and I assume rightly or wrongly that the OS handles optimizing the SSD without me adding commands. Perhaps the SSD flag allows a modern OS to do the same. Don't know.

The difference is that the host OS can detect that the underlying hardware is an SSD (assuming the OS is modern enough). A VM can't, since it has no access to host hardware. Not unless VirtualBox tells it.

So, if I am running say Windows 10 or a modern version of Linux on an SSD host, it sounds like it should be enabled.

If you don't want the guest OS to do inappropriate things on the SSD, then yes. In theory it will wear out faster if you don't.

I would rather it not do anything inappropriate.

It begs the question, what about older guest OS's such as XP or even Windows 7 which may not be SSD aware?

loukingjr wrote:It begs the question, what about older guest OS's such as XP or even Windows 7 which may not be SSD aware?

For hosts you could be provided with new device level drivers. For guests, yes: not all guests are SSD aware. One might want to consider that before locating your VM on an SSD. This isn't really something I've thought a lot about, because I don't yet use SSDs on a development PC (i.e. on PCs where I care about disk longevity).

Personally I don't believe I run guests often or long enough for it to matter. Your reasoning seems sound though for those who do and I think running only SSD aware guests on SSD hosts seems logical.

Anyway, this topic seems to have diverged from the OPs question. I suspect that he tried to get continuous compaction by setting this flag, so I still want to know where in the documentation he got this idea from.

As to the error itself, I'm having trouble convincing myself that any VirtualBox operation (even an op you shouldn't have told it to do), would leave behind a VDI with a corrupted header. I could imagine no VDI, or an empty VDI with a valid header, but I can't see the mechanism for anything else. It would be useful to know exactly what is left of the file: does it exist at all, what is the exact file size (in bytes), and what does CloneVDI say when you open it.

So I changed this in order to enable TRIM, I can try if the nonrotational flag also enables trim later.
So on my linux guest, it says So both Windows 7 and Linux did also shrink the VDI file automatically. So it seems really useful, but also seems to be dangerous (I never killed a .vdi before).

For now, I have this screenshot. It shows the first MB of the broken (left) and a working Virtual Box vdi.
http://imgur.com/TI62Hbn

Please answer my question of what documentation led you to set this flag. Chapter and verse.

And a screenshot of a partial hex dump is pretty useless to me. Less useless would be a binary dump of the first 3MB of the file, zipped and attached directly here.

Along with the other information I already asked for.

Hello,

I don't have the .vdi here at the moment, I can upload later.

The option I have found here: http://www.jaysonrowe.com/2013/08/compa ... x-vdi.html and not in the documentation.

So, it seems implemented, but not documentated...

David.

Well, first of all (as one green-hat told me), I am shocked, shocked I'm telling you that people will follow online blogs and will not follow the instructions in the manual on how to compact a disk.

You didn't have to do any of this, i.e. make it an SSD and run the "ftrim" command. Plus, I'm not 100% sure, but I do believe that the "--discard on" command may be outright wrong, since from the little bit I could read from the source code, it points to a function "SetAutoDiscardForDevice" which does not mean what you think it means.