Skip to end of metadata
Go to start of metadata

Description

Note: This article is specific to Non-Guest OS Customization (NGOC) Servers. For instructions on deploying a Cloud Server from a Guest OS Customization (GOC) Image, see: How to Deploy a Cloud Server from a Guest OS Customization Image. For more information on the differences between the two types of Images and corresponding deployments, see Introduction to Cloud Server Provisioning, OS Customization, and Best Practices.

Please note that Non-Guest OS Customization (NGOC) Images are available only in MCP 2.0 Data Center locations.

Note: Long-Term Retention Snapshot Images are created from Long-Term Retention Snapshots. They are always created as Without Guest OS Customization Images. For more information, see Introduction to Cloud Server Snapshot Long-Term Retention Images

Prerequisites:

  1. Only the Primary Administrator or a Sub-Administrator with the Server role can create a Cloud Server.
  2. The Source Image you are deploying from needs to be a Non-Guest OS Customization Image. Non-Guest OS Customization Images can be identified by the presence of a "plug" icon as shown in the diagram below:
  3. You must provide a unique VLAN on the same Network Domain for each NIC associated with the source Non-Guest OS Customization Image.
    1. You cannot connect two NICs to the same VLAN - each VLAN can only be connected to one NIC on a given Server.
    2. Each VLAN must be in a NORMAL state.
    3. For details on how to deploy a VLAN, see How to Deploy a MCP 1.0 Cloud Network or a MCP 2.0 Network Domain, How to Deploy a VLAN on a Network Domain in an MCP 2.0 Data Center 
  4. If the Source Image exists in a Data Center location with User-Manageable Clusters, then the specifications of the Cloud Server must be supported by the Target Cluster. For details, see How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location.
  5. The Data Center must be MCP 2.0. Non-Guest OS Customization Images are not supported in MCP 1.0 Data Center locations.
  6. In order to deploy a Server with disks that utilize the Provisioned IOPS Disk Speed, the Data Center must be enabled with that speed. See How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location
  7. CPU count must be supported by the Servers Virtual Hardware version. We recommend keeping Virtual Hardware version up-to-date. See How to Update Virtual Hardware on a Cloud Server
    1. If changing the number of CPUs to anything other than 1, 2, or 4 CPUs, the Virtual Hardware must be Version 4 or greater
    2. Support for using 3/5/6/7/8 virtual CPU's requires Virtual Hardware version 7
    3. Support for using more than 8 vCPU  requires Virtual Hardware version 8
    4. Support for using more than 32 vCPU requires Virtual Hardware version 9
    5. Support for using more than 64 vCPU's requires Virtual Hardware version 11
    6. Support for using more than 128 vCPU's requires Virtual Hardware version 15
  8. RAM count must be supported by Server's Virtual Hardware version. We recommend keeping the Virtual Hardware version up-to-date. See How to Update Virtual Hardware on a Cloud Server
    1. Support for using more than 64 GB RAM requires Virtual Hardware version 7
    2. Support for using more than 255 GB RAM requires Virtual Hardware version 8
    3. Support for using more than 1011 GB RAM requires Virtual Hardware version 11
    4. Support for using more than 4080 GB RAM requires Virtual Hardware version 13
  9. Advanced Virtualization Settings validations:
    1. For more information on Advanced Virtualization Settings, See Introduction to Advanced Virtualization Settings
      1. If the Source Image has Nested Hardware Virtualization set to true, then the Target Cluster must be enabled to support Advanced Virtualization Settings. See How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location
      2. If the Source Image has CPU Latency Sensitivity set to HIGH, then the Target Cluster must be enabled to support Advanced Virtualization Settings. See How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location
      3. If Source Image has Numa Autosize numaAutosize set to true, then the Target Cluster must be enabled to support Advanced Virtualization Settings. See How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location
      4. If Source Image has Enable Host Info to VM Tools set to true, then the Target Cluster must be enabled to support Advanced Virtualization Settings. See How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location

Content / Solution:

  1. From the Home page, click the Deploy Server button:


  2. The Select Image tab of the Deploy Server dialog will be displayed:


  3. Search for the NGOC OS Image that you want for your Cloud Server. You can choose from a variety of filters or search by Name using the respective search bars:

  4. Select a Non-Guest OS Customization Server Image from which to deploy your new Cloud Server. Once you have clicked on the desired Image, the system will indicate that it has been selected:

    Note: The description will indicate the total number of NICs on the Image. You must specify a unique VLAN in the Network Domain for each NIC as part of the deployment.

  5. Verify that you have selected the correct Server image. Click the Next button:


  6. The Server Details tab of the Deploy Server dialog will be displayed:

    • If you wish to create multiple Cloud Servers from the same Server Image, you can click the Add Server button. You can create up to 10 Servers at a time:

    • You can remove additional Servers by clicking the Manage gear next to the additional Server slot and selecting the Remove option from the drop-down menu.

      Note: The Server Image you selected in the previous step is displayed at the top of the dialog.
       

  7. Enter the appropriate Server details, then click Customize:

    • Data Center - Select the Data Center where the new Cloud Server(s) will be deployed. 

    • Network Domain- Select the Network Domain with which the Cloud Server(s) will be associated. 

    • Server Name - The Server Name is a descriptive name that will appear with the Cloud Server when viewing Servers in the administrative interface. It has no impact on the Server's functionality, machine name, or hostname. Therefore, Server Names are not required to be unique.

    • Choose your Network target for the Server Deployment:

      • VLANs (one entry per NIC on the Source NGOC Image) - Select a unique VLAN for each NIC. You cannot connect two NICs to the same VLAN - each VLAN can only be connected to one NIC on a given Server.

      • NIC Type - CloudControl supports five different "Network Adapters" (also referred to as "NIC Types") as defined by VMware in their KB article Choosing a network adapter for your virtual machine. These adapters represent the "hardware" that the NIC will appear to be to the Guest Operating System. The system will default to using the Network Adapter of the Source Image. However, you can click on the drop-down menu and select a different NIC Type. 

      • NIC State - You can select whether you want to deploy with the NIC(s) Connected or Disconnected. The default setting is 'Connected'. For more information on NIC Connectivity, see Introduction to Cloud Server NICs in MCP 2.0

      • IPv4 Address - Enter the desired IPv4 address or leave it blank to have an IP address assigned automatically by the system. When specifying an IP address, the proposed IP address cannot be "Exclusively reserved" and must not fall into the reserved ranges on the VLAN. For more details, see How do IP Addresses Work in a MCP 2.0 Data Center Location.

        • An IP Address that is in use by another Asset will have the  IP Address In Use icon, which indicates that the IP Address is in use by another cloud asset. You can still deploy the Server with this IP Address, but it may cause an IP conflict.

        • An IP Address that is exclusively reserved will be denoted by the  Exclusively Reserved icon. This icon indicates that the IP Address cannot be used for any further deployments until it is unreserved.

    • Description - You also have the option to enter a more detailed description (up to 255 characters) to be associated with the Server. Again, this is only for descriptive purposes.


  8.  The Server Spec tab of the Deploy Server dialog will be displayed. Set the specific Server parameters:

    • Cluster - If the Data Center is enabled with User-Manageable Clusters, you can select the desired Cluster from the drop-down menu. Otherwise, the default Cluster will be utilized. see Introduction to User-Manageable Clusters for more information.

    • CPU - Set the desired amount of CPU for the Server.

      • OS Units Group ID - Displays the OS Units Group ID. Cannot be changed. For more information on OS Units, see Introduction to OS Units
      • OS Units Usage Element - Displays OS Units Usage Element. Cannot be changed. For more information on OS Units, see Introduction to OS Units
      • OS Rate Type - Displays OS Rate Type. Cannot be changed. For more information on OS Units, see Introduction to OS Units
      • OS Rate - Displays OS Rate. Cannot be changed. For more information on OS Units, see Introduction to OS Units
    • Cores per Socket - Set the desired number of Cores per socket. Note that the display to the right of the drop-down menu will change to indicate the selected number of Cores per socket. The system will only present you with acceptable options.
      Note: One core per socket will provide the highest performance in all scenarios. When dealing with larger numbers of vCPUs on a Cloud Server (generally greater than 8 vCPUs), be aware that presenting multiple cores per socket may adversely impact performance due to NUMA calculations. For a more detailed discussion on this issue, see http://www.virtadmin.com/sockets-vs-cores-vmware/ or VMware’s blog post at http://blogs.vmware.com/vsphere/2013/10/does-corespersocket-affect-performance.html.
    • CPU Speed - Set the desired CPU Speed.  For more information on CPU Speeds, see Introduction to CPU Speeds (vCPU Classes)

    • RAM - Set the desired amount of RAM for the Server.

    • Storage - The Cloud Server will be deployed with the same storage as the Client Image (i.e. same local disk sizes in the same Id positions). However, you can modify the disk speed on deployment:

    • Add/Update Tag to List - Optionally add Tags to the Server. For more information on tagging, see Introduction to Tagging, Tag Keys and Tag Values

      Guest OS Variables are NOT modified from the Source Image as part of NGOC Deployment

      As part of Non-Guest OS Customization Image deployments, the following Guest OS settings are inherited (i.e. will be the same) from the settings of the Source Image. Hence you are not prompted for them as part of the deployment process:

      1) Root/Administrator Password - The deployed Cloud Servers will retain the same Root/Administrator password as the Source Image.

      2) DNS information (Standard or Secondary) - Since DNS is inherited from the Source Image, it may or may not be valid from the VLANs and/or default route on.

      3) Server Gateway IPv4 - The is the default route setting in the Guest Operating System. Since it is inherited from the Source Image, it may or may not be valid and/or correspond to the Primary NIC.

      4) Windows Time Zone (for Microsoft Windows deployments only) - This is the timezone perceived by the Windows Guest OS as the default route setting in the Guest Operating System. Since it is inherited from the Source Image, it may or may not be valid.

      If the Source Image was created as a Clone from a Client Image as described in How to Clone a Cloud Server to Create a Client Image, these values will be the same as the Cloud Server from which the Image was created.

      In any case, these settings may not be valid and you may need to update them in the Guest OS after deployment as described in the last step of this process.

      IPv4 and IPv6 Addresses are NOT configured in Guest OS as part of NGOC Deployment

      Similarly, the IPv4 and IPv6 address for each NIC is also inherited from the Source Image. The values shown in the UI after deployment represent the values that should be applied to the NICs in the Guest OS, not how the Guest OS is actually configured. They must be set correctly in the Guest OS following deployment in order for the Cloud Server to function properly. Should you choose to use different settings in the Guest OS, you can notify the system as described in How to Notify CloudControl of a Change to the IP Addresses of a NIC in a MCP 2.0 Data Center.

      In order to configure each NIC, the administrator needs to retrieve the relevant IP addresses from the Server Details screen in CloudControl. Each NIC visible on the Server Details screen can be correlated with those in the Guest Operating System using the MAC Address provided. As an additional aid, the VMware NIC Key is also displayed for each NIC. The NIC Key is an integer which rises incrementally from 4000-4009 from the Primary NIC through each additional NIC cloned from the source Server Image. In doing so, it identifies the order in which the NICs will be presented within the Guest Operating System.

      Also note that the IP address inherited from the source Server Image may conflict with another provisioned Cloud Server in the selected Network Domain once it is deployed and started!

  9. Click the Next button. The system will show you an overview of the Server deployment:

    Note: You can choose to Start the Server(s) upon deployment by checking the highlighted box.

    • Location - Describes the location of the Server
    • Data Center - Name of the Data Center 
    • Cluster Name - Name of the Cluster (If enabled for the Data Center)
    • Network Name - Name of the Network Domain
    • Supports Backup - whether the Server supports Backup. True or False
    • Operating System Family - Describes the Operating System Family
    • OS Units Group ID - Describes the OS Units Group ID
      • Note: hovering your mouse over the  info icon will display the OS Units methodology as described in Introduction to OS Units

    • OS Rate - Tells how many OS Units are generated per hour, based on the selected configuration


  10. Once you have reviewed the Server, click the Deploy button. The system will display a message indicating that the deployment is in progress:


  11. The Server will be added to the Server pool and the system will indicate that the Server deployment is in progress:

    Note: Your Server will take time to deploy. The specific amount of time is variable depending on several factors. For more details, see Introduction to Cloud Server Provisioning, OS Customization, and Best Practices.
     

  12. Assuming the Server is successfully deployed, it will appear in the Servers tab of the Network / Network Domain dashboard. Note the IP address is now listed and you are free to access and/or manage the Server to make additional changes:

    Note: If you chose to start the Server upon deployment, it will be in a running state as indicated by the color of the Server icon. 

    Note: If for some reason the server deployment fails (though this is rare with Non-Guest OS Customization deployments), the pending Server will be displayed in the Admin UI with a brown/maroon bar with brief information about the error. The full error description will be displayed in a popup and will also be logged in the Administrator Logs. To review the Administrator Logs, see How to Create an Administrator Logs Report. To remove the failed deployment, follow the instructions at How to Remove a Failed Server Deployment. 
     

  13. As described in the warnings in Step #8, you will now need to configure the Guest OS to the desired settings including assigning both IPv4 and IPv6 addresses to each NIC, add/modify DNS entries, adjust Windows timezone configurations, and change the root/administrator password (if desired). In many cases, the NIC configurations and gateway will be invalid and the Server will be unavailable on the Network - this will require logging in via Console as described in How to Get Virtual Console Access to a Cloud Server.

Recently Updated