virtualbox.org

On win10 64bit LTSC as a guest (with VB v.6.1.26 and Win10 64 as a host), I start having error 0x800F0922 in the latest win updates. There is still 10Gb of free space, but the error seems compatible with "not enough disk space" for the update.
I saw the way (using File/Virtual Media Manager...) to extend the size of the .vdi, now at 50Gb. I wanted to add at least other 10Gb, to see if the error disappears.
I have several snapshots on that machine. I know that here the suggestion is not to have them, but I got the message after having created them.

The question:
Do I need to merge or delete them before the "add space" to the vdi, or the addition can be done with snapshots in place. In this latter case, there are risks of corruption, or the practice is rather safe? What is the best practice, given the situation?

Thank you

How to Resize a Drive has a section on snapshots.

The process ought to work well, but one can never tell when the host PC might have a glitch. It is very strongly recommended to shut the VM down fully from within the VM's OS, then copy the VM's complete folder, as well as any drive files existing outside the folder, to some backup media or two, and file-compare the files to check backup integrity, before editing any VM with snapshots.

@scottgus1 thanks for link and suggestions.
Backups are always helpful, sometime however they are time and space consuming.
In my case the vdi is set to 50GB, but with snapshots its folder arrives almost to 300GB.

For that reason I was trying another safe strategy, that avoided backing up the whole 300GB.
For instance - I am asking - is it advisable to clone that machine, and then extend the vdi space on the cloned machine?
Does the cloned machine include all snapshots, in a unique vdi, within 50GB of the original space, so to extend it without too many risks?

Thanks again.

Top tip: if you are concerned at all about disk space then stop using snapshots.

Backups need not consume any space at all on the host drive as they can be moved to secondary storage, unlike snapshots. You VM never needs to occupy more than 50GB.

When cloning a VM you are given the choice to preserve snapshots or not. I recommend not, and learn how to make and restore proper offline backups. Note however that a clone is not a backup either, it is a new VM with different UUIDs. This can cause software to be deactivated, particularly Windows guests, Office apps etc (if not cloud based).

In addition to Mpack's thoughts above:

science2002 wrote:Backups are always helpful essential

FTFY. If you care about the data, that is. Depends on how much you'd cry if the data was lost. And don't forget:

scottgus1 wrote:one can never tell when the host PC might have a glitch.

We have no idea the state of your computer's health. Thus the recommendation to back up before putting your drive and PC through a real data throughput test to adjust the snapshotted VM. Trapeze without a net is very exciting, until you slip. It's your call, but we can't help if the VM doesn't work because your host drive starts pushing sector errors unexpectedly.... I'd back up.

science2002 wrote:300GB.

1TB external spinning-platter drives are super cheap. Multi-TB's are the order of the day. Cost and size are not real limits for backups nowadays.

@mpack, thanks. I know from your previous posts the suggestion of avoiding snapshots.
However I started reading it, and followed it, when snapshots were already in place: history cannot be changed.

You point out that cloning is not backing up, since it gets different UUIDs. On this point, I notice that in the Clone window like the following:
https://docs.oracle.com/en/virtualizati ... one-vm.png
there is a first option to "keep disk names" and another option to "keep hardware UUIDs" (If I am not wrong that means "keep *the same* etc.). By selecting the latter (or both of them), one does not solve the problem you mention? Or also this kind of feature(s), is better to avoid, since it creates problems like snapshots?

Yes, the cloning feature of VirtualBox now does give you the option to keep the hardware UUID. Keeping disk names has no relevance here, as the guest has no idea what files are called on the host. Whether these things are enough to maintain activation, who knows - and why risk it? Cloning is used when you want to have two active VMs, not when you want to make a backup. The procedure for making a backup is dead simple: copy the VM folder contents to a backup medium. Not run some fancy tool.

mpack wrote: Cloning is used when you want to have two active VMs, not when you want to make a backup. The procedure for making a backup is dead simple: copy the VM folder contents to a backup medium. Not run some fancy tool.

Yes, but you start from a premise that in same cases - like mine - is not true. There are several snapshots already in place, and one wants to obtain a "clean" (or the cleanest as possible) machine from a given "current status". So that one could then extend the vdi size, make vdi backups (without snaphosts), etc. I thought that a rather straight forward way to achive it was to use clone. That would avoid to strip down the original machine, by merging/deleting snapshots --an action more prone to errors.
When one has cloned the machine and tested it, one could delete the older one altogether. In theory I found a logic in these steps, given the premise. I do not know if it remains or not true in practice, or if there are other better steps to follow, taking into account - as I said - the premise.

Cloning is possible, but it has the risks already discussed.

If you want zero risk then make a proper backup, then delete the snapshots.

Once the modified VM is tested and known to be working you can make another backup, deleting the older one with snapshots.