How to Increase SheepShaver Desktop Size Inside VirtualBox?

[Old-School-BBSer]

In Terminal.app:

Code: Select all

hdiutil convert -format UDSB -o <OS 9.0.4> <path/to/OS 9.0.4.dmg>

This will create an OS 9.0.4.sparsebundle bundle in the folder where you ran the command. So you might as well do

Code: Select all

cd <drag your SheepShaver folder onto window>

first.

Okay, let's take this a step at a time.

I had actually started making the sparsebundle when I suddenly realized that I only have about 21 GB left on my Mountain Lion VM virtual hard disk.

As such, I had to suddenly stop everything, and shut everything down, including my Mountain Lion VM and VirtualBox itself, because I didn't know how to stop the sparsebundle creation process that was going on in the Terminal.

So, even though I didn't want to, I went ahead and deleted my original SheepShaver installation that is in the El Capitan side of things. It's okay though, because I do have a backup of that version of my SheepShaver setup on my external USB drive.

But my question is this:

By deleting my original SheepShaver installation on the El Capitan side, I now have enough space to make that sparse bundle.

The question is, how do I alter the path in the Terminal in Mountain Lion, so that instead of making the sparse image on the Mountain Lion VM virtual hard disk, it makes the sparse bundle somewhere on the El Capitan side instead?

I had considered copying the 131 GB SheepShaver virtual hard disk file -- which is a .dmg image -- over to the El Capitan side, and then making the sparse bundle there. However, I can't do that, because even with deleting the original SheepShaver setup, there is still not enough space on the hard drive for both the .dmg image and the sparse bundle image. I would need over 260 GB of space, which I currently do not have.

That is why I need to keep the .dmg image on the Mountain Lion side, but make its sparse bundle version on the El Capitan side.

I can then copy the sparse bundle back into the Mountain Lion VM via my shared network folders.

Yes, it would be time-consuming work, but I am forced to do it this way due to hard drive space limitations.

So, I just need to know how to change that Terminal command so that it creates the sparse bundle on the other side, and not in Mountain Lion.

Thanks my friend.

[Old-School-BBSer]

Here is an update to my last message:

I FINALLY beat that rascal!!!

What I had to do -- and the ONLY thing that seems to work -- is that after mounting my shared network folder on the Mountain Lion desktop, in the part where I have to put the path to my output file, I simply dragged and dropped the mounted image of the shared network folder to the Terminal. It is finally creating the sparsebundle in my designated shared network folder on the El Capitan side.

Once it is done, I will simply open that same shared network folder from the Mountain Lion side, and copy it over to the Mountain Lion "SheepShaver" folder. It will take a while though, because it is 131 GB.

Here's to hoping for success!

[Old-School-BBSer]

I just wrote a short tutorial for myself as a reminder of how to do this. Please let me now if you find any errors in it:

HOW TO CONVERT A DMG IMAGE INTO A SPARSEBUNDLE IMAGE

In the Terminal, use this command line format:

Code: Select all

hdiutil convert -format UDSB -o <intended/name/of/sparsebundle> <path/to/input/dmg/file>

[/color]

1. Do NOT include the ".sparsebundle" extension in the name of the intended output file.

2. The sparsebundle will be created in the same folder from which the command line is executed. Thus, by default, when you first launch the Terminal app, this will be your Home folder.

3. There are two ways to change the location of the output sparsebundle so that it is not created in your Home folder:

--- a. cd to the output directory, if it is on the same volume you are working from. This way you only need to include the name of the output file in the command line, and not the path.

--- b. type in the path to the output file on the command line like this:

Code: Select all

<path/to/output/file/intended/name/of/sparsebundle>

4. To avoid path errors for the output file, an easy solution is to simply drag and drop the folder or volume into the command line after this part:

--- hdiutil convert -format UDSB -o

--- Then, once the path shows in the command string, add a forward slash right after it -- no spaces -- followed by the name of the output file, minus the ".sparsebundle" extension.

5. This same drag and drop method can be used to make sure that there are no errors in the path to the targeted input file as well. In other words, at the end of the command line where the name of the DMG file is to be added, just drag and drop the actual .dmg file there.

6. If all goes well, the hdiutil should then start creating the sparsebundle in the intended location on your hard drive or volume.

7. This same method of drag and drop can be used with network volumes, including with shared network folders, which mount on the desktop as images. Just drag and drop the mounted image into the command line, and that path will be added before the output file or input file.

[Old-School-BBSer]

Going with a fixed-size VDI just means that you've got a portion of your El Cap HDD that can never be used for other purposes, even if it only contains 0's on the Mt Lion side.

I don't imagine that there is an easy "lossless" way to convert a fixed-size VDI into a dynamically allocated one, is there?

If not, it sounds as if I would have to start all over and recreate my Mount Lion virtual hard disk image, which I am really not prepared to do. It would be too much work, and I am worried about losing something or breaking something in the process.

Besides that, at this point in time, I think that a conversion would be kind of pointless, because of the 161 GB or so which constitute by current fixed-sized VDI, only 20 GB remain unused. I don't intend to grow either my BBS or my Hotline server by adding more files to them; and neither do I intend to add a lot to Mountain Lion in general, being as I do most things from the El Capitan side. Thus, that extra 20 GB should be useful for quite a long time.

But you could also just do a full backup of Mt. Lion and then exclude the VDI file in El Cap -- that way you still have it all backed up, but aren't dealing with continual backups of large monolithic files.

I am seriously thinking about doing this, but there are some tricky issues involved here.

For one thing, I only have one external 2 TB USB backup drive right now, which is already divided into two partitions.

As I mentioned before, currently, I just back up my entire El Capitan hard drive to the larger of the two partitions on a daily basis. Only what has been changed on the hard drive is backed up to the USB drive.

Being as we are talking about performing TWO distinct backups, that creates a problem.

In CCC, there is a way to protect files from being written over, when a new daily backup is added to the destination backup volume, meaning my external USB drive.

However, being as we are talking about two backup tasks, that creates a complication, because it seems to me that I can't protect my El Capitan backup from being written over by the Mountain Lion backup, as well as protect the Mountain Lion backup from being written over by the El Capitan backup, because doing so would mean that nothing new would ever be written to the hard drive . . . or worse.

So the only solution seems to be to take my larger partition -- the second partition is already reserved for something else -- and divide it into two smaller partitions, so that there are now three partitions on the external USB hard drive.

Basically, I guess I would just have to erase that first partition, divide it accordingly, and then back up everything from scratch for both the El Capitan side -- minus the VDI image -- and the Mountain Lion side.

However, I am left with one mystifying question, to which I do not know the answer, being as I have not tried this out yet.

Mountain Lion is a VM inside of VirtualBox, inside of El Capitan. So, assuming that I take this three-partitions route, and I use one of them for a full Mountain Lion backup, what if something happens to my Mountain Lion installation, and I need to restore it by doing a reverse clone from the CCC Mountain Lion backup?

What I mean is, Mountain Lion is not a physical hard disk, so what would I tell CCC to reverse clone the Mountain Lion backup to?

Similarly, if something happens to my El Capitan setup, and I have to restore from my CCC backup, it seems to me that the problem there would be that if I perform a reverse clone back to my El Capitan setup -- which is basically most of my internal hard drive, it is going to wipe out my entire Mountain Lion setup, being as the VDI is NOT included in the El Capitan backup, and that is the ONLY place where Mountain Lion actually is now on my internal hard drive.

Stepping back from the trees a bit, am I correct to assume that the only real way to resolve this, is by REALLY starting over from scratch, and partitioning my internal hard drive into two, and then using one for a fresh install of Mountain Lion -- where I would now use the sparsebundle for SheepShaver -- and the other for El Capitan?

By doing that, I could then CCC all of Mountain Lion to its own partition on my external USB drive without a problem, and I could likewise CCC my new El Capitan setup to its own partition on the external USB drive as well. In that way, the twain would never meet, cross paths, or be able to foul each other up in any way. I could do a daily backup of each, which would be complete, and I wouldn't have to worry about fiddling with the VDI file or VirtualBox.

Yeah, we are talking about some very major, time-consuming work here. And no, I don't have the slightest inclination to do all of that. We are just talking theoretical here, as you seem to like to do.

I think for now, I will be happy with just continuing to do a complete backup of my internal hard drive, but this time with SheepShaver using a sparsebundle instead of the DMG. Just doing that will save at least an hour of backup time alone each day.

And as I said earlier, recreating my VirtualBox setup now using a dynamically allocated VDI, or trying to convert my current fixed-size one to dynamic, doesn't seem worth doing, being as there is only 20 GB or so of free space left on it anyway.

[adespoton]

I don't imagine that there is an easy "lossless" way to convert a fixed-size VDI into a dynamically allocated one, is there?

Ask, and ye shall receive

Er, in a while. Too busy right now to build this recipe :\ VirtualBox has a resize flag from the vboxmanage terminal command, and there's also a way to convert between archive types (but you'll need the space free to write the new file).

[Old-School-BBSer]

Trust me. I am doing quite the disk space juggling act here right now.

First I sacrificed the original El Capitan version of my SheepShaver folder in order to have space to create the new sparsebundle version of my Mountain Lion SheepShaver hard disk image on the El Capitan side.

Once the sparsebundle was created, I copied over my current Mountain Lion version of the SheeperShaver hard disk image file in .dmg format, just in case something went wrong.

Then I deleted the current Mountain Lion version of the SheeperShaver hard disk image file in .dmg format from Mountain Lion.

Finally, I am currently in the last 27 minutes of copying the sparsebundle from my El Capitan shared network folder, into my Mountain Lion SheepShaver folder.

Once that finishes, I will edit the sheepshaver_prefs file and see what we've got.

It is now 3:19 AM, and I have been trying to sleep on and off, with more off than on.

If this turns out okay, I will then delete the remaining Mac OS 9.0.4 .dmg hard disk image file from El Capitan's shared network folder.

Finally, I will recreate my CCC backup task. I had to in fact delete it temporarily, because it is scheduled for 2 AM, and that would have cut right into what I am currently doing here.

I will wait patiently for the very, extremely, amazingly magical fixed-size VDI to dynamically allocated VDI conversion formula.

BTW, I saved about 42 GB of hard drive space by converting from .dmg to .sparsebundle, but I already knew that I had that much free space inside my SheepShaver setup. I purposely created it large so that I had some breathing space. Plus, I have always read that you should never fill up a HD more than about 50% if you want to maximize the speed of disk reads and writes. Of course, I never follow that golden rule of Macintosh computing.

[adespoton]

https://www.virtualbox.org/manual/ch08.html

Code: Select all

VBoxManage clonehd <path/to/source.vdi> <path/to/destination.vdi> --variant Standard

This will make a copy of your vdi file using the standard "use only what you need" option. After doing this, you may also want to do

Code: Select all

VBoxManage modifyhd <path/to/source.vdi> --resize <megabytes>

to give your guest VM more space to grow into, should the need arise. You'll also need to go into Disk Utility in your guest and expand the volume to use the newly allocated space.

Another useful thing to do is use Disk Utility inside the guest VM to zero out unused disk space (select Erase Free Space and then select Zero Out Data). Next, do

Code: Select all

VBoxManage modifyhd <path/to/source.vdi> --compact

This is only useful if you've been copying large bits of data in and out of your disk image (which you've now been doing). It can free up a sizeable chunk of space on your host's HD. This is also a reason not to set the --resize value above too large; with a smaller value, you'll keep overwriting the limited disk space. With a larger value, your .vdi could keep growing to the resize value, even if the actual space used inside is minimal.

[Old-School-BBSer]

Thanks again, Adespoton. You have been a tremendous help to me, and I have been carefully watching, reading and documenting everything for future reference.

Just a minute ago, as the email notification for this message from you arrived in my in box, I booted up SheepShaver using the new sparsebundle for the very first time,

Houston, we have liftoff! It is a go!

Regarding that second command in your previous message, so basically, I can re-add 20 GB of breathing space to my new dynamically-allocated VDI, if I want to, but it will only be added, as and when it is actually needed, correct?

When you have time, can you please re-read my previous message where I discuss my CCC backups and the complications involved? I'd appreciate your insights.

Thanks again!

[Old-School-BBSer]

In addition to my previous message . . . and just to clarify . . .

All of the "VBoxManage" Terminal commands are done from the El Capitan side, correct?

Erasing free disk space with Disk Utility is done INSIDE the Mountain Lion VM itself, correct?

Expanding the volume to ensure that my Mountain Lion VM has enough physical disk space to grow is the one that leaves me confused.

I can't do that from within Mountain Lion, because it is not a real partition. It is just a VM, right? And even if it was a real partition, you can't expand a partition from within itself, right. I mean, I would have to expand it from the level of my entire hard drive, being as that is where I will see the various partitions in Disk Utility.

Yet neither can I expand Mountain Lion's volume from the El Capitan side either, because VirtualBox VM's aren't real partitions. Thus, they won't even show up in Disk Utility, right?

So what am I not understanding from this last one? It's probably so obvious that I will feel stupid when I hear the answer.

[adespoton]

In addition to my previous message . . . and just to clarify . . .

All of the "VBoxManage" Terminal commands are done from the El Capitan side, correct?

Erasing free disk space with Disk Utility is done INSIDE the Mountain Lion VM itself, correct?

Expanding the volume to ensure that my Mountain Lion VM has enough physical disk space to grow is the one that leaves me confused.

I can't do that from within Mountain Lion, because it is not a real partition. It is just a VM, right? And even if it was a real partition, you can't expand a partition from within itself, right. I mean, I would have to expand it from the level of my entire hard drive, being as that is where I will see the various partitions in Disk Utility.

Yet neither can I expand Mountain Lion's volume from the El Capitan side either, because VirtualBox VM's aren't real partitions. Thus, they won't even show up in Disk Utility, right?

So what am I not understanding from this last one? It's probably so obvious that I will feel stupid when I hear the answer.

1) correct
2) correct
3) First you expand the disk image's capabilities, then you expand the logical partition from Mt Lion guest, as its Disk Utiility will report more space available to use, but your partition size hasn't changed. As far as Mt Lion is concerned, it's on bare metal. So you first have to expand the disk image, and then from *inside* you can expand the partition stored on the image to use the extra space. This can be done non-destructively (meaning you don't have to repartition, just expand the existing partition to use up the extra space).

[adespoton]

Regarding that second command in your previous message, so basically, I can re-add 20 GB of breathing space to my new dynamically-allocated VDI, if I want to, but it will only be added, as and when it is actually needed, correct?

Correct. But you'll need to follow the steps I outlined to *reclaim* space that you have used (for, say, an old disk image you've thrown in the trash) that is no longer being used. VirtualBox won't clean up after you.

[adespoton]

Mountain Lion is a VM inside of VirtualBox, inside of El Capitan. So, assuming that I take this three-partitions route, and I use one of them for a full Mountain Lion backup, what if something happens to my Mountain Lion installation, and I need to restore it by doing a reverse clone from the CCC Mountain Lion backup?

What I mean is, Mountain Lion is not a physical hard disk, so what would I tell CCC to reverse clone the Mountain Lion backup to?

Similarly, if something happens to my El Capitan setup, and I have to restore from my CCC backup, it seems to me that the problem there would be that if I perform a reverse clone back to my El Capitan setup -- which is basically most of my internal hard drive, it is going to wipe out my entire Mountain Lion setup, being as the VDI is NOT included in the El Capitan backup, and that is the ONLY place where Mountain Lion actually is now on my internal hard drive.

Stepping back from the trees a bit, am I correct to assume that the only real way to resolve this, is by REALLY starting over from scratch, and partitioning my internal hard drive into two, and then using one for a fresh install of Mountain Lion -- where I would now use the sparsebundle for SheepShaver -- and the other for El Capitan?

Ah, the beauty of virtualization vs emulation

VirtualBox has no problem attaching external USB devices to virtual machines. So if you accidentally blow away your Mt Lion VM, you either restore the VM sans vdi, or quickly create a new one. You then add a new blank vdi and link your USB drive by going to your VM settings->USB->Add USB filter and select the drive. Then you start your VM, and it boots off the external drive, allowing you to finally use CCC on the external drive to restore to the brand new blank vdi.

So as far as CCC and your USB drive are concerned, Mt Lion IS the environment you're working in. They don't have to know that the hard drive is actually a file stored on another OS.

You also have the interesting feature where you could always dual-boot your actual hardware into El Cap/Mt Lion by restoring your backup to a partition on the physical drive -- but why do that when we can virtualize?

[Old-School-BBSer]

3) First you expand the disk image's capabilities, then you expand the logical partition from Mt Lion guest, as its Disk Utiility will report more space available to use, but your partition size hasn't changed. As far as Mt Lion is concerned, it's on bare metal. So you first have to expand the disk image, and then from *inside* you can expand the partition stored on the image to use the extra space. This can be done non-destructively (meaning you don't have to repartition, just expand the existing partition to use up the extra space).

Okay, I think I have finally grasped what you are saying with this one. "First you expand the disk image's capabilities" is referring to this:

Code: Select all

VBoxManage modifyhd <path/to/source.vdi> --resize <megabytes>

And after I do that, when I use Disk Utility inside of Mountain Lion, it will suddenly report that there is more space available for the partition to grab.

Right now I am still in the process of converting the original 161 GB .vdi file to the "standard" version. The new .vdi image is currently about 95 GB in size, and stands at 70% done according to the Terminal. I am assuming that when it finally completes, it will be around 140 GB in size, since I already know that there are about 20 GB of free space inside of Mountain Lion at this time.

After that, I will perform the remaining steps in the order that you outlined them in your previous message.

[Old-School-BBSer]

Ah, the beauty of virtualization vs emulation

VirtualBox has no problem attaching external USB devices to virtual machines. So if you accidentally blow away your Mt Lion VM, you either restore the VM sans vdi, or quickly create a new one. You then add a new blank vdi and link your USB drive by going to your VM settings->USB->Add USB filter and select the drive. Then you start your VM, and it boots off the external drive, allowing you to finally use CCC on the external drive to restore to the brand new blank vdi.

So as far as CCC and your USB drive are concerned, Mt Lion IS the environment you're working in. They don't have to know that the hard drive is actually a file stored on another OS.

You also have the interesting feature where you could always dual-boot your actual hardware into El Cap/Mt Lion by restoring your backup to a partition on the physical drive -- but why do that when we can virtualize?

My gosh! Where is the Tylenol! You just gave me a headache! I am going to have re-read that one about 20 times before it even begins to sink in.

I mean, my gosh, even this whole setup from start to finish is so bizarre.

[Old-School-BBSer]

Okay, the new "standard" .vdi has now been cloned. It is actually only 108 GB in size, compared to the 161 GB of the original. I forgot to take into consideration that I converted my SheepShaver virtual hard disk image into a sparsebundle, thus saving an additional 43 GB.

At any rate, just now, I renamed the original .vdi by adding "-original" to its name, and then I moved it to another place on my hard drive.

After that, i put the new vdi in there, bearing the same name as the original one.

However, VirtualBox reported that the drive was not accessible, so I took out the new one, and put the original one back in.

Can I just take the new one, give it the same name as the original, and then let the system replace the original one with the new one when I drag it in there?

Or will it reject it because maybe it has a different UUID? Just guessing here.

My concern here, is that I don't have enough hard drive space to make a copy of the original .vdi, in case something goes wrong when I let the new .vdi overwrite the original .vdi. So either it works, or my goose is cooked!

It is either take the risk, or spend another couple of hours backing up the original vdi to my external USB drive first.

I am SO tempted to just be reckless!!!

[adespoton]

You can't just move things around in VirtualBox; you need to either use vboxmanage or the UI to detach the old image and attach the new one. They have their own unique serial identifiers in VirtualBox that it uses to manage them -- that way you can do the tricky things with writethrough and shared images etc. that we're not going to get into here

Just go into your settings for the VM, remove the old vdi, use the + to add a new one, and select it. The rest should happen automatically.

[Old-School-BBSer]

And you tell me this after I have already copied over the first 107 GB to my external USB drive.

Okay . . . I will do it YOUR way . . . Ahem . . . I mean the correct VirtualBox way.

that way you can do the tricky things with writethrough and shared images etc. that we're not going to get into here

Oh please, please!

PS: Dear Mr. VirtualBox,

I am a long-time Macintosh man! I am a drag 'n drop man! It is in my blood! I get the shakes when my hand cannot grab the mouse and drag and drop things all over my desktop, wherever I please!

You are cruel, cruel, cruel, Mr. VirtualBox, for trying to change my long-time habits. Shame on you!

[Old-School-BBSer]

Please help me to understand this . . .

My original fixed-size .vdi image was about 160-161 GB in size.

After I converted it to a dynamically-allocated .vdi image, it was reduced to 108 GB and something.

I just completed compacting it via that Terminal command, so now it shows 82.97 GB in the Finder.

However, what confuses me is the following . . .

When I launch VirtualBox and have my Mountain Lion VM selected on the left side of the "Oracle VM VirtualBox Manager" window, on the right side of that same window, under the "Storage" section, it states in part:

Controller: SATA
SATA Port 0: Mountain Lion.vdi (Normal, 150.00 GB)

Why does it say 150 GB still?

When I actually start the VM, in the status bar at the bottom of the Mountain Lion window it says "63.3 GB available."

I don't understand that. I know from running SheepShaver outside of a VM, that, at least on a .dmg image, I have 131 GB of actual data, divided between the OS, my BBS and my Hotline server.

So how can there be 63.3 GB of hard drive space left, on a .vdi image that the Finder claims is 82.97 GB in size, and how can 131 GB of original data supposedly fit in only about 20 GB of space. In other words, I rounded out the numbers and subtracted the 63 GB from the 83 GB.

To add to the confusion, when I launch Disk Utility inside of Mountain Lion, it shows the following:

Capacity: 160.2 GB
Available: 63.3
Used: 96.9

Why does Disk Utility say 160.2 GB, VirtualBox says 150 GB, and Finder says that the .vdi image is 82.97 GB?

I understand that there is this thing between the allotted/dynamically-allocated space granted to the virtual hard drive, and the amount of space that it is actually using, but I still don't understand how these various figures jive above. It is very confusing.

On related notes:

I discovered quite by accident that when you convert from fixed-size to dynamically-allocated size, you cannot name the new .vdi image the same as the original one.

What happened is this . . .

After you explained to me that you cannot just drag and drop, and replace .vdi image files in typical Macintosh fashion, I did as you said and unattached the original .vdi first via the VB Manager window. I left the original one in the same folder, but added "-original" to its file name, so that I could drag the new .vdi file , which bore the same name as the original file, into the folder.

Well, when I restarted VirtualBox, it said that the disk was not accessible. I unattached and reattached the new .vdi file a few times, and finally realized that VirtualBox was confused, because the new .vdi bore the same name as the original one, yet has a different UUID. It wasn't until I renamed the new .vdi to something else, removed the original vdi from that folder, and also deleted all of the previous log files, that it finally accepted the new .vdi image as being valid. I think I rebooted VirtualBox a few times as well in the process of getting it to work.

Now, regarding wiping free space in Disk Utility . . .

First, just to be safe, I verified the disk. It took three times, because the first two times it apparently got stuck while examining/verifying something. I can't remember what now, but it was just the second line that appears in the window when you verify a volume.

After verification finally succeeded -- it reported that the disk is okay -- I tried several times to wipe the free space. It would start by saying that 1 minute was left, then eventually go up to 10 minutes or so being left, and then begin to drop back down again. It would get to 2 minutes remaining, and then say that it was creating a secondary temporary file, or something like that. I think that was the name of it.

However, after a bit, it would seem to get stuck, and then a warning would come up stating that I was running out of disk space, and that I needed to delete some files, even though the status bar in the Finder window still clearly showed that I had 63.3 GB of free space.

As I said, I tried several times, and each time, Disk Utility reported failure.

Well, I decided to compact anyway, and that is how I ended up with the current .vdi image of 82.97 GB, according to the Finder at least, as opposed to the original 161 GB fixed-size disk.

So I am not sure what to make of all of these size discrepancies.

Whatever the case may be, VirtualBox and my Mountain Lion VM appear to be running fine.

I am now going to make a brand new CCC backup of the entire hard drive -- Mountain Lion, El Capitan, everything at once -- as I was doing previously.

I'll worry about the other stuff we discussed -- various partitions, two separate scheduled CCC backups, omitting .vdi from El Capitan backup, etc. -- later, after I better understand that last message that you left for me.

[adespoton]

Good to see the progress!

Why does Disk Utility say 160.2 GB, VirtualBox says 150 GB, and Finder says that the .vdi image is 82.97 GB?

I think that's the core of your question, so let me explain

The VDI image takes up 82.97 GB (currently) on your El Cap drive.
VirtualBox has allocated a virtual 150GiB as the maximum the VDI image can take up.
Disk Utility inside Mt Lion is reporting 160.2 GB of logical storage space in which to store files.

Note the GiB and GB. Starting... when? Lion? Apple moved from reporting data in GiB (1024 MiB) to GB (1000 MB). As such, the same data reported in GB is going to be a larger number than the data reported in GiB -- in your case, 150GiB = 161.061 GB. The missing 0.861 GB is likely taken up with filesystem data, and so is not available for the logical volume.

[adespoton]

Regarding your "out of disk space" issue:

When you zero out space on a drive, it does pretty much what we used to do with Norton Utilities and called "defragmentation" -- all the data blocks on the disk are shuffled around so that data is contiguous, and then the free space is wiped. Because you've got one set of HUGE files in there (your sparsebundle), some of them are larger than the space left on disk, and so can't be moved to another "physical" location on disk to re-order the blocks. So you get that error.

Not a problem; it just means that if you moved that off disk, compacted again, copied back on disk, compacted again, you'd have a slightly smaller vdi as a result. Apple's SparseBundles do a better job of managing this stuff than VirtualBox's VDI files, because they have to deal with fewer variables, and the OS is designed to actively manage the files.

[Old-School-BBSer]

So basically, everything is A-Okay.

Thank you for the explanations. I appreciate it.

I successfully performed two CCC backups. Each time, about 84 GB of changed data was copied over to my external USB drive. That is about 50 GB less than before, and I am saving about an hour's worth of backup time each time, so I won't complain. One hour and fifteen minutes of backup time each day is worth the wait, in order to have the peace of mind of knowing that nothing will be lost.