[SOLVED] Clonemedium from VDI to VMDK Stream variant

[Skilly]

Hello, all,

After cloning a VDI to a compressed ("Stream") VMDK, my Arch Linux guest VM cannot write to the disk.

I used the following command to clone a dynamically allocated VDI disk into a compressed VMDK:

Code: Select all

vboxmanage clonemedium disk arch-base.vdi arch-base.vmdk --format VMDK --variant Stream

This does not print any error messages. When I then add the hard disk to a VM, a Snapshot differencing image is created but according to the Virtual Media Manager, it is also "Dynamically allocated compressed storage" and it is my understanding that this format is read-only. I notice also that every time I open the VM's settings, the compressed VMDK still has the blue dot which I usually only see just after adding the VMDK (the tool tip that appears when I hover over it says that a newly created differencing disk will be used, but it says this even after closing VirtualBox and relaunching).

I cannot tell if this is a bug or a misconfiguration on my end. In the past, when I created a stream VMDK, a non-stream VMDK was automatically created for differencing. How do I do that now?

[mpack]

Moved to "Using VirtualBox" since your Q has nothing whatever to do with "Windows Hosts". Please choose a forum which is appropriate to your question.

It isn't possible to write to stream oriented VMDK. Frankly, I don't know why it is even possible to use one in a VM. Stream format VMDK is intended to be used in OVA appliances (VM import and export). VirtualBox must support the stream format for that reason. The format is never writable. In the VirtualBox case, instead of telling you this plainly, it creates a difference image to contain the changes. Naturally the difference image is writeable, that's the whole point of it.

[Skilly]

Hi, mpack,

Thanks for your reply and moving my post to the right forum; I'm sorry that I didn't post it here in the first place.

I am trying to convert to a Stream VMDK because in the past, I perceived that my VM boot times were between 25-50% faster compared to an uncompressed VDI or VMDK.

The format is never writable. In the VirtualBox case, instead of telling you this plainly, it creates a difference image to contain the changes. Naturally the difference image is writeable, that's the whole point of it.

This has always been my understanding in the past yet when I tried to configure this yesterday, my guest complains that the disk is read only and when I attempt to remount the virtual disk with

Code: Select all

mount -o remount /

, I get "WRITE DMA" errors. I will try an older version of Virtualbox to see if I can duplicate the behavior and post back.

[Skilly]

I just uninstalled 5.0.24 and installed 4.3.38 and now when I attach the compressed VMDK, a ~12MB "Dynamically allocated differencing storage" file was created as opposed to the ~78KB "Dynamically allocated compressed storage."

[Perryg]

Given this works in 4.3.* and fails in 5.0.* I would post this at bugtracker as a regression. There was a lot of work in this area and I bet a typo is involved.

[mpack]

I would be surprised if stream oriented VMDK was faster than a normal VMDK or VDI, in general. In the stream oriented scenario every read of a block has to go through an additional decompression layer, through code that won't have been designed to be particularly fast. Yes, there is less data to shift, and in the right circumstances (e.g. excessively slow host drive), then perhaps the faster I/O would redress the balance. But the downsides for me are far too great. Bottom line: stream oriented VMDKs simply aren't designed for this purpose. They are designed for a scenario where you have to decompress the VM before use.

I just uninstalled 5.0.24 and installed 4.3.38 and now when I attach the compressed VMDK, a ~12MB "Dynamically allocated differencing storage" file was created as opposed to the ~78KB "Dynamically allocated compressed storage."

The size of the VMDK is determined by how much writing (to the compressed drive) the guest OS does during booting. Obviously this will be variable, perhaps with VirtualBox version, certainly with guest OS version and boot mode, VM settings (particularly RAM) etc.

I don't understand what your mount command is doing, so I won't comment on that without seeing the VM log and ideally the .vbox file, both packed in one zip.

[Skilly]

I see a note on the 5.0.24 changelog that mentions a change to stream-optimized VMDKs:

Storage: fixed a possible corruption of stream optimized VMDK images from VMware when opened in read/write mode for the first time

I'll try 5.0.22 and see if the issue is still present there and then open a bug report.

[Skilly]

Just an FYI to possible future readers, this was an issue introduced by https://www.virtualbox.org/ticket/14764 that was fixed at least by 5.1.6 (possibly earlier in 5.1.x).

[socratis]

Thanks for the followup Skilly!