Merge branch 'release-4-5-b' into palette-4.5.b-api-docs

Author: karl-cardenas-coding

docs/docs-content/architecture/architecture-overview.md

@@ -87,3 +87,30 @@ be optionally downloaded from a self-hosted private repository instead of pullin
 repository.
 
 ![Self-hosted Palette architecture diagram](/architecture_architecture-on-prem-detailed.webp)
+
+### Message Brokers
+
+Palette requires reliable, scalable, and secure communication. The internal microservices use a Publish-Subscribe
+pattern implemented with [gRPC](https://grpc.io/) to achieve this. In order to support this communication pattern, a
+message broker service acts as the central hub for message exchange. Palette message brokers are automatically scaled,
+ensuring that a quorum is available for each management plane cluster. The broker system is designed to provide the
+following functionality.
+
+1. It efficiently distributes incoming gRPC requests across multiple replicas of the message broker to optimize resource
+   usage and platform performance. This capability supports Palette's ability to manage large enterprise Kubernetes
+   clusters, which are often distributed across numerous Kubernetes clusters.
+2. It provides high availability by enabling clients to fail over to alternative replicas in the case of a pod failure.
+   By default, two replicas of the message broker are created in each management plane cluster.
+3. It automatically adjusts to changes in the number of broker replicas without manual reconfiguration, ensuring that
+   the platform dynamically scales in response to load changes.
+4. It enforces message authentication and security by generating secondary certificates used for broker to broker
+   communication. This provides security in depth.
+
+Any Enterprise and VerteX Palette cluster will have a message broker that you can inspect. First, ensure that you can
+connect to the management plane cluster. Refer to the
+[Access Cluster with CLI](../clusters/cluster-management/palette-webctl.md#access-cluster-with-cli) guide for further
+information. You can then view your message broker by executing the following command.
+
+```bash
+kubectl get statefulset msgbroker --namespace hubble-system
+```

docs/docs-content/automation/palette-cli/commands/vmo.md

@@ -131,7 +131,7 @@ palette vmo import-ova --skip-image
 ### Prerequisites
 
 Refer to
-[Migrate a VM to a VMO cluster](../../../vm-management/create-manage-vm/advanced-topics/migrate-vm-kubevirt.md#prerequisites)
+[Migrate a VM to a VMO cluster using the Palette CLI](../../../vm-management/create-manage-vm/advanced-topics/migrate-vm-kubevirt.md#prerequisites)
 for a full list of prerequisites.
 
 ### Usage
@@ -141,8 +141,8 @@ supported by the `migrate-vm` subcommand. The migration consists of two phases.
 to Persistent Volumes (PVs) in K8s using KubeVirt CDI and VMware Virtual Disk Development Kit (VDDK). Then, the guest OS
 on the root disk is made bootable and drivers are installed using [virt-v2v](https://libguestfs.org/virt-v2v.1.html).
 Refer to the
-[Migrate a VM to a VMO cluster](../../../vm-management/create-manage-vm/advanced-topics/migrate-vm-kubevirt.md) guide
-for further details on migrating a vSphere VM to Palette VMO.
+[Migrate a VM to a VMO cluster using the Palette CLI](../../../vm-management/create-manage-vm/advanced-topics/migrate-vm-kubevirt.md)
+guide for further details on migrating a vSphere VM to Palette VMO.
 
 | **Short Flag** | **Long Flag**        | **Description**                                                                                                                | **Type** |
 | -------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------- |

docs/docs-content/clusters/public-cloud/aws/architecture.md

@@ -76,7 +76,7 @@ Where:
 - Values for **N** and **M** for each instance type can be referred from
   [this document](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI).
 
-## Example Calculation:
+### Example Calculation
 
 - For instance type = t3.medium
 - For values of N = 3, and M = 6 (values derived from AWS
@@ -126,3 +126,46 @@ balancer service. Add the following tags Virtual Private Network (VPC) public su
 - `sigs.k8s.io/cluster-api-provider-aws/role = public`
 - `kubernetes.io/cluster/[yourClusterName] = shared`
 - `sigs.k8s.io/cluster-api-provider-aws/cluster/[yourClusterName] = owned`
+
+## Custom Security Group Ingress Rules
+
+Palette provisions a Virtual Private Network (VPC) for the control plane and worker nodes of AWS IaaS clusters. It then
+also creates multiple security groups, which help manage and secure the resources within the VPC. By default, the API
+Load Balancer security group allows all inbound traffic, specified using an ingress rule with the CIDR range `0.0.0.0/0`
+and port `6443`.
+
+:::warning
+
+Security groups with CIDR range `0.0.0.0/0` will be automatically removed in AWS environments configured with
+[auto remediation](https://docs.aws.amazon.com/config/latest/developerguide/setup-autoremediation.html). The cluster
+will then become inaccessible.
+
+We recommend that you configure custom security group ingress rules to all the cluster profiles that you will be deploy
+to AWS IaaS on secure environments.
+
+:::
+
+You can change the load balancer security group ingress rule by specifying a custom CIDR range in the Kubernetes pack
+**Values** of your cluster profile. This custom ingress rule allows node to node communication within the specified CIDR
+range.
+
+```yaml
+cloud:
+  aws:
+    nodePortCIDRBlocks:
+      - 10.0.0.0/16
+```
+
+Similarly, the bastion node also receives a security group ingress rule of `0.0.0.0/0`. You can specify a custom ingress
+rule for your bastion node to only allow traffic from hosts in the specified IP range.
+
+```yaml
+cloud:
+  aws:
+    bastion:
+      allowedCIDRBlocks:
+        - 10.0.0.0/16
+```
+
+You can change your specified ingress rules by editing your cluster profile at any point, before or after cluster
+deployment.

docs/docs-content/vm-management/create-manage-vm/advanced-topics/advanced-topics.md

@@ -21,5 +21,4 @@ by over-committing CPU and memory.
 - [Create VM Templates](./create-vm-template.md)
 - [Create DISK Templates](./create-disk-templates.md)
 - [Over-commit Resources to Enhance VM Performance](./vm-oversubscription.md)
-- [Migrate a VM to a VMO cluster](./migrate-vm-kubevirt.md)
 - [Import and Deploy OVAs to Palette VMO](./deploy-import-ova.md)

docs/docs-content/vm-management/create-manage-vm/advanced-topics/migrate-vm-kubevirt.md

@@ -1,20 +1,22 @@
 ---
-sidebar_label: "Migrate a VM to a VMO cluster"
-title: "Migrate a VM to a VMO cluster"
-description: "Learn how to migrate VMs to Palette VMO using the Palette CLI."
+sidebar_label: "Migrate a VM to a VMO cluster using the Palette CLI"
+title: "Migrate a VM to a VMO cluster using the Palette CLI"
+description: "Learn how to migrate VMs from VMware vSphere to Palette VMO using the Palette CLI"
 icon: " "
 hide_table_of_contents: false
-sidebar_position: 40
-tags: ["vmo", "palette-cli"]
+sidebar_position: 20
+tags: ["vmo", "palette cli"]
+#toc_max_heading_level: 4
 ---
 
-During large scale Kubernetes adoptions, workloads are often rehosted or migrated instead of being redeployed from
-scratch. This process allows system administrators to copy the application, together with its data, to a Kubernetes
-cluster. However, the migration of VMs can be time consuming if done manually, so it is often automated with open source
-tools such as [Forklift](https://github.com/kubev2v/forklift).
+:::info
 
-The [Palette CLI](../../../automation/palette-cli/palette-cli.md) provides the ability to migrate Virtual Machines (VMs)
-from VMware vSphere to Palette VMO.
+We recommend using the [VM Migration Assistant](../../vm-migration-assistant/vm-migration-assistant.md) instead of this
+method for new migrations.
+
+:::
+
+This migration method uses the [Palette CLI](../../../automation/palette-cli/palette-cli.md).
 
 ## Limitations
 
@@ -68,8 +70,18 @@ from VMware vSphere to Palette VMO.
 
   :::
 
-- A VMware vSphere user account with the necessary permissions to manage the VMs you want to migrate.
-  - Migration can optionally accelerated by providing credentials for the ESXi hosts where the VMs reside.
+- A vCenter user account with the following necessary privileges to perform migrations.
+
+  | **Privileges**                                                                                                                                                                          | **Description**                                                                                                                                                                                         |
+  | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+  | **[Virtual machine.Interaction.Power Off](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-3D47149A-947D-4608-88B3-E5811129EFA8.html)**               | Allows shutting down a powered-on virtual machine, powering down its guest operating system.                                                                                                            |
+  | **[Virtual machine.Interaction.Power On](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-3D47149A-947D-4608-88B3-E5811129EFA8.html)**                | Enables starting a powered-off virtual machine or resuming a suspended one.                                                                                                                             |
+  | [**Virtual Machine Interaction Privileges**](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-3D47149A-947D-4608-88B3-E5811129EFA8.html)              | Allow creating, cloning, modifying, customizing, and managing templates, virtual machines, their files, and customization specifications, as well as performing disk and deployment-related operations. |
+  | **[Virtual machine.Snapshot management.Create snapshot](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-222FE721-0968-4E9E-9F98-7CB03E7185E8.html)** | Allows capturing the current state of a virtual machine as a snapshot.                                                                                                                                  |
+  | **[Virtual machine.Snapshot management.Remove Snapshot](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-222FE721-0968-4E9E-9F98-7CB03E7185E8.html)** | Permits deletion of a snapshot from the snapshot history.                                                                                                                                               |
+
+  - Migrations can be optionally accelerated by providing credentials for the ESXi hosts where the VMs reside.
+
 - One or more VMs hosted in VMware vSphere. Only VMs whose operating systems are included under
   [`virt-v2v` supported guest systems](https://libguestfs.org/virt-v2v-support.1.html) can be migrated.
   - The VMs must be powered off before migration.
@@ -80,13 +92,56 @@ from VMware vSphere to Palette VMO.
   - The Palette CLI must have access to both the VMO cluster and the machines to be migrated.
 - The kubectl command-line tool should also be installed. Refer to the
   [kubectl installation](https://kubernetes.io/docs/tasks/tools/install-kubectl/) guide to learn more.
-- We recommend providing a VMware Virtual Disk Development Kit (VDDK) image for the migration. This will significantly
-  speed up the migration.
+- We recommend providing a
+  [VMware Virtual Disk Development Kit (VDDK) image](https://developer.broadcom.com/sdks/vmware-virtual-disk-development-kit-vddk/latest)
+  for the migration. This will significantly speed up the migration. The migration engine uses VDDK on the destination
+  VMO cluster to read virtual disks from the source environment, transfer the data, and write it to the target storage.
+
+  - You must build and host the VDDK image in your own image registry, which must be accessible to the destination VMO
+    cluster for migrations.
+
+    <!--prettier-ignore-->
+    <details>
+    <summary> Example steps to build and upload VDDK image </summary>
+
+    1. Download the VDDK image from the
+       [Broadcom Developer Portal](https://developer.broadcom.com/sdks/vmware-virtual-disk-development-kit-vddk/latest).
+
+    2. Decompress the downloaded image.
+
+       ```shell
+       tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz
+       ```
+
+    3. Create a Dockerfile to build the VDDK image.
+
+       ```shell
+       cat > Dockerfile <<EOF
+       FROM <myregistry/myrepository:tag>
+       USER 1001
+       COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib
+       RUN mkdir -p /opt
+       ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"]
+       EOF
+       ```
+
+       Replace the `<myregistry/myrepository:tag>` with your chosen base image registry/repository (for example:
+       `alpine:latest`).
+
+    4. Build the image.
+
+       ```shell
+       docker buildx build --platform linux/amd64 --tag <docker-registry>/vddk:<tag> .
+       ```
+
+    5. Push the built image to your image registry.
+
+       ```shell
+       docker push <docker-registry>/vddk:<tag>
+       ```
+
+    </details>
 
-  - The VDDK image must be built and uploaded to your image registry before starting the migration. Refer to the
-    [Creating a VDDK image](https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/2.6/html/installing_and_using_the_migration_toolkit_for_virtualization/prerequisites_mtv#creating-vddk-image_mtv)
-    documentation for guidance.
-  - The migration host must have access to your image registry.
   - If you are using a private image registry, you must create a Secret to be used for the migration. The Secret must be
     in the form of a YAML file and the `metadata.name` value must be `vddk-image-pull-secret`. The `metadata.namespace`
     value should be left blank or omitted, as the Palette CLI will automatically populate it.
@@ -103,6 +158,7 @@ from VMware vSphere to Palette VMO.
     --docker-username=myUsername \
     --docker-password=myPassword \
     --docker-email=myEmail \
+    --kubeconfig=/path/to/myKubeconfig \
     --output yaml > image-pull-secret.yaml
     ```
 
@@ -134,8 +190,10 @@ from VMware vSphere to Palette VMO.
     `vddk-image-pull-secret`, and the `metadata.namespace` is left blank or omitted.
 
     Refer to the
-    [Pull an Image from a Private Registry documentation](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/)
-    for additional guidance.
+    [Pull an Image from a Private Registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/)
+    and
+    [kubectl create secret docker-registry](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_create/kubectl_create_secret_docker-registry/)
+    documentation for additional guidance.
 
     </details>
 
@@ -154,7 +212,7 @@ from VMware vSphere to Palette VMO.
    namespace.
 
    ```shell
-   kubectl create namespaces <migration-namespace>
+   kubectl create namespace <migration-namespace>
    ```
 
 4. Execute the following command to start an interactive shell and begin the migration process to the cluster specified
@@ -183,6 +241,7 @@ from VMware vSphere to Palette VMO.
    | **Migration Name**                                                 | The name of your migration and its corresponding configuration files. A default name is generated by the Palette CLI.                                                                                                     |                                              |
    | **Forklift Installation Type**                                     | A cluster to be used for performing the migration. You can either choose to create a local cluster or use the destination cluster. [Forklift](https://github.com/kubev2v/forklift) is installed on the migration cluster. | `Local Kind Cluster` / `Destination Cluster` |
    | **Install Forklift?**                                              | Specify whether to install Forklift on the migration cluster.                                                                                                                                                             | `Y` / `n`                                    |
+   | **KUBECONFIG path**                                                | The local filesystem path to the kubeconfig for your destination cluster. For example, `~/path/to/mycluster.kubeconfig`.                                                                                                  |                                              |
    | **Migration Namespace**                                            | Namespace where the migration VM is created. The namespace must exist on the cluster. You can enter the namespace you created earlier or use the `default` namespace.                                                     |                                              |
    | **vSphere Endpoint**                                               | Your vSphere endpoint. You can specify a Full Qualified Domain Name (FQDN) or an IP address. Make sure you specify the endpoint without the HTTP scheme `https://` or `http://`. For example, `vcenter.mycompany.com`.    |                                              |
    | **vSphere Username (with domain)**                                 | Your vSphere account username.                                                                                                                                                                                            |                                              |
@@ -220,7 +279,7 @@ from VMware vSphere to Palette VMO.
 
 ## Validate
 
-1. Log into [Palette](https://console.spectrocloud.com).
+1. Log in to [Palette](https://console.spectrocloud.com).
 
 2. From the left **Main Menu**, select **Clusters**. Then, choose the VMO cluster that you migrated your VM to. The
    **Overview** tab appears.

docs/docs-content/vm-management/create-manage-vm/clone-vm.md

@@ -23,6 +23,28 @@ clone a VM for the following reasons:
 
 - An active cluster in Palette with the Virtual Machine Orchestrator (VMO) pack.
 
+  :::warning
+
+  Ensure that the **Snapshot** feature gate is enabled in the Virtual Machine Orchestrator (VMO) pack. This is enabled
+  by default, but may be modified during cluster profile creation and editing. This feature gate allows Palette to
+  access the KubeVirt resources required for correctly cloning your VMs and their data volumes. Learn more about the
+  KubeVirt clone capabilities on the [Clone API](https://kubevirt.io/user-guide/storage/clone_api/#clone-api) page in
+  the official project documentation.
+
+  Select the VMO pack in your cluster profile. Then, click on **Values** under the **Pack Details** section. Verify that
+  `Snapshot` is present in the `charts.virtual-machine-orchestrator.kubevirt.kubevirtResources.additionalFeatureGates`
+  field.
+
+  ```yaml hideClipboard {5}
+  kubevirtResource:
+    name: kubevirt
+    useEmulation: false
+    additionalFeatureGates:
+      - Snapshot
+  ```
+
+  :::
+
 - Outbound internet connectivity for port 443 is allowed so that you and your applications can connect with the Spectro
   Cloud reverse proxy.
 

docs/docs-content/vm-management/create-manage-vm/migrate-vm-to-different-node.md

@@ -1,5 +1,5 @@
 ---
-sidebar_label: "Migrate a VM"
+sidebar_label: "Migrate a VM to a Different Node"
 title: "Migrate a VM to a Different Node"
 description: "Learn how to migrate a VM to another physical host in the cluster using Palette."
 hide_table_of_contents: false