Creating a VPX Amazon Machine Image (AMI) in SC2S 编辑

Contributors

Author: Jill Fetscher, Architect

SC2S is an air-gapped AWS instantiation with no access to an AWS Marketplace. All Amazon Machine Images (AMI) must be manually uploaded into the environment using the vmimport tool. Due to the nature of the Citrix ADC VPX appliance, the image file is too large to use the vmimport tool. The VPX AMI must be created so that it is bootable for future use. We created the following method specifically for SC2S, but it can be used for future use cases of this nature, where no Marketplace exists, or no VPX AMI offering is available in the Marketplace.

Create a VPX in SC2S: Steps on the low side (commercial AWS)

1. Create a VPC and subnet in UC2S (commercial) using the same CIDR block as the VPC where the Citrix ADC resides in SC2S. (for example, create a VPC of 10.0.0.0/16 size, with a single public subnet of size 10.0.0.0/24 using the VPC Wizard.)

   This can be done one of two ways:

   • Create a testing VPC in SC2S with the basic CIDR and subnetting
   • Copy the CIDR and subnetting that is used in SC2S

   Note:

   For C2S, VPC creation is done through a service and automatically allocated an IP space from the supernet. In this case, the second method is necessary. For GovCloud, wait for further instruction, or download the latest version of VPX from the Marketplace.

   

   

   

2. Deploy an EC2 instance from the Citrix ADC AMI in AWS Marketplace. The instance is required to be Customer Licensed. Use a non-nitro-based instance (for example, m4.xlarge).

   

   

   Choose the VPC you created in the previous steps. Disable Auto-assign Public IP.

   Name the instance with an easily recognizable name. We create many instances in the following steps and it is necessary to identify each instance for further configuration.

   The security group auto-populates. Click Next through the rest of the steps for instance launch.

   

3. Create a Windows Server 2019 or 2016 Base bastion host to reach your VPX instance.

   This instance can be an m4.xlarge, and must be built in the same VPC and AZ as the Citrix ADC, with an auto-assigned Public IP. The root volume requires a minimum of 45 GiB, General Purpose SSD (gp2).

   Note:

   If the environment allows creation of Elastic IPs (EIP), you can skip the creation of the bastion host, and the VPX instance can be connected to directly from the network or internet. We recommend the use of a bastion host for security purposes and the lack of EIP availability in air-gapped environments.

   

   Name the instance something recognizable (for example, SC2S: WS2016 Bastion Low).

   

   For simplicity, create a security group to allow All Traffic. You can lock down this security group later.

   

   Once the instance is ready, RDP in to the machine using the public IP. Then download PuTTY and WinSCP, and copy over the keypair that was used to create the VPX instance. This requires the conversion of the .pem to a .ppk, using PuTTYgen. In Server Manager, disable Windows Firewall and Internet Explorer Enhanced Security. Using PuTTY, verify that you are able to SSH into the newly deployed Citrix ADC appliance. Note the nsroot password for the instance. By default, this is the AWS InstanceID. Make a note of the private IP of the instance, as it is needed in a later step. At this stage, you have a working Citrix ADC appliance.

   Note:

   Do not configure this VPX! Simply log in as nsroot to verify functionality.

4. Power off the Citrix ADC instance from the AWS console. Detach the root EBS volume from the Citrix ADC instance.

   

   To detach the root volume, click the root device /dev/sda1, and then click the volume ID. In the Volume tab, select the volume, name it something recognizable (for example, SC2S: Commercial Root Vol), and note the volume ID. Click Actions > Detach Volume > OK. The volume state should now be Available.

   

5. Deploy a new Amazon Linux EC2 instance (Amazon Linux 2 AMI (HVM), SSD Volume Type, 64-bit, EBS-backed, ENA-enabled). This instance should be the same instance type as the previously deployed VPX instance (for example m4.xlarge), and should be in the same VPC and subnet, with the “Auto-assign Public IP” setting disabled. Name the instance something recognizable (for example SC2S: Linux Low). Set the Security Group to allow all traffic for now. Once the instance launches, power it off.

   

6. Attach the detached root EBS volume from the VPX to the Linux EC2 instance.

   

   Choose the Linux instance you created by clicking Instance > Attach.

   

7. Create a volume with a higher capacity than the root VPX volume. The root volume capacity of the VPX volume is 30 GiB. Create the volume with a capacity of 35 GiB. Set the volume type to General Purpose SSD (gp2) and name it something recognizable (for example, SC2S: Copy Low Vol). Attach the new volume to the Linux instance.

   

   

   

8. Power on the Linux instance and SSH to it from the bastion host using the private key file. Log in as ec2-user*.

9. Create a partition on the NEW EBS volume.

   Note:

   In this example, the VPX root volume SC2S: Commercial Root Vol is /dev/sdf and the newly created 35 GiB volume SC2S: Copy Low Vol is /dev/sdg. The partition is to be created on SC2S: Copy Low Vol only. In the AWS console, these block devices are denoted by symbolic links. In the Linux instance, /dev/sdf and /dev/sdg are referred to as /dev/xvdf and /dev/xvdg, respectively.

   In the Linux CLI, verify that there is no file system. The response should be data only.

   sudo file –s /dev/xvdg
   <!--NeedCopy-->