VirtualBox

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#20961 closed defect (invalid)

VBoxManage clonemedium truncates output disk image

Reported by: Trevor Hemsley Owned by:
Component: virtual disk Version: VirtualBox 6.1.34
Keywords: disk truncation corruption Cc:
Guest type: Linux Host type: Linux

Description

I tried to convert a vbox disk image from one format to another and the resulting output was corrupted.

I set up a vbox VM to install RHEL 9 and this created a RHEL9.vdi file. I then decided to copy this to a different medium so created a DRBD device of 8GB replicated between systems. The file used to perform the installation was

[trevor@trevor4 ~]$ qemu-img info /mnt/stuff/VDI/RHEL9/RHEL9.vdi
image: /mnt/stuff/VDI/RHEL9/RHEL9.vdi
file format: vdi
virtual size: 8 GiB (8589934592 bytes)
disk size: 2.35 GiB
cluster_size: 1048576

I used

[trevor@trevor4 ~]$ VBoxManage internalcommands createrawvmdk -filename /mnt/stuff/VDI/RHEL9/rhel9.vmdk -rawdisk /dev/drbd7
RAW host disk access VMDK file /mnt/stuff/VDI/RHEL9/rhel9.vmdk created successfully.

to create the new target device and then

[trevor@trevor4 ~]$ VBoxManage clonemedium disk /mnt/stuff/VDI/RHEL9/RHEL9.vdi /mnt/stuff/VDI/RHEL9/rhel9.vmdk --existing
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone medium created in format 'VMDK'. UUID: 980405fa-2e93-4b05-af98-586b78c18524

Now went into the settings for my RHEL 9 VM and detached the old disk and added the new rhel9.vmdk in its place and attempted to boot up. The boot process dropped to an emergency shell as the /boot filesystem was corrupted and was truncated. On the disk partitioning, /boot was a 1GB primary partition located at the far end of the disk. Looking at the stats for the output file for the clonemedium I can see that it was not large enough to contain the disk copy.

[trevor@trevor4 ~]$ qemu-img info /dev/drbd7
image: /dev/drbd7
file format: raw
virtual size: 8 GiB (8589635584 bytes)
disk size: 0 B

So 8589635584 is 299008 less than 8589934592 and I believe the clonemedium command should have ended with an error. It did not. Perhaps this was because the extra space in the source file had never been used and was 'sparse'. In any case I would expect an attempt to copy 8589934592 bytes to a device that is only 8589635584 bytes should fail and it did not.

I don't think DRBD plays a part in this problem. This is just about copying one larger disk image to a smaller one and ending up with a corrupted disk.

Change History (2)

comment:1 by aeichner, 2 years ago

Resolution: invalid
Status: newclosed

This works as designed, please read the documentation for the --existing parameter here.

comment:2 by Trevor Hemsley, 2 years ago

That is utterly stupid behaviour and should be fixed. It should at least TELL you it was not able to do it.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use