Jump to content
1812

Guide: Enable Trim on QEMU disk in MacOS/OSX

7 posts in this topic Last Reply

Recommended Posts

Tested on High Sierra and Mojave

 

I've been looking off and on about how to enable trim support on a disk image in osx. Had a few more minutes today and found it on the Internet (https://serverfault.com/questions/876467/how-to-add-virtual-storage-as-ssd-in-kvm)

 

 

Issue: QEMU disks in osx are presented to the OS in a manner which interprets them as a rotational disk, as shown under About This Mac>System Report>SATA/SATA EXPRESS.

 

2039511925_ScreenShot2019-06-08at4_39_36PM.png.b1b6f0e2cb2a8888c1ff5e883115ef07.png

 

 

Even after forcing trim on all disks via terminal, trim does not work, or even show it as an option. The result is the OS slows over time and disk images bloat.

 

 

To correct:

 

(if you're worried about potential loss of data, borking a working vm, or other world ending scenarios, make a backup before doing this, and proceed at your own risk.)

 

 

With the VM shutdown, edit xml settings, changing the disk image info  from

 

<disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source file='/mnt/disks/K/G/vdisk.img'/>
      <target dev='hda' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>

 

to

 

<disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/>
      <source file='/mnt/disks/K/G/vdisk.img'/>
      <target dev='hda' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>

 

with the changes only happening on the second line. (note: it may be possible to leave cache on write back and not use the io native setting, but I didn't experiment much, just followed working directions on the link)

 

make this change for any disk images you have that the vm uses.

 

next scroll to the bottom of the xml and add the following in the QEMU arguments

 

 

 <qemu:commandline>
    <qemu:arg value='-set'/>
    <qemu:arg value='device.sata0-0-0.rotation_rate=1'/>
  </qemu:commandline>

 

any other arguments you have will also still need to be included. I do not know if order matters, but mine is at the end of the arguments list.

 

 

if you have any other drives, add an additional copy of the argument (both lines) and modify the "device.sata0-0-0.rotat...." accordingly to match your address type listed at the top with the disk image(s). If you only have one, then you can leave it as is, assuming you didn't change the address.

 

If you did this correctly, the vm will boot normally. But this time will display:

 

618410586_ScreenShot2019-06-08at5_01_16PM.png.5b6da84164e167a0567b043420cb133f.png

 

Recognized as an SSD but no trim support. To fix this, you must force trim on all drives. To do this, go to terminal and enter:

 

sudo trimforce enable

 

It will then give you some text that makes it seem like your computer will eat itself. 

 

248083689_ScreenShot2019-06-08at5_03_30PM.png.61ba4a0f3409c2d592a30d1da629be8f.png

 

 

The OS will then sit for a short bit, after which time it will reboot itself. After it restarts, to verify trim support is now enabled, go back to About This Mac>System Report>SATA/SATA EXPRESS.

 

1748504670_ScreenShot2019-06-08at5_05_27PM.png.268d580673f66d30cadde79d01c21bf9.png

 

 

 

Enjoy!

Share this post


Link to post

Ran this on my mojave qcow2 vdisk and works. qcow2 disk start small by default but without being trimmed they grow as well so this should keep the size down. 

Share this post


Link to post

This thread initially seemed bizarre to me, but now I think I get it; I'd appreciate any feedback on my understanding:

 

On a real SSD, as I understand things, TRIM speeds up some writes and reduces wear on the flash chips by telling the SSD which blocks are no longer in use by the file system, so that the SSD controller can more efficiently deal with them.

 

So...for a virtual qcow2 disk image, enabling TRIM helps keep the dynamically-allocated disk image from growing more quickly than necessary?

 

And, assuming I'm right about that...are there any other advantages?

Share this post


Link to post
Posted (edited)
2 hours ago, bland328 said:

n a real SSD, as I understand things, TRIM speeds up some writes and reduces wear on the flash chips by telling the SSD which blocks are no longer in use by the file system, so that the SSD controller can more efficiently deal with them.

I'm no expert, but yes, and it "takes out the trash" when you delete a file, vs not really deleting the file, requiring deletion next time the "drive" attempts to write to those blocks, causing degraded performance while the write function waits. And additionally, over time, the lack of trash collection always seems to slow my disk image files after about 4-6 months of use. Which makes sense because if macOS thinks its a rotational disk, the data remains after deletion but is just blind to the os, essentially filling up the image. and when the data actually hits the ssd, having to deal with all the existing occupied blocks causes excessive overhead on ssd operations to perform basic functions that involve writes.

 

2 hours ago, bland328 said:

So...for a virtual qcow2 disk image, enabling TRIM helps keep the dynamically-allocated disk image from growing more quickly than necessary?

along with the discard=unmap in the xml, yes is should, , which releases the removed blocks back to the ssd, vs having a static mapped section that may be going unused in the vm. 

 

2 hours ago, bland328 said:

And, assuming I'm right about that...are there any other advantages?

better wear-leveling, meaning it's not writing to the same section over and over and over and over, where the image resides, causing premature failure of those blocks/sectors. 

 

there may be others as well.

Edited by 1812

Share this post


Link to post

Does this only work with vdisk image? Would it work with a passed-through sata ssd (via device-id)?

Share this post


Link to post
4 hours ago, testdasi said:

Does this only work with vdisk image? Would it work with a passed-through sata ssd (via device-id)?

 

it's been a while since I've passed an entire ssd to an osx vm. It would just depend on how macOS sees the drive. If it reads it w/out the quemu arg and other bits then you can check if trim is enabled or not (which I think for aftermarket drives you have to force enable anyways.) if its not recognized as an ssd, I don't know why it would not work, but again, I haven't tested it. I may have to do that just to see how it sees the disk.

 

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.