OS-8386: vmware vmdk number of blocks is wrong

Details

Issue Type:Bug
Priority:Medium
Status:Resolved
Created at:2022-05-19T00:55:24.051Z
Updated at:2022-05-20T19:37:18.182Z

People

Created by:Brian Bennett
Reported by:Brian Bennett
Assigned to:Brian Bennett

Fix Versions

2022-06-02 Slick Henry (Release Date: 2022-06-02)

Related Links

Description

The SmartOS.vmdk file has the wrong number of blocks, leading vmware fusion 11 and 12 to report that it can’t find the disk. The produced disk size hasn’t changed since at least 20191107, and the SmartOS.vmdk file has never changed since it was committed in 2014.

It’s possible that this used to work on older versions of fusion, if it was less strict about the block size. I can’t imagine that this never worked. Fusion 11 was released near macOS Sierra in 2016. Fusion 10 didn’t support Mojave (2018), so this as been broken at least that long.

Comments

Comment by Brian Bennett
Created at 2022-05-19T01:10:09.366Z
Updated at 2022-05-19T17:07:20.090Z

The fix appears to be setting the block size to the calculation used in sdc-headnode to produce those images.

[https://github.com/TritonDataCenter/sdc-headnode/blob/master/vmware/make_vmdk#L63-L69|https://github.com/TritonDataCenter/sdc-headnode/blob/master/vmware/make_vmdk#L63-L69|smart-link]

#
# Using the raw image size, determine the size (in 512 byte blocks) to use
# in the VMDK extent record, and the number of cylinders to use in the
# IDE configuration.
#
(( g_image_blocks = g_image_bytes / 512 ))
(( g_image_cylinders = g_image_blocks / (16 * 63) ))

With the image being 1940000256, that gives us 3789063 blocks.

Setting the blocks to this value in the vmdk file lets the vm boot in Fusion.


Comment by Brian Bennett
Created at 2022-05-19T20:56:38.626Z

Copying this in from github:

It looks like what was originally done was assumed the img file was 2000000000.

I created a script to help out here. This is based on the make_vmdk script in sdc-headnode.

#!/bin/bash

g_image_bytes="${1:-516096}"

(( g_image_blocks = g_image_bytes / 512 ))
(( g_image_cylinders = g_image_blocks / (16 * 63) ))

printf 'Size is  : %d\n' "$g_image_bytes"
printf 'Blocks   : %d\n' "$g_image_blocks"
printf 'Cylinders: %d\n' "$g_image_cylinders"

Starting with 2000000000, this gives us the values that are currently in the vmdk file:

> ./sizecalc 2000000000
Size is  : 2000000000
Blocks   : 3906250
Cylinders: 3875

Using the actual size of the image, we get this instead:

> ./sizecalc 1940000256
Size is  : 1940000256
Blocks   : 3789063
Cylinders: 3758

So it looks like 3875 isn't a typo, it just started with a different value. But it does also mean that I should fix that value in the PR.


Comment by Brian Bennett
Created at 2022-05-19T21:00:50.647Z

Looking back, originally the vmware image bundled the ISO, but smartos-live#367 changed it to a disk image. The vmware image produced along with that commit was 2000000000, so it was correct for the time. Sometime in the intervening eight years something changed the size of the image.


Comment by Brian Bennett
Created at 2022-05-19T21:16:42.943Z

This changed in 20200520T174734Z.

SmartOS-20200506T235114Z.vmwarevm:
total 211076
-rw-r--r-- 1 root root 2000000000 May  7  2020  smartos.img
-rw-r--r-- 1 root root       8704 May  7  2020  SmartOS.nvram
-rw-r--r-- 1 root root        326 May  7  2020  SmartOS.vmdk
-rw-r--r-- 1 root root          0 May  7  2020  SmartOS.vmsd
-rwxr-xr-x 1 root root       2202 May  7  2020  SmartOS.vmx*
-rw-r--r-- 1 root root    2686976 May  7  2020 'Virtual Disk.vmdk'

SmartOS-20200520T174734Z.vmwarevm:
total 210996
-rw-r--r-- 1 root root 1940000256 May 20  2020  smartos.img
-rw-r--r-- 1 root root       8704 May 20  2020  SmartOS.nvram
-rw-r--r-- 1 root root        326 May 20  2020  SmartOS.vmdk
-rw-r--r-- 1 root root          0 May 20  2020  SmartOS.vmsd
-rwxr-xr-x 1 root root       2202 May 20  2020  SmartOS.vmx*
-rw-r--r-- 1 root root    2686976 May 20  2020 'Virtual Disk.vmdk'

And, found it. [https://mnx.atlassian.net/browse/OS-8170|https://mnx.atlassian.net/browse/OS-8170|smart-link].