A question about documentation related to the proxmox_virtual_environment_container resource

[windowsrefund]

Hello,

In the example usage, we see this:

  mount_point {
    # bind mount, *requires* root@pam authentication
    volume = "/mnt/bindmounts/shared"
    path   = "/mnt/shared"
  }

What exactly does that comment mean? Does that mean SSH is used?

Thanks in advance.

[bpg]

Hi @windowsrefund 👋🏼

This config mounts "/mnt/bindmounts/shared" path from the host (PVE) under "/mnt/shared" path in the container. It requires the provider to be authenticated using root system user account (Linux PAM).
You can find more about mount points in the Admin Guide section 11.4.4.

SSH access is not used in container resource.

[windowsrefund]

Thanks for moving this to a discussion.

OK, I figured out what you mean. Based on this provider's documentation related to authentication, we're saying either the PROXMOX_VE_USERNAME environment variable needs to be set to root@pam or the provider block's username attribute needs to be set to the same. Either way, I get it. As I'm using an API Token with appropriate privileges, I'll probably just avoid managing the mounts. Thanks for the feedback as I clearly got confused.

[divStar]

@bpg thank you so much for this plugin! I am using it to set up my homelab.

I am having issues with bind-mounts though. I already (for the sake of getting it to work first) used root@pam along with the password (no SSH) when creating a LXC container, but my plan was to have a ZFS dataset on the host and mount it into the container.
It doesn't work, erroring out like this:

╷
│ Error: error waiting for container created: task "UPID:sanctum:000F4605:01503C69:67F66100:vzcreate:695:root@pam:" failed to complete with exit code: unable to create CT 695 - directory '/storage-pool/lldap-data:0' does not exist
│ 
│   with proxmox_virtual_environment_container.alpine_container,
│   on create_container.tf line 25, in resource "proxmox_virtual_environment_container" "alpine_container":
│   25: resource "proxmox_virtual_environment_container" "alpine_container" {

It works flawlessly with volume mounts, but I thought if I had bind-mounts, I'd be able to see the files from the host and not risk getting the volumes deleted if I un- or redeploy the container.

Here's my configuration:

resource "proxmox_virtual_environment_container" "alpine_container" {
  # Wait for the template to be downloaded before creating the container
  depends_on = [proxmox_virtual_environment_download_file.alpine_template]
...
  unprivileged = true

  # Container initialization settings
  initialization {
    hostname = var.lldap_hostname

    # Network configuration
    ip_config {
      ipv4 {
        address = "${var.lldap_ip}/24"
        gateway = var.lldap_gateway
      }
    }

    # User authentication
    user_account {
      keys = [
        trimspace(tls_private_key.alpine_ssh_key.public_key_openssh)
      ]
      password = random_password.alpine_password.result
    }
  }

  # Network interface
  network_interface {
...
  }

  # Operating system - using Alpine template
  operating_system {
    template_file_id = proxmox_virtual_environment_download_file.alpine_template.id
    type             = "alpine"
  }

...

  # Disk configuration (default)
  disk {
    datastore_id = "images-host"
    size         = 2
  }

  # Mount points for user data persistence
  mount_point {
    volume    = "/storage-pool/lldap-data" # also tried "storage-pool:lldap-data"
    path      = "/data"
    size      = "128M"
    shared    = true
  }

...

  features {
    nesting = true
  }
}

(I redacted all the general settings, that most likely do not play into this issue; here's the link to the full file, though it does not include any bind-mount related things as I did not commit/push them)
The lldap-data ZFS dataset is empty, because it'll be filled during container setup. I tried it when it was owned by root:root as well as 100000:100000, but neither helped. The error is slightly different when using storage-pool:lldap-data - it says, that it's unable to parse the volume.

Here's my repository, that contains most of my Terraform setup: https://github.com/divStar/homelab/ (I avoided uploading a few files).

Do you have an idea why that is?

[bpg]

Hey @divStar 👋🏼

Thanks, I'm glad you found my work useful! ❤️

I think your issue is with the size attribute — you need to remove it for bind mounts.

The PVE API (which the provider relies on here) is a bit of a "Swiss Army knife" in this regard: the same three arguments cover a bunch of completely different use cases. So the decision about the required mount type (either "volume" or "bind") is determined by the presence of the size attribute. As you might guess, size only makes sense for volumes, not for folders (i.e. bind mounts):

  mount_point {
    // bind mount, requires root@pam
    volume = "/mnt/bindmounts/shared"
    path   = "/shared"
  }

  mount_point {
    // volume mount
    volume = "local-lvm"
    size   = "4G"
    path   = "/mnt/local"
  }

[divStar]

Ah - thank you! It works.
It's really a bummer, that I not only have to use root@pam, but I am also not allowed to use an API token (neither as a token, nor as a password), so I'd have to include my root password in a tfvars file or similar and while I could use something to encrypt it, I just don't feel comfortable doing so. I know this is not a restriction imposed by your plugin, but rather by Proxmox (or possibly one of the tools it uses).

Do you happen to know if there is a way to prevent the destruction of a volume mount when the container is destroyed? My sole reason to use bind-mounts is to have them in one place on some volume (e.g. in a ZFS pool / dataset) to know, that it will not be deleted even if for some strange reason the container is undeployed. Of course I'll set up backups and such, but restoring them into bind-mounts is easier than restoring them into those subvol-<vm_id>-disk-<partition_number> directories...

[bpg]

Do you happen to know if there is a way to prevent the destruction of a volume mount when the container is destroyed? My sole reason to use bind-mounts is to have them in one place on some volume (e.g. in a ZFS pool / dataset) to know, that it will not be deleted even if for some strange reason the container is undeployed. Of course I'll set up backups and such, but restoring them into bind-mounts is easier than restoring them into those subvol-<vm_id>-disk-<partition_number> directories...

There is a similar use case for VMs, where we can have one "data VM" that holds the volumes, and a "live VM" that uses them, see details here. You could probably set up something like that for containers, i.e. a "data VM" to own the volume, and a container with a bind mount to this volume.

But in general, PVE does not support "dangling volumes", they must be associated with a resource, so if the resource is deleted, the volume will be deleted as well.

[divStar]

Alright. Thank you! I went for bind-mounts and using root@pam and indeed it works flawlessly using your plugin. Thanks again! Have a relaxing weekend!