Turnkey LAMP (turnkey-lamp-2009.10-hardy-x86) fails startup - "msg.disk.permission.write:You do not have write access"

Trying to start up turnkey-lamp-2009.10-hardy-x86 on VMWare Server (hosted on XPSP2 x64) and VMWare Player osted on XPSP3 32 bit) fails with multiple -

msg.disk.permission.write:You do not have write access to a partition.
Select Allow to override access rights for this write.
Select Allow all to override access rights for this and subsequent writes to all raw disk partitions during this run of the virtual machine.
Select Deny to refuse this write.
Select Deny all to refuse this and subsequent writes to all safe raw disk partitions which do not have write access during this run of the virtual machine.

Selecting Allow All pushes through but still gets BUffer I/O errors on sda1 and appliance only partially installs.

Redownloading the .zip file makes no difference.

Help?

Replies (5)

I used the VMDK file.

Reply 1 2009-10-25

I just ADDed a virtual machine to my VMWare Server installation by pointing to the VMDK files. That's less hoops.

Thanks

Reply 2 2009-10-26

This is helpful information. I'm going to investigate what's going on in-depth and update the VM images as soon as it's fixed. You shouldn't have to jump through these hoops to work with our VM build.

Importing via OVFTOOLS corrects the problem

Reply 3 2009-10-26

Using the OVFTools to 'convert' the files results in an usable virtual machine.

Try importing OVF

Reply 4 2009-10-25

Guys thanks for reporting this. You may have found a bug in the conversion to the virtual appliance format. We're using VMWare's OVF conversion tool and I suspect it may set permission flags on the VMDK file it builds.

Did you try importing the virtual appliance from OVF (I.e., rather than trying to run it directly as a VMX)

Should be fixed now

Reply 5 2009-10-28

I found what the problem was, fixed it and have uploaded new VM images for all appliances. Try again.

In case anyone is interested, here's what happened. We didn't realize it when we packaged the VM builds but for some reason VMWare's OVF tool insists on creating a "compressed" VMDK that can only be accessed read-only. According to VMWare documentation this is the intended behavior. Presumably admins are expected to use ovftool to convert an OVF VMDK back into a format that is usable by VMWare.

That's very inconvenient so I digged deeper. VMWare's documentation states that OVF's disk format is not directly usable, but the OVF documentation says that the disk format is unspecified.

Long story short I resolved this by repackaging the VM's HD image into a monolithic sparse file and referencing it from the OVF. According to my testing with VMWare Server and VirtualBox this gives you the best of all worlds. VMWare can use it directly, VirtualBox can import it as an OVF, and VMWare's OVF tool can still convert it into other formats.

An added benefit is that we get better compression ratios this way so the VM images are more lightweight.

Cheers