6fe0215c8f
* Add VnicProfileMapping to register VM Add vnic profile mappings to be supported in vm registration * Add VnicProfileMapping to register template Add vnic profile mappings to be supported in template registration * Add reassign bad macs to register VM Add reassign bad macs to be supported in vm registration. * Add additional mappings params for VM registration As part of the effort to support DR with oVirt the "Register" operation is being added with a new mapping parameter that describes the configuration of the registration. The idea of supporting DR site to site in oVirt is to have 2 active setups using storage replication between the primary setup and the secondary setup. Both setups will have active DCs, clusters, and hosts, although those will not be identical. The user can define a mapping which will be used to recover its setup. Each mapping can be used to map any VM's attribute stored in the OVF with its correlated entity. For example, there could be a primary setup with a VM configured on cluster A. We also keep an active secondary setup which only have cluster B. Cluster B is compatible for that VM and in case of a DR scenario theoretically the storage domain can be imported to the secondary setup and the use can register the VM to cluster B. In that case, we can automate the recovery process by defining a cluster mapping, so once the entity will be registered its OVF will indicate it belongs to cluster A but the mapping which will be sent will indicate that cluster B should be valid for every thing that is configured on cluster A. The engine should do the switch, and register the VM to cluster B in the secondary site. Cluster mapping is just one example. The following list describes the different mappings which were introduced: LUN mapping Role mapping Permissions mapping Affinity group mapping Affinity label mapping Each mapping will be used for its specific OVF's data once the register operation will take place in the engine. * Add additional mappings params for Template registration As part of the effort to support DR with oVirt the "Register" operation is being added with a new mapping parameter that describes the configuration of the registration. The idea of supporting DR site to site in oVirt is to have 2 active setups using storage replication between the primary setup and the secondary setup. Both setups will have active DCs, clusters, and hosts, although those will not be identical. The user can define a mapping which will be used to recover its setup. Each mapping can be used to map any Template's attribute stored in the OVF with its correlated entity. For example, there could be a primary setup with a Template configured on cluster A. We also keep an active secondary setup which only have cluster B. Cluster B is compatible for that Template and in case of a DR scenario theoretically the storage domain can be imported to the secondary setup and the use can register the Template to cluster B. In that case, we can automate the recovery process by defining a cluster mapping, so once the entity will be registered its OVF will indicate it belongs to cluster A but the mapping which will be sent will indicate that cluster B should be valid for every thing that is configured on cluster A. The engine should do the switch, and register the Template to cluster B in the secondary site. Cluster mapping is just one example. The following list describes the different mappings which were introduced: Role mapping Permissions mapping Each mapping will be used for its specific OVF's data once the register operation will take place in the engine. * Add support for update OVF store Add support for task of update OVF store in a storage domain. |
||
---|---|---|
.. | ||
ansible |