Abstract: Examples disclosed herein relate to propagating changes made on a file system volume of a primary cluster of nodes to the same file system volume also being managed by a secondary cluster of nodes. An application is executed on both clusters, and data changes on the primary cluster are mirrored to the secondary cluster using an exo-clone file. The exo-clone file includes the differences between two or more snapshots of the volume on the primary cluster, along with identifiers of the change blocks and (optionally) state information thereof. Just these changes, identifiers, and state information are packaged in the exo-clone file and then exported to the secondary cluster, which in turn makes the changes to its version of the volume. Exporting just the changes to the data blocks and the corresponding block identifiers drastically reduces the information needed to be exchanged and processed to keep the two volumes consistent.

Abstract: Examples disclosed herein relate to propagating changes made on a file system volume of a primary cluster of nodes to the same file system volume also being managed by a secondary cluster of nodes. An application is executed on both clusters, and data changes on the primary cluster are mirrored to the secondary cluster using an exo-clone file. The exo-clone file includes the differences between two or more snapshots of the volume on the primary cluster, along with identifiers of the change blocks and (optionally) state information thereof. Just these changes, identifiers, and state information are packaged in the exo-clone file and then exported to the secondary cluster, which in turn makes the changes to its version of the volume. Exporting just the changes to the data blocks and the corresponding block identifiers drastically reduces the information needed to be exchanged and processed to keep the two volumes consistent.

Abstract: Examples disclosed herein relate to propagating changes made on a file system volume of a primary cluster of nodes to the same file system volume also being managed by a secondary cluster of nodes. An application is executed on both clusters, and data changes on the primary cluster are mirrored to the secondary cluster using an exo-clone file. The exo-clone file includes the differences between two or more snapshots of the volume on the primary cluster, along with identifiers of the change blocks and (optionally) state information thereof. Just these changes, identifiers, and state information are packaged in the exo-clone file and then exported to the secondary cluster, which in turn makes the changes to its version of the volume. Exporting just the changes to the data blocks and the corresponding block identifiers drastically reduces the information needed to be exchanged and processed to keep the two volumes consistent.

Abstract: A policy-driven method of migrating a virtual computing resource that is executing an application workload includes the steps of determining that at least one of multiple policies of the application has been violated by the virtual computing resource while executing the workload in a first virtual data center, and responsive to said determining, programmatically performing: (1) searching for a virtual data center to which the virtual computing resource can be migrated, (2) determining that the virtual computing resource will be able to comply with all of the policies of the application while executing the workload if the virtual computing resource is migrated to the second virtual data center, and (3) based on determining the ability to comply, migrating the virtual computing resource across clouds, namely from the first virtual data center to the second virtual data center.

Abstract: A policy-driven method of migrating a virtual computing resource that is executing an application workload includes the steps of determining that at least one of multiple policies of the application has been violated by the virtual computing resource while executing the workload in a first virtual data center, and responsive to said determining, programmatically performing: (1) searching for a virtual data center to which the virtual computing resource can be migrated, (2) determining that the virtual computing resource will be able to comply with all of the policies of the application while executing the workload if the virtual computing resource is migrated to the second virtual data center, and (3) based on determining the ability to comply, migrating the virtual computing resource across clouds, namely from the first virtual data center to the second virtual data center.

Abstract: A method and apparatus in a virtualization system may include using a storage policy that defines a storage characteristic to specify a datastore. The storage policy may be used to identify candidate datastores. A datastore may be selected from the candidates. The datastore can therefore be identified without the user having to identify the datastore directly, but rather indirectly by way of a storage characteristic defined by a storage policy.

Abstract: A method and apparatus in a virtualization system may include using a storage policy that defines a storage characteristic to specify a datastore. The storage policy may be used to identify candidate datastores. A datastore may be selected from the candidates. The datastore can therefore be identified without the user having to identify the datastore directly, but rather indirectly by way of a storage characteristic defined by a storage policy.

Abstract: Examples disclosed herein relate to propagating changes made on a file system volume of a primary cluster of nodes to the same file system volume also being managed by a secondary cluster of nodes. An application is executed on both clusters, and data changes on the primary cluster are mirrored to the secondary cluster using an exo-clone file. The exo-clone file includes the differences between two or more snapshots of the volume on the primary cluster, along with identifiers of the change blocks and (optionally) state information thereof. Just these changes, identifiers, and state information are packaged in the exo-clone file and then exported to the secondary cluster, which in turn makes the changes to its version of the volume. Exporting just the changes to the data blocks and the corresponding block identifiers drastically reduces the information needed to be exchanged and processed to keep the two volumes consistent.