topic sk183754 MANA in Cloud Firewall

sk183754 MANA

LazarusG — Thu, 28 May 2026 15:01:47 GMT

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

Re: sk183754 MANA

Duane_Toler — Fri, 29 May 2026 00:12:53 GMT

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.

Re: sk183754 MANA

LazarusG — Fri, 29 May 2026 08:16:29 GMT

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?

Re: sk183754 MANA

LazarusG — Fri, 29 May 2026 08:20:38 GMT

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

Re: sk183754 MANA

LazarusG — Fri, 29 May 2026 11:17:46 GMT

thanks for the screnshot though - most helpful

Re: sk183754 MANA

avivs — Fri, 29 May 2026 15:47:21 GMT

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.

Re: sk183754 MANA

Cristobal_Valle — Fri, 29 May 2026 17:51:22 GMT

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

Re: sk183754 MANA

Duane_Toler — Sat, 06 Jun 2026 20:37:44 GMT

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.

Re: sk183754 MANA

Duane_Toler — Sat, 06 Jun 2026 20:56:07 GMT

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.