# Adding and formatting additional disks

**URL:** <https://forum.ansible.com/t/adding-and-formatting-additional-disks/45872>\
**Category:** Get Help\
**Tags:** vmware\
**Created:** [June 2, 2026, 12:15pm UTC](https://forum.ansible.com/t/adding-and-formatting-additional-disks/45872 "2026-06-02T12:15:15Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![nbeernink](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nbeernink/32/9890_2.png) [@nbeernink](https://forum.ansible.com/u/nbeernink)\
**Post date:** [June 2, 2026, 12:15pm UTC](https://forum.ansible.com/t/adding-and-formatting-additional-disks/45872/1 "2026-06-02T12:15:15Z")

</div>

Hi,

I’d like to get some community input on this scenario;

Using `vmware.vmware.deploy_content_library_ovf` you can deploy an imagebuilder image.

Adding an additional disk after the deployment is difficult using `vmware.vmware.vm` compared to `community.vmware.vm_guest_disk` because `vmware.vmware` is quite explicit instead of implicit.

The community module just adds an extra disk, whereas using `vmware.vmware.vm` requires you to figure out the list of disks before adding (and increasing the SCSI bus numbers) to the existing machine.

Does anyone have an example on how to do this while keeping the playbook modular and end up with a working machine?

The additional disk should be formatted using the `redhat.rhel_system_roles.storage` role (or the upstream linux system roles variant)

---

<div class="post-metadata">

**Author:** ![mikemorency](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mikemorency/32/2672_2.png) [@mikemorency](https://forum.ansible.com/u/mikemorency)\
**Post date:** [June 2, 2026, 2:13pm UTC](https://forum.ansible.com/t/adding-and-formatting-additional-disks/45872/2 "2026-06-02T14:13:40Z")

</div>

I dont have a concrete example, but I think using an `_info` module to get the current disks would be the answer. `vmware.vmware.guest_info` doesnt return this information, so maybe an opportunity for an enhancement

---

<div class="post-metadata">

**Author:** ![nbeernink](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nbeernink/32/9890_2.png) [@nbeernink](https://forum.ansible.com/u/nbeernink)\
**Post date:** [June 4, 2026, 1:15pm UTC](https://forum.ansible.com/t/adding-and-formatting-additional-disks/45872/3 "2026-06-04T13:15:23Z")

</div>

Thanks, that was my idea (using `community.vmware.guest_info`) as well but like I said, getting the formatting for SCSI right is critical here.

Will make an RFE later for the guest\_info module to also return disk info (if not already present)

---

<div class="post-metadata">

**Author:** ![mikemorency](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mikemorency/32/2672_2.png) [@mikemorency](https://forum.ansible.com/u/mikemorency)\
**Post date:** [June 4, 2026, 2:23pm UTC](https://forum.ansible.com/t/adding-and-formatting-additional-disks/45872/4 "2026-06-04T14:23:50Z")

</div>

You can actually get this information using the vmware.vmware\_rest repo. I still think something more elegant could be added in the guest\_info module but you could do something like this:

```auto
---
- name: Test
  hosts: localhost
  gather_facts: no
  vars:
    dc: Eco-Datacenter
    vm_name: auto-xjv6-xcopy-template-test-storage-class--cold-y6t8

  tasks:
    - name: Test
      vmware.vmware_rest.vcenter_vm_info:
        vm: "{{ lookup('vmware.vmware.moid_from_path', '/' + dc + '/vm/' + vm_name) }}"
      register: _vm_info

    - name: Debug
      ansible.builtin.debug:
        var: _vm_info.value.disks

    - name: Parse disks
      ansible.builtin.set_fact:
        disks: >-
          {{ disks | default([]) + [
            "SCSI(" + (item.bus | string) + ":" + (item.unit | string) + ")"
          ] }}
      loop: "{{ _vm_info.value.disks.values() | selectattr('type', 'equalto', 'SCSI') | map(attribute='scsi') | list }}"

    - name: Debug
      ansible.builtin.debug:
        var: disks

```

---

<div class="post-metadata">

**Author:** ![nbeernink](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nbeernink/32/9890_2.png) [@nbeernink](https://forum.ansible.com/u/nbeernink)\
**Post date:** [June 4, 2026, 2:43pm UTC](https://forum.ansible.com/t/adding-and-formatting-additional-disks/45872/5 "2026-06-04T14:43:18Z")

</div>

The parse disks example you give is exactly what I would hope to avoid here. It seems so brittle, unnecessary complex to use in a role that I’m wondering if it should just be abstracted away into the module as an additional option similar to how [microsoft.ad.group](https://galaxy.ansible.com/ui/repo/published/microsoft/ad/content/module/group/) can “add”, “remove” or “set” the list of users.

---

<div class="post-metadata">

**Author:** ![mikemorency](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mikemorency/32/2672_2.png) [@mikemorency](https://forum.ansible.com/u/mikemorency)\
**Post date:** [June 4, 2026, 3:11pm UTC](https://forum.ansible.com/t/adding-and-formatting-additional-disks/45872/6 "2026-06-04T15:11:50Z")

</div>

Thats fair; I agree with your feelings about the extra steps in the playbook.

Part of the challenge with the disks (and vm devices in general) is that there needs to be a way to identify the device. For example, if you just provided a list of sizes its unclear what will happen if you remove any items in the list _except_ the last one. Even if you had an option to just “append” the disk to the list, its unclear what the next run of the module would do since theres no identifier. Since VMWare doesnt give or communicate device IDs to the user, the best way to identify which disk your talking about is by specifying the bus and unit number.

The `vm` module does have a `disks_remove_unmanaged` option, which means you dont need to specify all the disks. That would make the parsing in your playbook a little simpler.