Virtual disks should be their own resources

[VoyTechnology]

trafficstars

The resource_vm is responsible for the whole lifetime of a VM. We should detach the responsibility of creating the virtual disk and delegate it to resource_disk, which can be controlled independently of the VM.

[VoyTechnology]

I believe the setup should look similar to how AWS AMI is created: https://www.terraform.io/docs/providers/aws/r/ami.html

[VoyTechnology]

resource "virtualbox_image" "ubuntu" {
  location = "https://app.vagrantup.com/ubuntu/boxes/bionic64/versions/20180903.0.0/providers/virtualbox.box"
  dynamic  = false
  size     = "8GB"
}

resource "virtualbox_disk" "storage" {
  size    = "100GB"
  dynamic = false
}

resource "virtualbox_vm" "node" {
  ...
  disk {
    device_id  = virtualbox_image.ubuntu.id
    mount_path = "/"
  }

  disk {
    device_id  = virtuabox_disk.storage.id
    mount_path = "/var/data"
  }
}

I have no real experience with vagrant box format, and I have always done thing with iso+install, so this might not be 100% accurate, but this is how I would see it working. I am also not sure about disk.device_id, maybe alternative name, or method of getting details about which disk to actually use. What's your opinion @ringods.

[VoyTechnology]

Perhaps the virtualbox_image can only be a data source, since its just getting stuff from remote location.

[ringods]

@VoyTechnology I can follow your thinking of it being a datasource, but the question really is: where is the user manipulating the image: remotely or locally?

I am tempted to say locally and that means it should be a resource. Expressed in the different Terraform callback functions for a resource:

• Exists: Is the image already available as a registered image in your local Virtualbox?
• Create: download the remote image, unpack it and register it locally in Virtualbox
• Read: fetch the actual information of the locally registered image
• Update: not sure whether this is applicable. If one would change the remote URL, I would say this means a Delete (old) + Create (new)
• Delete: unregister the image and cleanup all local files.

I would not model it as the AWS ami resource which creates a new AMI. Creating images is better done with Packer