# Ansible vmware deploy linux vm - adapter not connected

**URL:** <https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560>\
**Category:** Get Help\
**Tags:** vmware, playbook, awx, ee\
**Created:** [October 29, 2024, 8:37am UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560 "2024-10-29T08:37:18Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![alainseys](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/alainseys/32/2757_2.png) [@alainseys](https://forum.ansible.com/u/alainseys)\
**Post date:** [October 29, 2024, 8:37am UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/1 "2024-10-29T08:37:18Z")

</div>

Hello i have an issue with ansible i am using awx to execute playbook using  
the execution environment: [Quay](http://quay.io/ansible/awx-ee:24.5.0) the vm is create but network is not connected i need to go in to VMware click the connected button.

 ![image](https://us1.discourse-cdn.com/ansible/original/2X/8/870a0c1e8cd00621a3fd97a67701900ae609debd.png)

And then everything works i tried adding connected: true and start\_connected: true but that seems not to do anything.

I have checked i have open-vm-tools running in the template that is cloned. (This does also report on the deployed vm as Running).

```auto
- name: Clone the template
  community.vmware.vmware_guest:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: false
      cluster: "{{ vcenter_vm_cluster }}"
      folder: "{{ vcenter_vm_folder }}"
      datacenter: "{{ vcenter_datacenter }}"
      datastore: "{{ vcenter_datastore }}"
      name: "{{ vm_name | upper }}"
      state: powered-on
      template: "{{ vm_template }}"
      wait_for_ip_address: false
      annotation: "{{ comments | default ('Deployed by ansible') }} Buisness Contact: {{ email_b_contact }}"
      networks:
        - name: "{{ network_name }}"
          ip: "{{ network_ip.msg }}"
          netmask: "{{ network_netmask }}"
          gateway: "{{ network_gateway }}"
          device_type: "{{ vm_device_type }}"
          type: static
      hardware:
        memory_mb: "{{ memory_mb|int * 1024 }}"
        num_cpus: "{{ num_cpus }}"
        hotadd_cpu: false
        hotadd_memory: false
      customization:
        domain: "{{ vm_domain }}"
        dns_servers: "{{ dns_servers.split(',') }}"
      guest_id: "{{ guest_id }}"
  register: deploy_vm

```

Could this be relevant to the execution environment ?

---

<div class="post-metadata">

**Author:** ![anon81884396](https://avatars.discourse-cdn.com/v4/letter/a/b782af/32.png) [@anon81884396](https://forum.ansible.com/u/anon81884396)\
**Post date:** [October 29, 2024, 12:26pm UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/2 "2024-10-29T12:26:46Z")

</div>

Per [https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware\_guest\_module.html#parameter-networks](https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_guest_module.html#parameter-networks) it looks like you’d need to add `connected: true` and/or `start_connected: true` within the list item of each NIC under networks, ie:

```auto
- name: Clone the template
  community.vmware.vmware_guest:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: false
      cluster: "{{ vcenter_vm_cluster }}"
      folder: "{{ vcenter_vm_folder }}"
      datacenter: "{{ vcenter_datacenter }}"
      datastore: "{{ vcenter_datastore }}"
      name: "{{ vm_name | upper }}"
      state: powered-on
      template: "{{ vm_template }}"
      wait_for_ip_address: false
      annotation: "{{ comments | default ('Deployed by ansible') }} Buisness Contact: {{ email_b_contact }}"
      networks:
        - name: "{{ network_name }}"
          ip: "{{ network_ip.msg }}"
          netmask: "{{ network_netmask }}"
          gateway: "{{ network_gateway }}"
          device_type: "{{ vm_device_type }}"
          type: static
          connected: true
          start_connected: true
      hardware:
        memory_mb: "{{ memory_mb|int * 1024 }}"
        num_cpus: "{{ num_cpus }}"
        hotadd_cpu: false
        hotadd_memory: false
      customization:
        domain: "{{ vm_domain }}"
        dns_servers: "{{ dns_servers.split(',') }}"
      guest_id: "{{ guest_id }}"
  register: deploy_vm

```

I’m unclear by your original post since you mention you’ve tried adding “connected: true” but don’t specify where you added it, and neither option appear within your paste.

---

<div class="post-metadata">

**Author:** ![alainseys](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/alainseys/32/2757_2.png) [@alainseys](https://forum.ansible.com/u/alainseys)\
**Post date:** [October 29, 2024, 2:10pm UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/3 "2024-10-29T14:10:26Z")

</div>

> [@anon81884396](#):
>
> u

Hello,

i have pasted connected:true and start\_connected: true the same way you have done. But this did not solve my issue.

Let me test this out again

---

<div class="post-metadata">

**Author:** ![anon81884396](https://avatars.discourse-cdn.com/v4/letter/a/b782af/32.png) [@anon81884396](https://forum.ansible.com/u/anon81884396)\
**Post date:** [October 29, 2024, 2:27pm UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/5 "2024-10-29T14:27:43Z")

</div>

You may also want to take a look at this thread: [vmware\_guest - after cloning nic is not connected to network · Issue #45834 · ansible/ansible · GitHub](https://github.com/ansible/ansible/issues/45834) seems similar to what you’re experiencing

---

<div class="post-metadata">

**Author:** ![alainseys](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/alainseys/32/2757_2.png) [@alainseys](https://forum.ansible.com/u/alainseys)\
**Post date:** [October 30, 2024, 12:53pm UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/6 "2024-10-30T12:53:47Z")

</div>

Simular but no fix , i fixed it by adding a python script after deployment to connect the interface based on {{ network\_name }} that connects the interface.

Not the cleanest solution but works for now

---

<div class="post-metadata">

**Author:** ![Walter\_Rowe](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/walter_rowe/32/4506_2.png) [@Walter\_Rowe](https://forum.ansible.com/u/Walter_Rowe)\
**Post date:** [November 1, 2024, 11:32am UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/7 "2024-11-01T11:32:09Z")

</div>

We add a second task specifically to ensure the network is connected.

We use DHCP on our server VLANs. We use permanent leases in our DNS service. Once the machine is created we send over the mac address to the DNS service. That service creates the DHCP record.

The machine powers up and waits for a response from DHCP which then configures its network, gateway, netmask, etc.

```yaml
##
## create a VM from template, powered off state, then add disks and tags
##
- name: create the guest vm using template
  community.vmware.vmware_guest:
    validate_certs: no
    hostname: "{{ vcenter[location|lower].vc }}"
    datacenter: "{{ vcenter[location|lower].dc }}"
    cluster: "{{ vcenter[location|lower].cl }}"
    name: "{{ vm_guest_name | lower }}"
    state: poweredoff
    template: "{{ os_type }}"
    folder: "{{ esx_folder }}"
    datastore: "{{ vcenter[location|lower].ds }}"
    advanced_settings:
      - key: "disk.EnableUUID"
        value: "true"
    hardware:
      hotadd_cpu: yes
      hotadd_memory: yes
      memory_mb: "{{ vm_spec[vm_size].ram }}"
      num_cpus: "{{ vm_spec[vm_size].cpu }}"
    networks:
      - name: "VLAN_{{ vlan }}"
        type: dhcp
        start_connected: yes
        connected: yes
    wait_for_ip_address: no
  delegate_to: localhost
  register: newvm

##
## ensure the network connects on startup
##
- name: set the vm network to connect at startup
  community.vmware.vmware_guest_network:
    validate_certs: no
    hostname: "{{ vcenter[location|lower].vc }}"
    datacenter: "{{ vcenter[location|lower].dc }}"
    cluster: "{{ vcenter[location|lower].cl }}"
    name: "{{ vm_guest_name | lower }}"
    mac_address: "{{ newvm.instance.hw_eth0.macaddress }}"
    network_name: "VLAN_{{ vlan }}"
    start_connected: yes
    connected: yes

```

---

<div class="post-metadata">

**Author:** ![alainseys](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/alainseys/32/2757_2.png) [@alainseys](https://forum.ansible.com/u/alainseys)\
**Post date:** [November 3, 2024, 2:30pm UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/8 "2024-11-03T14:30:34Z")

</div>

Hy walter i will give this method a try see what result i will get

---

<div class="post-metadata">

**Author:** ![alainseys](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/alainseys/32/2757_2.png) [@alainseys](https://forum.ansible.com/u/alainseys)\
**Post date:** [November 3, 2024, 4:05pm UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/9 "2024-11-03T16:05:07Z")

</div>

@Walter_Rowe tested your approuch and this is indeed a more cleaner solution i only added a additional step to boot the vm when network configuration is executed.

nice work

---

<div class="post-metadata">

**Author:** ![Walter\_Rowe](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/walter_rowe/32/4506_2.png) [@Walter\_Rowe](https://forum.ansible.com/u/Walter_Rowe)\
**Post date:** [November 4, 2024, 12:36pm UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/10 "2024-11-04T12:36:48Z")

</div>

Glad that helped. I should have added that there are more tasks in our esx-create-vm.yml playbook that do things with tagging and adding storage. At the end we do power on the machine.

We have a vars file that provides server specifications. You can see refs to vm\_spec[vm\_size].ram and .cpu … we get vm\_size from our ServiceNow request form and use it as a dictionary key. We model the keys after Amazon machine sizes so we can use the same key across VMware and AWS.

```yaml
vm_spec:
  t2_micro: { cpu: 1, ram: 1024 }
  t2_small: { cpu: 1, ram: 2048 }
  t2_medium: { cpu: 2, ram: 4096 }
  t2_large: { cpu: 2, ram: 8192 }
  r5_large: { cpu: 2, ram: 16384 }
  t2_xlarge: { cpu: 4, ram: 16384 }
  m4_xlarge: { cpu: 4, ram: 16384 }
  t2_2xlarge: { cpu: 8, ram: 32768 }
  m4_2xlarge: { cpu: 8, ram: 32768 }
  r5a_large: { cpu: 2, ram: 16384 }
  r5a_xlarge: { cpu: 4, ram: 32768 }
  r5a_2xlarge: { cpu: 8, ram: 65536 }
  r6i_large: { cpu: 2, ram: 16384 }
  r6i_xlarge: { cpu: 4, ram: 32768 }
  r6i_2xlarge: { cpu: 8, ram: 65536 }

```

We employ a similar method for server types - MSSQL server, nginx server, etc, where we provide disks. For that we use a list of JSON records and json\_query to filter for the server type.

```yaml
fs_spec: [

  # linux apache web server servers
  { profile: apache , name: system , device: a, size: 75, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 0, unit: 0, owner: root, group: root, perms: 0755 }, # /
  { profile: apache , name: sites , device: b, size: 32, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 1, unit: 0, owner: root, group: root, perms: 0755 }, # /sites

  # linux commvault media servers
  { profile: commvault , name: system , device: a, size: 75, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 0, unit: 0, owner: root, group: root, perms: 0755 }, # /
  { profile: commvault , name: ddb , device: b, size: 512, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 1, unit: 0, owner: root, group: root, perms: 0755 }, # /ddb
  { profile: commvault , name: index , device: c, size: 512, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 1, unit: 1, owner: root, group: root, perms: 0755 }, # /index

  # linux docker container servers
  { profile: docker , name: system , device: a, size: 75, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 0, unit: 0, owner: root, group: root, perms: 0755 }, # /
  { profile: docker , name: containers , device: b, size: 100, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 1, unit: 0, owner: root, group: root, perms: 0755 }, # /containers

  # linux general purpose servers
  { profile: general , name: system , device: a, size: 75, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 0, unit: 0, owner: root, group: root, perms: 0755 }, # /

  # linux MySQL database servers
  { profile: mysql , name: system , device: a, size: 75, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 0, unit: 0, owner: root, group: root, perms: 0755 }, # /
  { profile: mysql , name: tmp , device: b, size: 64, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 0, unit: 1, owner: root, group: root, perms: 1777 }, # /tmp
  { profile: mysql , name: apps , device: c, size: 128, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 1, unit: 0, owner: oranist, group: dba, perms: 0755 }, # /apps
  { profile: mysql , name: archive , device: d, size: 192, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 1, unit: 1, owner: oranist, group: dba, perms: 0755 }, # /archive
  { profile: mysql , name: mydata , device: e, size: 208, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 2, unit: 0, owner: mysql, group: dba, perms: 0755 }, # /mydata
  { profile: mysql , name: mybackups , device: f, size: 224, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 2, unit: 1, owner: mysql, group: dba, perms: 0755 }, # /mybackups

  # linux nginx web server servers
  { profile: nginx , name: system , device: a, size: 75, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 0, unit: 0, owner: root, group: root, perms: 0755 }, # /
  { profile: nginx , name: sites , device: b, size: 32, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: paravirtual, ctrl: 1, unit: 0, owner: root, group: root, perms: 0755 } # /sites
]

fs_spec_windows: [

  # Windows commvault media servers
  { profile: commvault , disk_number: 0 , name: system , device: c, size: 100, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 0, unit: 0, block: 4096 }, # OS/Sys
  { profile: commvault , disk_number: 1 , name: Index , device: e, size: 100, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 1, unit: 0, block: 4096 }, # Index
  { profile: commvault , disk_number: 2 , name: DDB , device: f, size: 100, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 2, unit: 0, block: 4096 }, # DDB

  # Windows general purpose servers
  { profile: general , disk_number: 0 , name: system , device: c, size: 100, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 0, unit: 0, block: 4096 }, # OS/Sys
  { profile: general , disk_number: 1 , name: Data1 , device: e, size: 100, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 1, unit: 0, block: 4096 }, # Data1

  # Windows IIS web servers
  { profile: iis , disk_number: 0 , name: system , device: c, size: 100, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 0, unit: 0, block: 4096 }, # OS/Sys
  { profile: iis , disk_number: 1 , name: Data1 , device: e, size: 300, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 1, unit: 0, block: 4096 }, # Data1

  # Windows MS SQL servers
  { profile: mssql , disk_number: 0 , name: system , device: c, size: 100, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 0, unit: 0, block: 4096 }, # OS/Sys
  { profile: mssql , disk_number: 1 , name: Data1 , device: e, size: 500, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: 250, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 0, unit: 1, block: 65536 }, # Data1
  { profile: mssql , disk_number: 2 , name: Data2 , device: f, size: 500, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: 250, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 0, unit: 2, block: 65536 }, # Data2
  { profile: mssql , disk_number: 3 , name: Backup , device: g, size: 800, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: 250, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 1, unit: 0, block: 4096 }, # Backup
  { profile: mssql , disk_number: 4 , name: Index , device: i, size: 5, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 1, unit: 1, block: 65536 }, # Index
  { profile: mssql , disk_number: 5 , name: Log , device: l, size: 200, type: { esx: thin, aws: { ebs_vol_type: io2 , throughput: default, iops: 500 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 2, unit: 0, block: 65536 }, # Log
  { profile: mssql , disk_number: 6 , name: SQL , device: p, size: 75, type: { esx: thin, aws: { ebs_vol_type: gp3, throughput: default, iops: 3000 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 2, unit: 1, block: 4096 }, # SQL Program
  { profile: mssql , disk_number: 7 , name: TempDB , device: t, size: 50, type: { esx: thin, aws: { ebs_vol_type: io2, throughput: default, iops: 500 }, azr: azr_default, gcp: gcp_default }, ctrl_type: lsilogicsas, ctrl: 3, unit: 0, block: 65536 }, # TempDB
]

```

In our ESX server creation playbook we query these lists for the specific server type. Note how the `type_list` value chooses the proper Windows or Linux list to query. We set “my\_family” higher in the playbook based on info we get from our form in ServiceNow.

```yaml
##
## build required disk lists based on fs_type (excludes system disk provided by ESX template)
##
- name: Initialize disk lists
  set_fact:
    type_list: "{{ (fs_spec if my_family != 'windows' else fs_spec_windows) | json_query('[?profile==`'+fs_type+'` && name!=`system`]') }}"
    disk_list: []

- name: Build vmware_guest_disk list from filesystem list
  set_fact:
    disk_list: "{{ disk_list + this_list }}"
  loop: "{{ type_list }}"
  vars:
    this_list: [{ size_gb: "{{ item.size }}", type: "{{ item['type'][location[0:3]] }}", datastore: "{{ vcenter[location|lower].ds }}", scsi_type: "{{ item.ctrl_type }}", scsi_controller: "{{ item.ctrl }}", unit_number: "{{ item.unit }}" } ]

##
## attach additional disks (if any) to template just provisioned
##
- name: Add disk(s) to {{ vm_guest_name | lower }}
  community.vmware.vmware_guest_disk:
    datacenter: "{{ vcenter[location|lower].dc }}"
    hostname: "{{ vcenter[location|lower].vc }}"
    name: "{{ vm_guest_name | lower }}"
    validate_certs: no
    disk: "{{ disk_list }}"
# disk: "{{ snow_disks }}"
  when: (disk_list|length) > 0

```

As you can see we filter the fs\_spec or fs\_spec\_windows (fs = filesystem) lists based on `fs_type` and build a VMware formatted disk specification so we can add the storage needed based on file system (server purpose) type.

We chose to be very detailed in our disk specifications to provide predictability about which volume is assigned to which disk. This was forward thinking that hopefully enables automation of requests to increase volume sizes as needed.

All of this happens before the machine is powered on the first time so that the OS will do its initial probe on first boot and find all the disks needed by that type of system. They all start with the same vanilla machine template based on OS. A later playbook in our workflow does all the “customization” to make it into the type the user selected in the ServiceNow form. This includes formatting volumes and setting their mount points, installing the needed packages, making system resource settings, installing configuration files, updating host-based firewall, etc.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\
**Post date:** [December 4, 2024, 12:37pm UTC](https://forum.ansible.com/t/ansible-vmware-deploy-linux-vm-adapter-not-connected/10560/11 "2024-12-04T12:37:21Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.