Skip to content

Error while creating the raw disk VMDK

I have been attaching raw disks to VirtualBox before but I missed one particular detail: apparently one cannot attach disks readonly. But that's exactly what I wanted to do, I did not want the VM to be able to alter the disk in any way:
$ ls -l ../disk3.img
-r--------  1 christian  staff  3965190144 Nov 26 12:18 ../disk3.img

$ hdid -nomount ../disk3.img
/dev/disk3              FDisk_partition_scheme          
/dev/disk3s1            DOS_FAT_32 

$ diskutil list disk3
/dev/disk3
   #:                       TYPE NAME              SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                   *4.0 GB     disk3
   1:                 DOS_FAT_32 CANON_DC           4.0 GB     disk3s1

$ ls -l /dev/disk3*
br--r-----  1 christian  staff   14,   9 Nov 28 18:20 /dev/disk3
br--r-----  1 christian  staff   14,  10 Nov 28 18:20 /dev/disk3s1

$ VBoxManage internalcommands createrawvmdk -filename ../disk3.vmdk \
             -rawdisk /dev/disk3 -partitions 1 -register
ERROR: VMDK: could not open raw partition file '/dev/disk3s1'
Error code VERR_ACCESS_DENIED at \
/Users/vbox/tinderbox/3.2-mac-rel/src/VBox/Devices/Storage/VmdkHDDCore.cpp(3661) \
in function int vmdkCreateRawImage(VMDKIMAGE*, VBOXHDDRAW*, uint64_t)
Error while creating the raw disk VMDK: VERR_ACCESS_DENIED
The raw disk vmdk file was not created
Even making the blockdevice and/or its backing store writable (with the disk still attached to Virtualbox), did not help. The trick is to unregister the disk, eject it from the OS, make it writable and then reattach it to VirtualBox again:
$ diskutil eject disk3
Disk disk3 ejected

$ chmod u+w ../disk3.img
$ hdid -nomount ../disk3.img

$ ls -l /dev/disk3*
brw-r-----  1 christian  staff   14,   9 Nov 28 18:42 /dev/disk3
brw-r-----  1 christian  staff   14,  10 Nov 28 18:42 /dev/disk3s1

$ VBoxManage internalcommands createrawvmdk -filename ../disk3s1.vmdk \
             -rawdisk /dev/disk3 -partitions 1 -register
RAW host disk access VMDK file ../disk3.vmdk created successfully.
To make the disk readonly after all, we can mark it immutable:
$ VBoxManage modifyhd ../disk3.vmdk --type immutable

Cannot unregister the machine 'foo' because it has 1 snapshots

So, I dabbled with this VirtualBox VM a bit but the guest OS was broken anyway so I decided to get rid of the VM:
$ VBoxManage unregistervm foo --delete
ERROR: Cannot unregister the machine 'foo' because it has 1 snapshots
Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component 
            Machine, interface IMachine, callee nsISupports
Context: "UnregisterMachine(uuid, machine.asOutParam())" at line 164 
              of file VBoxManageMisc.cpp
Oh, right. The VM in question had a snapshop attached to it as well, so let's delete it too:
$ VBoxManage showvminfo foo | less
[...]
Snapshots:
   Name: snap1 (UUID: 8e2914fa-de59-4842-9391-3afac42e0125)

$ VBoxManage snapshot foo delete 8e2914fa-de59-4842-9391-3afac42e0125
0%...FAILED
Error: snapshot operation failed. Error message: Hard disk '../deb0.vdi' has 
       more than one child hard disk (2)
Hm, I remember now, the VM was using another VM's disk. Kinda weird setup, no wonder I wanted to get rid of it :-) So let's find out which VM also uses "deb0.vdi":
$ VBoxManage list hdds
[...]
UUID:        03b1afd9-4ce4-4e42-9347-226b55cba657
Parent UUID: base
Format:      VDI
Location:    ../deb0.vdi
State:       created
Type:        normal
Usage:       foo (UUID: 3c57773a-de6a-4714-9149-407a98f85ae7)
          [snap1 (UUID: 8e2914fa-de59-4842-9391-3afac42e0125)]

UUID:        bc3b45a9-db44-41a4-822d-52987f2734c8
Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657
Format:      VDI
Location:    ../foo/Snapshots/{bc3b45a9-db44-41a4-822d-52987f2734c8}.vdi
State:       created
Type:        normal

UUID:        06280b86-8389-40c4-8bfb-3562a3e206df
Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657
Format:      VDI
Location:    ../debian/Snapshots/{06280b86-8389-40c4-8bfb-3562a3e206df}.vdi
State:       created
Type:        normal
Usage:       debian (UUID: bdbf5c46-aefe-4004-acea-ac521eaedb2e)
So, "deb0.vdi" was used by VM foo and debian an also by a snapshot. Maybe I could just edit VirtualBox.xml manually, but that wouldn't be that much fun, right? So let's detach 06280b86-8389-40c4-8bfb-3562a3e206df from debian, then we should be able to delete the snapshot, right?
$ VBoxManage showvminfo debian | grep 06280b86-8389-40c4-8bfb-3562a3e206df
SATA Controller (1, 0): ../debian/Snapshots/{06280b86-8389-40c4-8bfb-3562a3e206df}.vdi
                                      (UUID: 06280b86-8389-40c4-8bfb-3562a3e206df)

$ VBoxManage storageattach debian --storagectl "SATA Controller" \
                                  --port 1 --device 0 --medium none


$ VBoxManage snapshot foo delete 8e2914fa-de59-4842-9391-3afac42e0125
0%...FAILED
Error: snapshot operation failed. Error message: Hard disk '../deb0.vdi' has
       more than one child hard disk (2)
Huh? OK, I say it again: the VM's setup was seriously braindamaged, so maybe VirtualBox got a little confused. A somehow related ticket suggested to revert the snapshot to a current state. Did that and went on to detach the disks from the VM but now things got a bit out of hand:
$ VBoxManage snapshot 3c57773a-de6a-4714-9149-407a98f85ae7 restorecurrent
$ VBoxManage showvminfo foo | grep SCSI

SCSI Controller (0, 0): ../foo/Snapshots/{95000117-e5e0-46dc-bbbd-4929afd9b88c}.vdi 
                                   (UUID: 95000117-e5e0-46dc-bbbd-4929afd9b88c)
SCSI Controller (1, 0): ../foo/Snapshots/{f209322c-b784-4ec3-b0af-e0374444b349}.vdi 
                                   (UUID: f209322c-b784-4ec3-b0af-e0374444b349)

$ VBoxManage storageattach foo --storagectl "SCSI Controller" \
                               --port 0 --device 0 --medium none
$ VBoxManage storageattach foo --storagectl "SCSI Controller" \
                               --port 1 --device 0 --medium none

$ VBoxManage showvminfo foo | grep ^SCSI
SCSI Controller (1, 0): ../foo/Snapshots/{f209322c-b784-4ec3-b0af-e0374444b349}.vdi 
                                   (UUID: f209322c-b784-4ec3-b0af-e0374444b349)
Huh? I just detached the disk from the VM, how comes it's still attached? Shortly after, both disks were attached to the SCSI controller again. This did not look right, so I felt like cheating a bit:
$ pkill VBoxSVC
$ mv ../Machines/foo/Snapshots/* ~/trash/
Meanwhile, I had 4 (!) disks referring to 03b1afd9-4ce4-4e42-9347-226b55cba657 now, I wonder why:
$ VBoxManage list hdds | egrep '^(UUID|Parent)'
[...]
UUID:        03b1afd9-4ce4-4e42-9347-226b55cba657
Parent UUID: base

UUID:        bc3b45a9-db44-41a4-822d-52987f2734c8
Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657

UUID:        06280b86-8389-40c4-8bfb-3562a3e206df
Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657

UUID:        95000117-e5e0-46dc-bbbd-4929afd9b88c
Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657

$ VBoxManage closemedium disk bc3b45a9-db44-41a4-822d-52987f2734c8
$ VBoxManage closemedium disk 06280b86-8389-40c4-8bfb-3562a3e206df
$ VBoxManage closemedium disk 95000117-e5e0-46dc-bbbd-4929afd9b88c
Also, I removed all the storage controllers attached to VM foo:
$ VBoxManage storagectl foo --name "IDE Controller"  --remove
$ VBoxManage storagectl foo --name "SATA Controller" --remove
$ VBoxManage storagectl foo --name "SCSI Controller" --remove
$ VBoxManage storagectl foo --name "SAS Controller"  --remove
This did the trick, apparently:
$ VBoxManage snapshot foo delete 8e2914fa-de59-4842-9391-3afac42e0125
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

$ VBoxManage unregistervm foo --delete
Re-attaching the disks to the other VM, and we're done:
$ VBoxManage storageattach debian --storagectl "SATA Controller" \
                 --port 0 --device 0 --type hdd --medium ../debian/deb0.vdi 
$ VBoxManage storageattach debian --storagectl "SATA Controller" \
                 --port 1 --device 0 --type hdd --medium ../debian/deb1.vdi 

Balsamic vinegar, unleaded please!

Today I came across the following sign while shopping for aceto balsamico:
   CALIFORNIA PROPOSITION 65 WARNING
   The red wine vinegars and balsamic vinegars on these shelves contain lead,
   a chemical known to the state of California to cause birth defects or other
   reproductive harm.
Wait, what? Of course, by now I've searched the tubes and these signs have been there for quite a while. And it's widely discussed too, and people go on raving about these bad vinegars and if there are good vinegars and so on - but I did not find the answer to the question: why? Why would anyone still buy lead-containing vinegar, when it's clearly stated that it's harmful to the (human) body. Well, for Californian bodies, that is. As if lead was not toxic in other states :-)

I don't get it. At all.

Ubuntu 10.10 & btrfs

Ubuntu 10.10 (Maverick) now allows for a btrfs root filesystem. Even before the final relase, performance problems with dpkg have been spotted. The short answer was:
sudo apt-add-repository ppa:brian-rogers/btrfs
sudo apt-get update
sudo apt-get upgrade
And although I've experienced a similar performance impact before, it's somewhat better now, though I'm unsure why: This is still Linux 2.6.35 and dpkg hasn't received any upgrades either since then.
# ls -lgoh ./openoffice.org-core_*.deb
-rw-r--r-- 1 27M Sep 30 08:05./openoffice.org-core_1%3a3.2.1-7ubuntu1_amd64.deb
# echo 3 > /proc/sys/vm/drop_caches
# LC_ALL=C time -p /usr/bin/dpkg -i ./openoffice.org-core_*.deb
real 47.61
user 2.09
sys 7.52

# dpkg -i ./dpkg_1.15.8.4ubuntu3-nosync1_amd64.deb 
# dpkg --force-all -P openoffice.org-core
# echo 3 > /proc/sys/vm/drop_caches 
# LC_ALL=C time -p /usr/bin/dpkg -i ./openoffice.org-core_*.deb
real 31.34
user 2.58
sys 6.50