This page describes how you can easily save and create a typical set of VMs using the virtual appliance specs (blueprints) feature.
This page describes blueprints for a cloud administrator or reseller administrator, including the Catalogue functionalities, and sharing.
For details of how to use this blueprints for a tenant administrator, see https://abiquo.atlassian.net/wiki/pages/resumedraft.action?draftId=326598709.
Introduction to virtual appliance specifications
The virtual appliance specifications (VApp specs) feature enables administrators to save complex configurations and present them to users for simple, self-service deployment across their virtual datacenters. Specs are similar to blueprints because the platform uses them to define the configurations to recreate. Administrators select the locations where users can work with each spec, including datacenters and public cloud regions, such as AWS and Azure ARM.
With specs, you can save the configuration of virtual appliances including VMs, storage, networks, monitoring, Chef, firewalls, and load balancers. When users create a new virtual appliance based on a spec (also referred to as to "materialize" a spec), the platform will automatically use existing virtual resources or create new ones for this virtual appliance.The limitations of specs are as follows:
Specs do not store data from VM disks; they use template disks only
Specs do not support external networks and NICs or unmanaged networks and NICs
Specs do not support scaling groups
Users should also be aware of differences in features between private and public cloud environments.
Save a VApp configuration as a blueprint spec
To save a configuration of a group of VMs as a blueprint (virtual appliance spec):
Privileges: Manage virtual appliance specs
Go to myCloud → Virtual datacenters → Virtual appliances
Open the virtual appliance
Go to the virtual appliance options menu → select Create new spec
Enter spec details
The Description should identify the spec and the current version for the user
For the Icon, enter a URL
This URL must have a public IP address, not localhost or 127.0.0.1. It may contain the IP address of the API server. Use the same protocol as the server to avoid mixed content errors
Square icon images with a size of 128x128 pixels and a transparent background look best. The compatible image formats are PNG, JPG, and GIF.
Click Validate to check the display of the Icon
Optionally, go to Scopes and select scopes to share the spec with the tenants in those scopes
Optionally, go to Locations and select datacenters and public cloud regions where the user can work with the spec
Click Save
The platform will create the new spec for your tenant. This spec will be the default, but an administrator can change or remove the default.
When designing a virtual appliance for use in more than one location, please consider the following differences between private and public cloud:
Private cloud datacenters allow multiple disk templates and additional disks. In public cloud, the platform may support only a single disk or use all disks
Public networks in private cloud will be translated to floating IPs in public cloud and vice versa
A range of IP addresses may be reserved by an SDN system or the cloud provider
The number of NICs allowed or required per VM may vary
Firewall and load balancer configurations may differ
To save VM disks as templates, see Create instances to save VM disks to templates.
What do VApp specs save and create
When creating the new virtual appliance based on the spec, the platform will:
Click here to show or hide the What do VApp specs save and create table
The following VM configuration elements are saved and created by virtual appliance specs. When creating a virtual appliance from a spec, the platform will assign the spec icon to the virtual appliance.
Element | Save in Spec | Create in VApp from saved configuration |
---|
VMs | General information: hardware profiles, CPU, RAM, remote access and description | Same. If a matching hardware profile is not found, the platform will activate or create one, or the user can select another available hardware profile |
Anti-affinity layers | VMs in layers | Same |
Scaling groups | Scaling groups are not supported | |
VM templates | Template name is saved | The system matches the spec template name against the catalogue template name. The user selects from a list of templates with names that contain the spec template name. The match is done with an SQL %LIKE% command from the spec to the template, so spec template "m0n0" will match with "m0n0" and "m0n0wall" in the Catalogue. But spec template "m0n0wall" will not match with "m0n0" in the catalogue |
Template auxiliary hard disks | Template system disks and other datastore hard disks and their tiers are saved | The platform will create template disks in order as in the template with no gaps in the sequence. Then empty additional hard drives and volumes will be added in the same order as in the base virtual appliance. The platform will search for datastore tiers by name, as for templates |
Persistent VMs | Persistent VMs are not supported. (Use a VM from an instance of the persistent VM) | |
Private network, Private IPs | Save private network characteristics: network address and mask only. Save private IPs | The materialize process will present the addresses of the spec private networks. Abiquo will display matching networks in the virtual datacenter in green text, and ones that are not present in red text. Abiquo will display the number of private IPs to use in each network. The user can choose to change any private network, even if it matches the spec network. The user can choose to create a new network (specifying the IP address, mask and gateway), or replace the network with an existing VDC network. |
Network gateways | Abiquo will determine if a NIC has a gateway IP address and save this information in the spec | If a NIC has a gateway IP address, when using an existing network, the materialize process will attempt to assign the network's gateway address to the NIC Abiquo will not assign the gateway IP address to a NIC that did not have this address in the original configuration If the materialize process is creating a new network, it will attempt to assign the same gateway address from the spec to the gateway NIC in the new network
|
Public network | Number of public IPs is saved | The materialize process will try to use public IPs that were already purchased by the enterprise. These public IPs will be momentarily quarantined during the materialization process. If not, the materialize process will purchase new public IPs. The public networks will be used in the order returned by the API. In public cloud, the platform will use floating IPs |
External IPs | Not supported, except for basic support in VCD | If you create a spec containing an external IP, the materialize process will fail because the external IP is unsupported. In vCloud, specs have basic support for external networks. The validation process will list the network, and you can select it and then continue with the process. The platform will create the VApp correctly. Remember to ensure that there are enough external IP addresses available for the new virtual appliance |
Unmanaged IPs | Not supported | If you create a spec containing an unmanaged IP, the materialize process will fail because the unmanaged IP is unsupported. |
Volume (data) | Data on external storage volumes is not included. To use data on a volume, create an instance to save it to a template disk | |
Volume (specifications) | The specifications, disk controller types, and tiers of the volumes are saved in private cloud | Empty volumes with the same specifications as the attached volumes are created. Empty volumes are named vappName-UUID Volumes are attached to the same disk controller type as in the original VM. If this controller type is not compatible with the target hypervisor, then the platform will use the hypervisor default Matches tier names as for VM templates. If no storage tier is found, then the validate will fail. If the storage tier does not contain pools, then the volume create will fail.
|
Hard disk (data) | Data on hard disks attached to the VM is not included. To use data on a hard disk, create an instance to save it to the template | Empty hard disks with the same specifications as the attached hard disks are created. Empty disks are named Empty disk-UUID |
Hard disk (specifications) | The specifications, disk controller types and tiers of the hard disks are saved in private cloud | Empty hard disks with the same specifications as the attached hard disks are created. Empty disks are named Empty disk-UUID Hard disks are attached to the same disk controller type as in the original VM. If this controller type is not compatible with the target hypervisor, then the platform will use the hypervisor default Matches tier names as for VM templates. If no datastore tier is found, then the validate will fail. If the datastore tier does not contain datastores, then the deploy will fail.
|
Backup configuration | Configured backups are stored in private cloud | Backups are configured |
Firewalls | Firewalls attached to VMs or load balancers are saved | Access to a firewall integration is required to create firewalls in the new virtual appliance Users can edit firewall rules during virtual appliance creation Users should be aware of compatibility issues between providers If a VM has no firewall in the spec, and the virtual datacenter has a default firewall, then the platform will assign the default firewall to the VM
|
Load balancers | Load balancers attached to VMs are saved, including health checks and so on | |
Monitoring (status) | | |
Alarms and Alerts | Alarms and alerts are saved | The materialize process creates all existing alarms and alerts, regardless of the existence of their corresponding metrics |
VM variables | VM variables are saved | The materialize process creates VMs with VM variables During the materialize process, users can edit the VM variables
|
Chef | Chef status, runlist and attributes are stored | |
VM bootstrap script | The VM startup script is saved | The startup script is added to the new VM at the end of the materialize process After the materialize process, the user can edit the VM to modify the startup script
|
Manage VApp specs in the user interface
Unable to render {include} The included page could not be found.
Create a new version of a virtual appliance spec
Unable to render {include} The included page could not be found.
Display virtual appliance specs in the catalogue
Unable to render {include} The included page could not be found.
Share virtual appliance specs with other tenants
Unable to render {include} The included page could not be found.
Define the locations where users can work with a spec
Unable to render {include} The included page could not be found.
Define the version of a spec to use
The platform presents users with a single version of a virtual appliance spec. The administrator can configure this to be the default version or the latest version.
When you create a virtual appliance spec, the platform automatically sets this first version as the default version.
When you create another version you can choose to make this version the default.
To change the default version of a spec:
Go to Catalogue → Virtual appliance specs
Select the VApp spec icon, click the options button, and select Versions
Click on the Version you want users to work with
On the top, right-hand side of the dialog, click Mark as default version
To unset the default, so that users will always work with the latest version:
Select the VApp spec version and click the pencil Edit button
Clear the Default checkbox
To delete a version of a spec, select it and click the Delete button. If you delete the default version, then the platform will return the latest version to users.
Edit the details of a virtual appliance spec
Unable to render {include} The included page could not be found.
Delete a virtual appliance spec
Unable to render {include} The included page could not be found.