windows_2016_docker.json produces 0 byte vmdk #87

asbjornu · 2018-03-01T21:00:13Z

I'm trying to get Octopus Deploy run in Docker (version 18.03.0-ce-rc1, build c160c73) on my macOS 10.12.6. I've installed VirtualBox (version 5.2.8r121009), downloaded the Windows 2016 ISO and seemingly successfully executed the following command:

packer build --only=virtualbox-iso -var 'iso_url=/Users/bitbear/Downloads/14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FRE_EN-US.ISO' windows_2016_docker.json

After a few hours, this command finishes with the following:

Build 'virtualbox-iso' finished.

==> Builds finished. The artifacts of successful builds are:
--> virtualbox-iso: 'virtualbox' provider box: windows_2016_docker_virtualbox.box

However, when I execute the following command, a .box file is created with a WindowsServer2016Docker-disk001.vmdk file in it that is 0 bytes in size:

vagrant box add windows_2016_docker windows_2016_docker_virtualbox.box

After copying vagrantfile-windows_2016.template to Vagrantfile and modifying it according to work with my setup, vagrant up fails with the following:

There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "/Users/bitbear/.vagrant.d/boxes/windows_2016_docker/0/virtualbox/box.ovf", "--vsys", "0", "--vmname", "WindowsServer2016Docker_1519934437898_19158", "--vsys", "0", "--unit", "8", "--disk", "/Users/bitbear/VirtualBox VMs/WindowsServer2016Docker_1519934437898_19158/WindowsServer2016Docker-disk001.vmdk"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting /Users/bitbear/.vagrant.d/boxes/windows_2016_docker/0/virtualbox/box.ovf...
OK.
0%...
Progress state: VBOX_E_FILE_ERROR
VBoxManage: error: Appliance import failed
VBoxManage: error: Could not open the medium storage unit '/Users/bitbear/.vagrant.d/boxes/windows_2016_docker/0/virtualbox/WindowsServer2016Docker-disk001.vmdk'.
VBoxManage: error: VMDK: error reading the magic number in '/Users/bitbear/.vagrant.d/boxes/windows_2016_docker/0/virtualbox/WindowsServer2016Docker-disk001.vmdk' (VERR_EOF).
VBoxManage: error: VD: error VERR_VD_VMDK_INVALID_HEADER opening image file '/Users/bitbear/.vagrant.d/boxes/windows_2016_docker/0/virtualbox/WindowsServer2016Docker-disk001.vmdk' (VERR_VD_VMDK_INVALID_HEADER)
VBoxManage: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component ApplianceWrap, interface IAppliance
VBoxManage: error: Context: "RTEXITCODE handleImportAppliance(HandlerArg *)" at line 886 of file VBoxManageAppliance.cpp

When I inspect the file /Users/bitbear/.vagrant.d/boxes/windows_2016_docker/0/virtualbox/WindowsServer2016Docker-disk001.vmdk, it is indeed an empty file of 0 bytes in size. Any ideas what might be causing this and how I can fix it?

The text was updated successfully, but these errors were encountered:

StefanScherer · 2018-03-02T06:03:38Z

Which version of Packer do you use?
My latest builds are done with Packer 1.1.3.
Which size is the box file? It should be about 10 GByte.

basictheprogram · 2018-03-02T19:36:09Z

Do you have enough free disk space to hold the 10 GByte file?

asbjornu · 2018-03-02T22:01:36Z

I'm using version 1.2.1 of Packer and I have 160 GB of free disk space. The .box is 10.89 GB. Opening the .box in an archive browser, I can see a WindowsServer2016Docker-disk001.vmdk file in there at 0 bytes in size.

StefanScherer · 2018-03-03T09:19:01Z

The box size looks good. Can you list the content of the box file?
It should look like this:

$ .\tar.exe tvf .\windows_2016_docker_virtualbox.box
-rw-rw-rw-  0 0      0        2347 Jan 23 01:43 Vagrantfile
-rw-rw-rw-  0 0      0 10767669248 Jan 23 01:43 WindowsServer2016Docker-disk001.vmdk
-rw-rw-rw-  0 0      0       10416 Jan 23 01:43 box.ovf
-rw-rw-rw-  0 0      0          26 Jan 23 01:43 metadata.json

asbjornu · 2018-03-03T21:07:44Z

$ tar tvf windows_2016_docker_virtualbox.box
-rw-r--r--  0 bitbear staff    2286 Mar  1 20:50 Vagrantfile
-rw-r--r--  0 bitbear staff       0 Mar  1 20:50 WindowsServer2016Docker-disk001.vmdk
-rw-r--r--  0 bitbear staff   10412 Mar  1 20:50 box.ovf
-rw-r--r--  0 bitbear staff      26 Mar  1 20:50 metadata.json

StefanScherer · 2018-03-04T16:13:28Z

Well, I don't know where the error during the packer build happened to produce this corrupt box file.
I would suggest to just rebuild the box and see if it works. You could also use the StefanScherer/windows_2016_docker box from Vagrant cloud.

asbjornu · 2018-03-04T16:34:06Z

I’ve rebuilt the box four times due to other hints I’ve found around the web of what the problem might be. Nothing has helped, which is why I ended up asking here.

I’ll definitely try your box from Vagrant cloud, thanks!

basictheprogram · 2018-03-04T21:02:23Z

Can duplicate.

macOS 10.13.3
$ packer --version
1.2.1

$ vboxmanage --version
5.2.8r121009

$ ls -lh *.box
-rw-r--r--  1 tanner  staff    10G Mar  4 03:30 windows_2016_docker_virtualbox.box

The .box is 10G in size

$ tar -tvf windows_2016_docker_virtualbox.box
-rw-r--r--  0 tanner staff    2286 Mar  4 03:25 Vagrantfile
-rw-r--r--  0 tanner staff       0 Mar  4 03:25 WindowsServer2016Docker-disk001.vmdk

-rw-r--r--  0 tanner staff   10412 Mar  4 03:25 box.ovf
-rw-r--r--  0 tanner staff      26 Mar  4 03:25 metadata.json

But the .vmdk is zero?

Where is the 10G of disk space coming from?

$ tar -xvzf ../windows_2016_docker_virtualbox.box
x Vagrantfile
x WindowsServer2016Docker-disk001.vmdk: Attempt to write to an empty file
x box.ovf
x metadata.json
tar: Error exit delayed from previous errors.

$ ls -alh
total 40
drwxr-xr-x   6 tanner  staff   204B Mar  4 15:02 .
drwxr-xr-x  72 tanner  staff   2.4K Mar  4 15:00 ..
-rw-r--r--   1 tanner  staff   2.2K Mar  4 03:25 Vagrantfile
-rw-r--r--   1 tanner  staff     0B Mar  4 03:25 WindowsServer2016Docker-disk001.vmdk
-rw-r--r--   1 tanner  staff    10K Mar  4 03:25 box.ovf
-rw-r--r--   1 tanner  staff    26B Mar  4 03:25 metadata.json

Maybe this?

https://en.wikipedia.org/wiki/Hierarchical_File_System
Max. file size | 2 GB (2 × 10243 bytes)

Is your filesystem hfs?

Because all my Mac's are upgrades from previous versions of macOS or OSX they are hfs.

This week I'll head to the lab and convert hfs to apfs. Needs to be doing via safe mode.

asbjornu · 2018-03-04T21:19:05Z

Yes, I'm using HFS+ since I have a Fusion drive. I'm waiting for Fusion support in APFS before I convert.

basictheprogram · 2018-03-04T21:23:42Z

HFS+ has Max. file size | 8 exabyte

asbjornu · 2018-03-04T22:21:10Z

@StefanScherer: Your Vagrant cloud box booted just fine. Thank you! Now I just need to figure out how to use it as a DOCKER_HOST for just one of many Docker images I want to boot with docker-compose. I've searched but found no way to declare one image's DOCKER_HOST in docker-compose, do you know if this is possible, or do I need to run all images in the same host?

StefanScherer · 2018-03-05T06:41:09Z

Interesting, so HFS+ does not have a problem with the box file size and extracting the contents.
So it seems a problem while creating the tar file.
You can run Packer with debug output

export PACKER_LOG=1
packer build ...

To see which command is called during the box file creation.
I don't know if it's a built-in command in the packer binary or if some external tools from macOS are called.

basictheprogram · 2018-03-05T19:36:04Z

Not seeing anything obvious in the logs.

typescript.txt

Going to do a packer with "keep_input_artifact": true

basictheprogram · 2018-03-06T06:33:11Z

"keep_input_artifact": true
HFS+ filesystem
Packer Logs

output-virtualbox-iso/

$ ls -l
total 21220296
-rw-r--r--  1 tanner  staff  10864777216 Mar  5 18:46 WindowsServer2016Docker-disk001.vmdk
-rwx------  1 tanner  staff        10412 Mar  5 18:23 WindowsServer2016Docker.ovf

$ ls -l *.box
-rw-r--r--  1 tanner  staff  10729788371 Mar  5 18:56 windows_2016_docker_virtualbox.box

$ tar -tvf windows_2016_docker_virtualbox.box
-rw-r--r--  0 tanner staff    2286 Mar  5 18:51 Vagrantfile
-rw-r--r--  0 tanner staff       0 Mar  5 18:51 WindowsServer2016Docker-disk001.vmdk
-rw-r--r--  0 tanner staff   10412 Mar  5 18:51 box.ovf
-rw-r--r--  0 tanner staff      26 Mar  5 18:51 metadata.json

StefanScherer · 2018-03-06T06:50:37Z

Thanks. This really looks like a problem inside packer

2018/03/05 18:51:25 packer: 2018/03/05 18:51:25 Turning dir into box: /var/folders/5m/b4xyt3kj2sx8sbrksf0c6q0w0000gn/T/packer821802642 => windows_2016_docker_virtualbox.box
2018/03/05 18:51:25 packer: 2018/03/05 18:51:25 Compressing with gzip compression level: -1
2018/03/05 18:51:26 packer: 2018/03/05 18:51:26 Skipping directory '/var/folders/5m/b4xyt3kj2sx8sbrksf0c6q0w0000gn/T/packer821802642' for box 'windows_2016_docker_virtualbox.box'
2018/03/05 18:51:26 packer: 2018/03/05 18:51:26 Box add: '/var/folders/5m/b4xyt3kj2sx8sbrksf0c6q0w0000gn/T/packer821802642/Vagrantfile' to 'windows_2016_docker_virtualbox.box'
2018/03/05 18:51:26 ui: �[0;32m    virtualbox-iso (vagrant): Compressing: Vagrantfile�[0m
�[0;32m    virtualbox-iso (vagrant): Compressing: Vagrantfile�[0m
2018/03/05 18:51:26 packer: 2018/03/05 18:51:26 Box add: '/var/folders/5m/b4xyt3kj2sx8sbrksf0c6q0w0000gn/T/packer821802642/WindowsServer2016Docker-disk001.vmdk' to 'windows_2016_docker_virtualbox.box'
2018/03/05 18:51:26 ui: �[0;32m    virtualbox-iso (vagrant): Compressing: WindowsServer2016Docker-disk001.vmdk�[0m
�[0;32m    virtualbox-iso (vagrant): Compressing: WindowsServer2016Docker-disk001.vmdk�[0m
�[0;32m    virtualbox-iso (vagrant): Compressing: box.ovf�[0m
�[0;32m    virtualbox-iso (vagrant): Compressing: metadata.json�[0m
2018/03/05 18:56:09 packer: 2018/03/05 18:56:09 Box add: '/var/folders/5m/b4xyt3kj2sx8sbrksf0c6q0w0000gn/T/packer821802642/box.ovf' to 'windows_2016_docker_virtualbox.box'
2018/03/05 18:56:09 ui: �[0;32m    virtualbox-iso (vagrant): Compressing: box.ovf�[0m
2018/03/05 18:56:09 packer: 2018/03/05 18:56:09 Box add: '/var/folders/5m/b4xyt3kj2sx8sbrksf0c6q0w0000gn/T/packer821802642/metadata.json' to 'windows_2016_docker_virtualbox.box'
2018/03/05 18:56:09 ui: �[0;32m    virtualbox-iso (vagrant): Compressing: metadata.json�[0m
2018/03/05 18:56:09 [INFO] (telemetry) ending vagrant

The tar file is created internally: https://github.com/hashicorp/packer/blob/4d3a762e85e7e8050134a4e33e1f87a54029dcb8/post-processor/vagrant/util.go#L71-L155
but this function has no recent changes.

basictheprogram · 2018-03-06T16:13:38Z

Can duplicate this problem with macOS sierra (10.12.6) and HFS+ filesystem.

Time to open a bug in the packer project?

Or maybe an issue in golang?

StefanScherer · 2018-03-06T20:27:48Z

There's one config option compression_level which can be set to 0 to turn off compression. Don't know if that makes a difference.

Issue with Golang or one of the imported packages?, maybe.
Maybe create a small golang program from the DirToBox function, removing the ui parameter and run it with some big files.

An issue in packer project may help to get some feedback. But I haven't seen a similar issue there yet, so probably most people work with much smaller vmdk sizes.

StefanScherer · 2018-03-07T06:55:18Z

@asbjornu With docker-compose you only can start containers on one Docker host. If you want to mix Linux and Windows workloads you need eg. Docker Swarm running a Linux and Windows node and then you can use a docker-compose.yml to deploy a stack.

With later Windows Server like 1709, 1803, ... and latest nightly Docker builds you may use LCOW to start Linux containers directly on the Windows Docker host. But this works only with HyperV enabled in the VM, but VirtualBox does not have nested virtualization feature to do that.

asbjornu · 2018-03-07T19:29:11Z

@StefanScherer: Thanks. As I write in docker/compose#3987 (comment) I finally figured this out as well. I hoped to not have to start from scratch with Docker Swarm, since I've never used it before and really enjoy the simplicity of Docker Compose. I might as well just go with Kubernetes then, since I know that better than Docker Swarm, but it too adds infinite amounts of complexity I don't really want to deal with in this very simple demo project.

With later Windows Server like 1709, 1803, ... and latest nightly Docker builds you may use LCOW to start Linux containers directly on the Windows Docker host. But this works only with HyperV enabled in the VM, but VirtualBox does not have nested virtualization feature to do that.

Yeah, I considered that but VirtualBox makes that impossible. So I don't really know what to do. I think I might just manually run Octopus Deploy within a Windows VM and skip Docker for this purpose altogether.

StefanScherer · 2018-03-11T13:37:45Z

The workaround for now: Use Packer 1.1.3

I just rebuilt a VirtualBox box file (brew switch packer 1.1.3) and everything looks fine:

$ tar tvf windows_2016_docker_virtualbox.box 
-rw-r--r--  0 501    20        2286 Mar 11 14:27 Vagrantfile
-rw-r--r--  0 501    20 10952051712 Mar 11 14:27 WindowsServer2016Docker-disk001.vmdk
-rw-r--r--  0 501    20       10412 Mar 11 14:27 box.ovf
-rw-r--r--  0 501    20          26 Mar 11 14:27 metadata.json
~/code/packer-windows on my*
$ ls -l *box
-rw-r--r--  1 stefan  staff  10817278351 Mar 11 14:28 windows_2016_docker_virtualbox.box

StefanScherer · 2018-03-29T17:36:39Z

Created golang/go#24599 for further investigation.

basictheprogram · 2018-03-29T18:40:45Z

Everything from brew works for me now. Just adding the below for work around(?) until the golang people find the fix.

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.3
BuildVersion:	17D102

$ packer --version
1.2.2

$ go version
go version go1.10 darwin/amd64

StefanScherer · 2018-03-29T18:49:51Z

@basictheprogram Your fix/workaround includes using the homebrew GNU tar and replacing the embedded tar in Vagrant?

basictheprogram · 2018-03-29T19:11:42Z

@StefanScherer Nope. I think something changed in packer 1.2.2 from homebrew.

StefanScherer · 2018-03-29T20:58:19Z

Weird. But as long as it works for you.
It will be officially fixed with Packer 1.2.3, PR hashicorp/packer#6084 got merged.
So using Packer 1.1.3 or 1.2.3 fixes the problem.

basictheprogram mentioned this issue Mar 7, 2018

packer produces 0 byte vmdk hashicorp/packer#5990

Closed

StefanScherer closed this as completed Mar 29, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

windows_2016_docker.json produces 0 byte vmdk #87

windows_2016_docker.json produces 0 byte vmdk #87

asbjornu commented Mar 1, 2018

StefanScherer commented Mar 2, 2018

basictheprogram commented Mar 2, 2018

asbjornu commented Mar 2, 2018 •

edited

Loading

StefanScherer commented Mar 3, 2018

asbjornu commented Mar 3, 2018

StefanScherer commented Mar 4, 2018

asbjornu commented Mar 4, 2018

basictheprogram commented Mar 4, 2018 •

edited

Loading

asbjornu commented Mar 4, 2018

basictheprogram commented Mar 4, 2018

asbjornu commented Mar 4, 2018 •

edited

Loading

StefanScherer commented Mar 5, 2018

basictheprogram commented Mar 5, 2018 •

edited

Loading

basictheprogram commented Mar 6, 2018

StefanScherer commented Mar 6, 2018

basictheprogram commented Mar 6, 2018 •

edited

Loading

StefanScherer commented Mar 6, 2018

StefanScherer commented Mar 7, 2018

asbjornu commented Mar 7, 2018

StefanScherer commented Mar 11, 2018

StefanScherer commented Mar 29, 2018

basictheprogram commented Mar 29, 2018

StefanScherer commented Mar 29, 2018 •

edited

Loading

basictheprogram commented Mar 29, 2018

StefanScherer commented Mar 29, 2018

windows_2016_docker.json produces 0 byte vmdk #87

windows_2016_docker.json produces 0 byte vmdk #87

Comments

asbjornu commented Mar 1, 2018

StefanScherer commented Mar 2, 2018

basictheprogram commented Mar 2, 2018

asbjornu commented Mar 2, 2018 • edited Loading

StefanScherer commented Mar 3, 2018

asbjornu commented Mar 3, 2018

StefanScherer commented Mar 4, 2018

asbjornu commented Mar 4, 2018

basictheprogram commented Mar 4, 2018 • edited Loading

asbjornu commented Mar 4, 2018

basictheprogram commented Mar 4, 2018

asbjornu commented Mar 4, 2018 • edited Loading

StefanScherer commented Mar 5, 2018

basictheprogram commented Mar 5, 2018 • edited Loading

basictheprogram commented Mar 6, 2018

StefanScherer commented Mar 6, 2018

basictheprogram commented Mar 6, 2018 • edited Loading

StefanScherer commented Mar 6, 2018

StefanScherer commented Mar 7, 2018

asbjornu commented Mar 7, 2018

StefanScherer commented Mar 11, 2018

StefanScherer commented Mar 29, 2018

basictheprogram commented Mar 29, 2018

StefanScherer commented Mar 29, 2018 • edited Loading

basictheprogram commented Mar 29, 2018

StefanScherer commented Mar 29, 2018

asbjornu commented Mar 2, 2018 •

edited

Loading

basictheprogram commented Mar 4, 2018 •

edited

Loading

asbjornu commented Mar 4, 2018 •

edited

Loading

basictheprogram commented Mar 5, 2018 •

edited

Loading

basictheprogram commented Mar 6, 2018 •

edited

Loading

StefanScherer commented Mar 29, 2018 •

edited

Loading