- ► What happens if I reconfigure a virtual machine which was previously autoconfigured using a rule?
- If you reconfigure an individual virtual machine created in a vCenter folder that already has a configuration rule applied to it, it is added to the exclusion list of the rule.
- ► What happens if the tag for a virtual machine changes after it is configured?
- The VM will be reconfigured if the new tag has a rule applied to it and the storage region is the same.
- ► What if a virtual machines has disks in multiple datastores and I have applied auto configuration rule at the datastore level?
- The VMs which have VMX configuration files in that specific datastore are eligible for auto configuration.
- ► What happens if the object on which rule is applied no longer exists or is moved/deleted?
- If the object is moved or deleted, the auto configuration rule is considered invalid.
- ► How do the exclusion patterns work?
Exclusion patterns let you provide strings that can be a part of the name of the virtual machine. The rule does not auto configure a virtual machine with a name matching that pattern. Patterns that you can provide to exclude virtual machines from getting auto-configuration rule applied:
- If you enter Test_VM, Phoenix excludes the virtual machine that has the string Test_VM as its name.
- If you enter Test*, Phoenix excludes all virtual machines that have names beginning with the string Test.
- If you enter *Test*, Phoenix excludes all virtual machines that have names with the string Test in the beginning, middle, or end.
- If you enter *Test, Phoenix excludes all virtual machines that have names ending with the string Test.
- ► What happens if I update a rule and apply it to a different folder?
- All the virtual machines created under the folder with a rule applied are listed under the Configured VMs section.
If you select a new folder when you update your rule,
- All the virtual machines created under the previous folder and the current folder are listed under Configured VMs section.
- Consider a scenario where you create a rule (rule1) and apply it to a folder (folder1) under the vCenter hierarchy. Folder1 contains VM1, VM2, and VM3. After some time, you edit rule1 and select folder2 that contains virtual machines VM-A, VM-B, and VM-C. When you select the rule, under Configured VMs you can see VM1, VM2, VM3, VM-A, VM-B, and VM-C.
If you create a new rule, for example, rule2, and apply it to folder1:
- If the Exclude already configured VMs setting is disabled for rule2, virtual machines VM1, VM2, and VM3 are reconfigured based on rule 2 provided their storage region is same.
- If the Exclude already configured VMs setting is enabled, VMs VM1, VM2, and VM3 remain configured through rule1.
- ► What happens if I remove all the backup proxies from a backup proxy pool, and a rule uses the backup proxy pool?
- Phoenix does not alert or mark your rule as invalid if all backup proxies from one pool are moved to another, and your rule uses the empty backup proxy pool. When your rule, that uses an empty backup proxy pool, tries to automatically configure a virtual machine for backup, it is configured. However, when Phoenix tries to back up your virtual machine, the backup job fails because there is no proxy to back it up.
- ► My folder in vCenter datastore contains virtual machines and folders under it. The folders under it contain more virtual machines. What happens if I apply a rule to the parent folder in the datastore?
In step 7 of the Create an auto-configuration rule procedure, you can see a folder hierarchy. If you apply rule1 to VM_Folder1, and you do not create and apply any rule to VM_Folder1-A, rule1 auto-configures VMs under VM_Folder1 and VM_Folder1-A. If you create a rule2 later and apply it to VM_Folder1-A:
- If the Exclude already configured VMs setting is enabled for rule2, rule2 does not auto configure VMs under VM_Folder1-A since the VMs are already configured from rule1.
- If the Exclude already configured VMs setting is disabled for rule2, rule2 auto-configures VMs under VM_Folder1-A.
- ► My folder in vCenter datastore contains virtual machines and folders under it. The folders under it contain more virtual machines. What happens if I create two rules, and apply the first rule to the parent folder, and the second rule to a child folder?
- In step 7 of the Create an auto-configuration rule procedure, you can see a folder hierarchy. If you apply rule1 to VM_Folder1 and rule2 to VM_Folder1-A:
- rule2 auto-configures eligible VMs under VM_Folder1-A
- rule1 auto-configures eligible VMs under VM_Folder1
- rule2 gets a priority over rule1. Phoenix does not let rule1 auto configure rule2 eligible VMs under VM_Folder1-A
- If VM_Folder1-A contains a virtual machine (for example VM1), and a virtual machine that is powered off (for example VM2):
If rule2 is created to exclude VMs that are powered off (Powered Off setting is checked) and contains the exclusion pattern VM1, rule2 does not auto configure virtual machines VM1 and VM2.
- If rule1 is created without any exclusion patterns and can include powered off virtual machines (Powered Off setting is unchecked), rule1 auto-configures VM1 and VM2.
- ► I want to reconfigure virtual machines using rules, but the rule uses a different storage than the storage which the virtual machines are already using. What happens if I create and use this rule?
- If you try to reconfigure your virtual machines using rules, reconfiguration fails if the storage specified in the rule is different. For example, you add virtual machines VM1 and VM2 under folder VMFD1 in a vCenter setup. You attach VM1 and VM2 to the storage US-West. Later, you create an auto-configuration rule R1 for folder VMFD1 in which you specify storage as US-East. In the rule R1, you disable Exclude already configured VMs ensuring auto-configuration of all virtual machines in the folder when the rule is applied.
When the rule R1 to folder VMFD1 is applied:
- VM1 and VM2 remain attached to the US-West storage since the reconfiguration fails due to the different storage.
- You do not see an error message as in manual reconfiguration.