sk183754 MANA

[LazarusG]

Hi,

Simple query - if you manually edit the VM overview page and add the LegacyVMNVA tag and then stop/start - is that sufficient to scope the opt-out to that vm.

Thanks

[Duane_Toler · Accepted solution]

That's what the compliance/remediation policy is doing, except the policy is filtered for a select list of marketplace publishers.  The resulting tag has no value on it, either.  Here's what it looks like on a VM after the policy remediation ran. 

If you deploy it as a compliance policy, it can automate the remediation as well.  This is the result.

[LazarusG]

cool yeh - so in a really simple environment - where someone might not have permissions to run the policy in their org - you could just manually poke it in there and restart the vm right?

[LazarusG]

also we have customers having errors trying to apply the label - and also customers asking how to remove the label.

[avivs · Accepted solution]

We should look at this in two scenarios:

1. VM currently on Mellanox

• Applying the LegacyVMNVA tag is sufficient to protect future allocations
• No immediate action is required
• The tag is evaluated only during lifecycle events (stop/start, redeploy, scale-out), so it mainly matters for future changes

2. VM currently on MANA

• The tag alone is not enough to move the VM off MANA
• A lifecycle event is required (stop/start, redeploy, or VMSS instance replacement) to trigger reallocation and enforce the tag

---

As these mechanisms are all Microsoft owned, operated and documented, In any case of errors applying the azure policy or opt-out tag, kindly contact Microsoft Azure support.

[LazarusG]

thanks for the screnshot though - most helpful

[Cristobal_Valle]

Hello

About VMSS,   Must we Stop/Start the VMSS group or it is enough apply this by each vm in the scale-set group?

Regards

[Duane_Toler]

Applying the compliance and auto-remediation policy to the resource group will ensure the VMs get the tag.  You can do a scale out event to test the results and verify, however.

[Duane_Toler]

For those interested, here's an Ansible playbook to add the MANA driver to the modprobe deny-list.  This assumes you have an Ansible inventory group for your CloudGuard management and CloudGuard gateway hosts.  You also need a user that can login via SSH directly into Expert mode.  This playbook does not use Gaia API.

---
# disable_mana.yml
# Add the Microsoft MANA driver to modprobe deny-list
# sk183754
#
- name: Disable Microsoft MANA driver
  hosts: ckp_mgmt_azure,ckp_gw_azure  # Inventory group of Azure hosts
  gather_facts: false
  become: false
  remote_user: YOUR_EXPERT_MODE_USER

  vars:
    output_dir: /tmp/disable_microsoft_mana # Change to your own output path

  tasks:
    - name: Create output directories
      ansible.builtin.file:
        path: "{{ item }}"
        state: directory
        recurse: true
      loop:
        - "{{ output_dir }}/{{ inventory_hostname }}/BEFORE"
        - "{{ output_dir }}/{{ inventory_hostname }}/AFTER"
      delegate_to: localhost

    # ITSM Change Control BEFORE state
    - block:
        - name: Get current modprobe config
          ansible.builtin.fetch:
            src: /etc/modprobe.d/disable_mana.conf
            dest: "{{ output_dir }}/{{ inventory_hostname }}/BEFORE/disable_mana.conf"
            flat: true
          register: fetch_result
      rescue:
        - name: modprobe config absent
          ansible.builtin.copy:
            content: "disable_mana.conf does not exist"
            dest: "{{ output_dir }}/{{ inventory_hostname }}/BEFORE/disable_mana.conf.txt"
          delegate_to: localhost

    - name: Add MANA to modprobe config
      ansible.builtin.copy:
        content: "blacklist mana\n"
        dest: /etc/modprobe.d/disable_mana.conf
        owner: root
        group: root
        mode: '0644'

    # ITSM Change Control AFTER state
    - block:
        - name: Get current modprobe config
          ansible.builtin.fetch:
            src: /etc/modprobe.d/disable_mana.conf
            dest: "{{ output_dir }}/{{ inventory_hostname }}/AFTER/disable_mana.conf"
            flat: true
      rescue:
        - name: modprobe config absent
          ansible.builtin.copy:
            content: "disable_mana.conf does not exist"
            dest: "{{ output_dir }}/{{ inventory_hostname }}/AFTER/disable_mana.conf.txt"
          delegate_to: localhost

...

Your inventory would look like this:

---
# inventory.yml
all:
  children:
    ckp_mgmt_azure:
      hosts:
        mgmt01:
          ansible_host: 192.0.2.1
    ckp_gw_azure:
      hosts:
        gw01:
          ansible_host: 192.0.2.2
        gw02:
          ansible_host: 192.0.2.3
...

Run the playbook:

ansible-playbook -i inventory.yml disable_mana.yml -k  # "-k" asks for the expert-level user password

The playbook will capture the BEFORE/AFTER state of the configuration for your ITSM/Change Control management.  There is no TEST plan, however, since this is just modifying the file.  This doesn't automatically reboot the host.  If you want to do that, you can add a ansible.builtin.reboot module task at the end.