virtualbox.org

Hello everybody! I might be asking an obvious question, but still I could not find a clear answer anywhere on the web.
If I use windows xp guest on windows 7 host with an SSD, will the guest machine inherently use gently the host machine's SSD drive (trim, etc.)
In other words, is it safe, in terms of SSD wear out, to run windows xp guest on a windows 7 host and SSD drive, compared to normal
work and tasks on the host system?

I would deeply appreciate if one could explain in greater details the answer for complete understanding.
Thank you in advance for the help!

The guest doesn't inherently use the hosts anything. It's a VM. It's "disks" are really just host files. Locate the files anywhere you want.

mpack wrote:The guest doesn't inherently use the hosts anything. It's a VM. It's "disks" are really just host files. Locate the files anywhere you want.

Thank you for the reply. So if I understand it right the read/write operations of the XP VM to the virtual disk (which is a file) are handled by the Host OS (which in my case is Windows 7, which is "SSD-aware"), right?
And hence, the SSD is treated in a gentle way.

Yes, the "virtual disk" is just an ordinary file on the host, so everything else follows from that.

Nice to know. Especially, since there does not seem to be a reached consensus on the web. For example (from http://social.technet.microsoft.com/For ... ine-on-ssd):

Rick Dee wrote:

jeProject wrote:Surely the host OS is where the trim command will be used...
As far is the XP virtual machine goes it's no different to any other application running on the host, saving a file to the SSD.

But there is a difference. The XP VM is an Operating System running applications. Not a single application running. The XP VM would still have a Page File and perform all the functions an OS performs. Therefore, the XP VM would generate more activity that a single application would. The XP VM would be totally oblivious to the fact that it is running on a SSD.

I am nothing else than layman, but it seems to me there is no automatic defragmentation in XP, and no use of Superfetch and ReadyBoost technologies either. It also seems to me pagefile usage, allocating the VM sufficient amounts of RAM, would be no worse than the one in modern OSes such as Windows 7 or Ubuntu (14.04).

TRIM support would be the sole lacking SSD-optimization feature, but it is already handled on the host. Meaning, there would be no much difference, in terms of hardware wearing, between running a Windows-7- and a XP guest under any modern-enough operating system, given the SSD tickbox (useful in the first case) has been checked in VirtualBox's settings, let alone running a native Linux Mint 17. Care to differ?

I don't know how else I can say this: a VDI is just a file on the host. The nature of the application that created the file is not relevant. The host OS will manage this file like any other. I can't help what nonsense you may have read elsewhere.

Alright. Further exploration from my part has shown no downsides at all to using virtualized XP on an SDD (as opposed to running it natively). I'd still be open to potential inconvenients in the future, though (if there are to be at all!).

(Page-file usage can be monitored, for reference, running perfmon (using the run shell), then clicking the plus button, adding the paging-file performance object to the graph. Even running with 512 MB of RAM, no dedicated swap space might be put to contribution, which is a wonderful indication concerning SSD compatibilities.)

EDIT: here are what look like some downsides to it: http://www.mysolutions.it/tips-migratin ... ws-xp-ssd/
(for example, the default "hard drive optimization" feature; some seem okay though, such as file indexing.)

mpack wrote:Yes, the "virtual disk" is just an ordinary file on the host, so everything else follows from that.

Got it! Thank you for the help!

Presuming trimming is implemented as it should from the host, it isn't clear to which extent though guest HDD idle optimization produces SSD wear.

I've read quite some articles on the subject, but it might boost my understanding of this scenario if someone as knowledgeable as mpack concerning XP virtualization on SSDs ever wrote some guide on the subject. The implications sure are multiple! I do not yet understand the frequency of trimming in such circumstances, nor the inner functioning of it all. I need more reading or reflection.

EDIT: it seems (at least over here!) this "optimize hard disk when idle" tickbox was unchecked by default. I would advise one to check out others of their settings, too (such as if file indexing is present, if disk-write caching is enabled or not, etc.).

The sole thing I do not yet understand is the manner timming works. Does it work real-time? Is the frequency of trimming the .vdi file resulting in the same wear or non-wear than the frequency trimming would occur if XP were ran natively (although somehow supported the feature)?

EDIT: or is the answer just obvious, and I am too slow to understand the inner workings of computers?

Trimming doesn't normally apply to guests because VirtualBox never returns disk space to the host, i.e. the VDI never shrinks so there's nothing to trim. You can override that by running a compaction of the disk every now and then. Naturally you should avoid all use of snapshots.

Okay. Also, I have spent the last few hours reading stuff. I have learned, for example, that:

mpack wrote:There is no passthrough or other processing of the TRIM signal under any circumstances, even if you are using VDI [or ticking the SSD option]. The sole purpose of the feature is to set a flag which a modern guest picks up, causing it to e.g. not defrag in the background.

My main worry was that since in the guest, I am always writting to the same sectors (constituting about a thousandth of the space), the SSD would prematurely wear.

Would you be suited to expand a little bit on the manner modern OSes might apply their wear-leveling functionalities, as relating to virtual-machines usage? Or, to point to some pertinent reading on the matter? (I have spent much of my free time this week exploring this, to no avail.) I know you have mentioned running the --compact command, but I am failing to see how this can prevent wear leveling, especially in the above-described scenario.

EDIT: I am recognizing that I had trimming and wear leveling garbled up in my mind. Trimming might not even help the disc lasting longer. Wear leveling seems performed hardware-side, right from the SSD controller, therefore it knows all and is omnipotent. The guest needs not to report anything to it for the disc to last longer. Therefore, VirtualBox (virtualizing a properly-configued XP) would be as gentle to it as would a native, modern OS be.

EDIT2: Reserving free, unpartitioned disc space (e.g., about 30%) might facilitate internal wear-leveling operations. The rest of the optimizations to reduce wear-and-tear inconveniences seem to lie in fiddling with guest internal settings, such as disabling automatic defragmentation, the file-indexing service, enabling write caching, and disabling (or leaving disabled) hard-drive idle optimization.

I would be happy for someone to ever prove this wrong, as it would contribute to advancing my own understanding of the topic.

Sorry, that's beyond the scope of these forums, and not something I need to know a lot about. Suffice to say that you can set the SSD flag to let the guest OS know that this disk should be treated as an SSD. What the guest OS does with that information is it's own concern. Presumably it will do many things a little differently. Some popular guests will do nothing, because SSDs are after their time (e.g. XP if using native hdd drivers).

Alright. Thanks for the time, especially considering this is out of the scope of this forum

Let me just leave this link for reference purposes, as one might get educated by it: http://forum.notebookreview.com/solid-s ... -trim.html (and therefore, perhaps individuals using this forum could get to do so in a more-educated manner -- or get to become less confused, to put it in a somewhat less-bluntly way!).

The linked-to thread states (without TRIM) that "to avoid permanent damage, one should reserve 33% of disk capacity (as unpartitioned, never-used space) for internal wear-leveling operations."

yours,
twipley