CloudStack fournit aux administrateurs un contrôle complet du cycle de vie de toutes les VM invitées exécutées dans le cloud. CloudStack fournit différentes opérations de gestion des invités aux utilisateurs finaux et aux administrateurs. Les VMs peuvent être stoppées, démarrées, redémarrées et détruites.
Les VM invitées ont un nom et un groupe. Les noms des VM et les groupes sont opaques pour CloudStack et sont utiles aux utilisateurs finaux pour organiser leurs VM. Chaque VM peut avoir trois noms différents pour utiliser dans différents contextes. Seulement deux de ces noms sont contrôlés par l’utilisateur :
Nom de l’instance - un ID unique et non modifiable qui est généré par CloudStack et ne peut pas être modifié par l’utilisateur. Ce nom est conforme aux exigences de la RFC 1123 de l’IETF.
Nom affiché - le nom affiché dans l’interface web CloudStack. Peut être fixé par l’utilisateur. Prend par défaut le nom de l’instance.
Nom - nom de machine que le serveur DHCP assigne à la VM. Peut être fixé par l’utilisateur. Prend par défaut le nom de l’instance.
Note
Vous pouvez ajouter le nom affiché d’une VM invitée à son nom interne. Pour plus d’informations, voir “Ajouter un Nom d’Affichage au Nom Interne d’une VM invités.”.
Les VM invités peuvent être configuré pour être Hautement Disponible (HA). Une VM dont la HA est activée est supervisée par le système. Si le système détecte que la VM est à l’arrêt, il va tenter de redémarrer la VM, si possible sur un hôte différent. Pour plus d’information, voir Activer la HA sur les Machines Virtuelles.
Chaque nouvelle VM se voit attribué une adresse IP Publique. Quand la VM est démarrée, CloudStack crée automatiquement un NAT static entre cette adresse IP public et l’adresse IP privée de la VM.
If elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new VM is not marked as elastic. The user must replace the automatically configured IP with a specifically acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s private IP. The VM’s original IP address is then released and returned to the pool of available public IPs. Optionally, you can also decide not to allocate a public IP to a VM in an EIP-enabled Basic zone. For more information on Elastic IP, see “About Elastic IP”.
CloudStack cannot distinguish a guest VM that was shut down by the user (such as with the “shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut down from inside the VM, CloudStack will restart it. To shut down an HA-enabled VM, you must go through the CloudStack UI or API.
For VMs to work as expected and provide excellent service, follow these guidelines.
The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
Be sure the following are installed on each VM:
To be sure that Xen tools or VMware Tools is installed, use one of the following techniques:
Les machines virtuelles peuvent se trouver dans les états suivants :
Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual machine will be reclaimed by the system. This includes the virtual machine’s IP address.
A stop will attempt to gracefully shut down the operating system, which typically involves terminating all the running applications. If the operation system cannot be stopped, it will be forcefully terminated. This has the same effect as pulling the power cord to a physical machine.
Un redémarrage est un arrêt suivi d’un démarrage.
CloudStack preserves the state of the virtual machine hard disk until the machine is destroyed.
A running virtual machine may fail because of hardware or network issues. A failed virtual machine is in the down state.
The system places the virtual machine into the down state if it does not receive the heartbeat from the hypervisor for three minutes.
The user can manually restart the virtual machine from the down state.
The system will start the virtual machine from the down state automatically if the virtual machine is marked as HA-enabled.
Virtual machines are usually created from a template. Users can also create blank virtual machines. A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and install the OS from the CD/DVD-ROM.
Note
You can create a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A request parameter, startVM, in the deployVm API provides this feature. For more information, see the Developer’s Guide.
To create a VM from a template:
Log in to the CloudStack UI as an administrator or user.
In the left navigation bar, click Instances.
Cliquer sur Ajouter une instance.
Sélectionner une zone.
Select a template, then follow the steps in the wizard. For more information about how the templates came to be in this list, see *Working with Templates*.
Be sure that the hardware you have allows starting the selected service offering.
Click Submit and your VM will be created and started.
Note
For security reason, the internal name of the VM is visible only to the root admin.
To create a VM from an ISO:
Note
(XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
Cliquer sur Ajouter une instance.
Sélectionner une zone.
Tous les utilisateur peuvent accéder à leur propore machines virtuelles. L’administrateur peut accéder à toute les VMs qui fonctionnent dans le cloud.
To access a VM through the CloudStack UI:
Cliquez sur Instances, puis choisissez le nom de la VM en cours d’éxécution.
Pour accéder à une VM directement à travers le réseau :
Once a VM instance is created, you can stop, restart, or delete it as needed. In the CloudStack UI, click Instances, select the VM, and use the Stop, Start, Reboot, and Destroy buttons.
At any point in time, each virtual machine instance is running on a single host. How does CloudStack determine which host to place a VM on? There are several ways:
By defining affinity groups and assigning VMs to them, the user or administrator can influence (but not dictate) which VMs should run on separate hosts. This feature is to let users specify that VMs with the same “host anti-affinity” type won’t be on the same host. This serves to increase fault tolerance. If a host fails, another VM offering the same service (for example, hosting the user’s website) is still up and running on another host.
The scope of an affinity group is per user account.
To add an affinity group:
To assign a new VM to an affinity group:
To assign an existing VM to an affinity group:
To see which VMs are currently assigned to a particular affinity group:
In the left navigation bar, click Affinity Groups.
Click the name of the group you are interested in.
Click View Instances. The members of the group are listed.
From here, you can click the name of any VM in the list to access all its details and controls.
To delete an affinity group:
In the left navigation bar, click Affinity Groups.
Click the name of the group you are interested in.
Click Delete.
Any VM that is a member of the affinity group will be disassociated from the group. The former group members will continue to run normally on the current hosts, but if the VM is restarted, it will no longer follow the host allocation rules from its former affinity group.
(Supported on VMware and XenServer)
In addition to the existing CloudStack ability to snapshot individual VM volumes, you can take a VM snapshot to preserve all the VM’s data volumes as well as (optionally) its CPU/memory state. This is useful for quick restore of a VM. For example, you can snapshot a VM, then make changes such as software upgrades. If anything goes wrong, simply restore the VM to its previous state using the previously saved VM snapshot.
The snapshot is created using the hypervisor’s native snapshot facility. The VM snapshot includes not only the data volumes, but optionally also whether the VM is running or turned off (CPU state) and the memory contents. The snapshot is stored in CloudStack’s primary storage.
VM snapshots can have a parent/child relationship. Each successive snapshot of the same VM is the child of the snapshot that came before it. Each time you take an additional snapshot of the same VM, it saves only the differences between the current state of the VM and the state stored in the most recent previous snapshot. The previous snapshot becomes a parent, and the new snapshot is its child. It is possible to create a long chain of these parent/child snapshots, which amount to a “redo” record leading from the current state of the VM back to the original.
If you need more information about VM snapshots on VMware, check out the VMware documentation and the VMware Knowledge Base, especially Understanding virtual machine snapshots.
The cloud administrator can use global configuration variables to control the behavior of VM snapshots. To set these variables, go through the Global Settings area of the CloudStack UI.
Configuration Setting Name
Description
vmsnapshots.max
The maximum number of VM snapshots that can be saved for any given virtual machine in the cloud. The total possible number of VM snapshots in the cloud is (number of VMs) * vmsnapshots.max. If the number of snapshots for any VM ever hits the maximum, the older ones are removed by the snapshot expunge job.
vmsnapshot.create.wait
Number of seconds to wait for a snapshot job to succeed before declaring failure and issuing an error.
To create a VM snapshot using the CloudStack UI:
Log in to the CloudStack UI as a user or administrator.
Click Instances.
Click the name of the VM you want to snapshot.
Click the Take VM Snapshot button.
Note
If a snapshot is already in progress, then clicking this button will have no effect.
Provide a name and description. These will be displayed in the VM Snapshots list.
(For running VMs only) If you want to include the VM’s memory in the snapshot, click the Memory checkbox. This saves the CPU and memory state of the virtual machine. If you don’t check this box, then only the current state of the VM disk is saved. Checking this box makes the snapshot take longer.
Quiesce VM: check this box if you want to quiesce the file system on the VM before taking the snapshot. Not supported on XenServer when used with CloudStack-provided primary storage.
When this option is used with CloudStack-provided primary storage, the quiesce operation is performed by the underlying hypervisor (VMware is supported). When used with another primary storage vendor’s plugin, the quiesce operation is provided according to the vendor’s implementation.
Cliquez sur OK.
To delete a snapshot or restore a VM to the state saved in a particular snapshot:
Navigate to the VM as described in the earlier steps.
Click View VM Snapshots.
In the list of snapshots, click the name of the snapshot you want to work with.
Depending on what you want to do:
To delete the snapshot, click the Delete button.
To revert to the snapshot, click the Revert button.
Note
VM snapshots are deleted automatically when a VM is destroyed. You don’t have to manually delete the snapshots in this case.
After a VM is created, you can modify the display name, operating system, and the group it belongs to.
To access a VM through the CloudStack UI:
Sur la gauche, cliquez sur Instances
Every guest VM has an internal name. The host uses the internal name to identify the guest VMs. CloudStack gives you an option to provide a guest VM with a display name. You can set this display name as the internal name so that the vCenter can use it to identify the guest VM. A new global parameter, vm.instancename.flag, has now been added to achieve this functionality.
The default format of the internal name is i-<user_id>-<vm_id>-<instance.name>, where instance.name is a global parameter. However, If vm.instancename.flag is set to true, and if a display name is provided during the creation of a guest VM, the display name is appended to the internal name of the guest VM on the host. This makes the internal name format as i-<user_id>-<vm_id>-<displayName>. The default value of vm.instancename.flag is set to false. This feature is intended to make the correlation between instance names and internal names easier in large data center deployments.
The following table explains how a VM name is displayed in different scenarios.
User-Provided Display Name | vm.instancename.flag | Hostname on the VM | Name on vCenter | Internal Name |
---|---|---|---|---|
Oui |
True | Display name | i-<user_id>-<vm_id>-displayName | i-<user_id>-<vm_id>-displayName |
Non |
True | UUID | i-<user_id>-<vm_id>-<instance.name> | i-<user_id>-<vm_id>-<instance.name> |
Oui |
False | Display name | i-<user_id>-<vm_id>-<instance.name> | i-<user_id>-<vm_id>-<instance.name> |
Non |
False | UUID | i-<user_id>-<vm_id>-<instance.name> | i-<user_id>-<vm_id>-<instance.name> |
To upgrade or downgrade the level of compute resources available to a virtual machine, you can change the VM’s compute offering.
Log in to the CloudStack UI as a user or admin.
Sur la gauche, cliquez sur Instances
Choose the VM that you want to work with.
(Skip this step if you have enabled dynamic VM scaling; see CPU and Memory Scaling for Running VMs.)
Click the Stop button to stop the VM.
Click the Change Service button.
The Change service dialog box is displayed.
Select the offering you want to apply to the selected VM.
Cliquez sur OK.
(Supported on VMware and XenServer)
It is not always possible to accurately predict the CPU and RAM requirements when you first deploy a VM. You might need to increase these resources at any time during the life of a VM. You can dynamically modify CPU and RAM levels to scale up these resources for a running VM without incurring any downtime.
Dynamic CPU and RAM scaling can be used in the following cases:
If you are upgrading from a previous version of CloudStack, and you want your existing VMs created with previous versions to have the dynamic scaling capability, update the VMs using the following steps:
To configure this feature, use the following new global configuration variables:
To modify the CPU and/or RAM capacity of a virtual machine, you need to change the compute offering of the VM to a new compute offering that has the desired CPU and RAM values. You can use the same steps described above in “Changing the Service Offering for a VM”, but skip the step where you stop the virtual machine. Of course, you might have to create a new compute offering first.
When you submit a dynamic scaling request, the resources will be scaled up on the current host if possible. If the host does not have enough resources, the VM will be live migrated to another host in the same cluster. If there is no host in the cluster that can fulfill the requested level of CPU and RAM, the scaling operation will fail. The VM will continue to run as it was before.
For secure environments, and to ensure that VM state is not persisted across reboots, you can reset the root disk. For more information, see “Reset VM to New Root Disk on Reboot”.
The CloudStack administrator can move a running VM from one host to another without interrupting service to users or going into maintenance mode. This is called manual live migration, and can be done under the following conditions:
To manually live migrate a virtual machine
Log in to the CloudStack UI as a user or admin.
Sur la gauche, cliquez sur Instances
Choose the VM that you want to migrate.
Click the Migrate Instance button.
From the list of suitable hosts, choose the one to which you want to move the VM.
Note
If the VM’s storage has to be migrated along with the VM, this will be noted in the host list. CloudStack will take care of the storage migration for you.
Cliquez sur OK.
Les utilisateurs peuvent supprimer leurs machines virtuelles. Une VM en cours d’utilisation sera arrêtée brutalement avant suppression. Les administrateurs peuvent supprimer n’importe quelle VM.
Pour supprimer une machine virtuelle :
Sur la gauche, cliquez sur Instances
Choisissez la VM que vous voulez supprimer.
CloudStack supports ISOs and their attachment to guest VMs. An ISO is a read-only file that has an ISO/CD-ROM style file system. Users can upload their own ISOs and mount them on their guest VMs.
ISOs are uploaded based on a URL. HTTP is the supported protocol. Once the ISO is available via HTTP specify an upload URL such as http://my.web.server/filename.iso.
ISOs may be public or private, like templates.ISOs are not hypervisor-specific. That is, a guest on vSphere can mount the exact same image that a guest on KVM can mount.
ISO images may be stored in the system and made available with a privacy level similar to templates. ISO images are classified as either bootable or not bootable. A bootable ISO image is one that contains an OS image. CloudStack allows a user to boot a guest VM off of an ISO image. Users can also attach ISO images to guest VMs. For example, this enables installing PV drivers into Windows. ISO images are not hypervisor-specific.
To make additional operating system or other software available for use with guest VMs, you can add an ISO. The ISO is typically thought of as an operating system image, but you can also add ISOs for other types of software, such as desktop applications that you want to be installed as part of a template.
Log in to the CloudStack UI as an administrator or end user.
In the left navigation bar, click Templates.
In Select View, choose ISOs.
Click Add ISO.
In the Add ISO screen, provide the following:
Name: Short name for the ISO image. For example, CentOS 6.2 64-bit.
Description: Display test for the ISO image. For example, CentOS 6.2 64-bit.
URL: The URL that hosts the ISO image. The Management Server must be able to access this location via HTTP. If needed you can place the ISO image directly on the Management Server
Zone: Choose the zone where you want the ISO to be available, or All Zones to make it available throughout CloudStack.
Bootable: Whether or not a guest could boot off this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not bootable.
OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
Note
It is not recommended to choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not work. In these cases, choose Other.
Extractable: Choose Yes if the ISO should be available for extraction.
Public: Choose Yes if this ISO should be available to other users.
Featured: Choose Yes if you would like this ISO to be more prominent for users to select. The ISO will appear in the Featured ISOs list. Only an administrator can make an ISO Featured.
Cliquez sur OK.
The Management Server will download the ISO. Depending on the size of the ISO, this may take a long time. The ISO status column will display Ready once it has been successfully downloaded into secondary storage. Clicking Refresh updates the download percentage.
Important: Wait for the ISO to finish downloading. If you move on to the next task and try to use the ISO right away, it will appear to fail. The entire ISO must be available before CloudStack can work with it.
Sur la gauche, cliquez sur Instances
Choisissez la machine virtuelle avec laquelle vous souhaitez travailler.
Dans la boîte de dialogue Attacher une ISO, sélectionnez l’ISO voulue.
Cliquez sur OK.
Every VM is created from a base image, which is a template or ISO which has been created and stored in CloudStack. Both cloud administrators and end users can create and modify templates, ISOs, and VMs.
In CloudStack, you can change an existing VM’s base image from one template to another, or from one ISO to another. (You can not change from an ISO to a template, or from a template to an ISO).
For example, suppose there is a template based on a particular operating system, and the OS vendor releases a software patch. The administrator or user naturally wants to apply the patch and then make sure existing VMs start using it. Whether a software update is involved or not, it’s also possible to simply switch a VM from its current template to any other desired template.
To change a VM’s base image, call the restoreVirtualMachine API command and pass in the virtual machine ID and a new template ID. The template ID parameter may refer to either a template or an ISO, depending on which type of base image the VM was already using (it must match the previous type of image). When this call occurs, the VM’s root disk is first destroyed, then a new root disk is created from the source designated in the template ID parameter. The new root disk is attached to the VM, and now the VM is based on the new template.
You can also omit the template ID parameter from the restoreVirtualMachine call. In this case, the VM’s root disk is destroyed and recreated, but from the same template or ISO that was already in use by the VM.
In addition to the username and password authentication, CloudStack supports using SSH keys to log in to the cloud infrastructure for additional security. You can use the createSSHKeyPair API to generate the SSH keys.
Because each cloud user has their own SSH key, one cloud user cannot log in to another cloud user’s instances unless they share their SSH key files. Using a single SSH key pair, you can manage multiple instances.
Create an instance template that supports SSH Keys.
Create a new instance by using the template provided by cloudstack.
For more information on creating a new instance, see
Download the cloudstack script from The SSH Key Gen Script to the instance you have created.
wget http://downloads.sourceforge.net/project/cloudstack/SSH%20Key%20Gen%20Script/cloud-set-guest-sshkey.in?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcloudstack%2Ffiles%2FSSH%2520Key%2520Gen%2520Script%2F&ts=1331225219&use_mirror=iweb
Copy the file to /etc/init.d.
cp cloud-set-guest-sshkey.in /etc/init.d/
Give the necessary permissions on the script:
chmod +x /etc/init.d/cloud-set-guest-sshkey.in
Run the script while starting up the operating system:
chkconfig --add cloud-set-guest-sshkey.in
Stop the instance.
You must make a call to the createSSHKeyPair api method. You can either use the CloudStack Python API library or the curl commands to make the call to the cloudstack api.
For example, make a call from the cloudstack server to create a SSH keypair called “keypair-doc” for the admin account in the root domain:
Note
Ensure that you adjust these values to meet your needs. If you are making the API call from a different server, your URL/PORT will be different, and you will need to use the API keys.
Run the following curl command:
curl --globoff "http://localhost:8096/?command=createSSHKeyPair&name=keypair-doc&account=admin&domainid=5163440e-c44b-42b5-9109-ad75cae8e8a2"
The output is something similar to what is given below:
<?xml version="1.0" encoding="ISO-8859-1"?><createsshkeypairresponse cloud-stack-version="3.0.0.20120228045507"><keypair><name>keypair-doc</name><fingerprint>f6:77:39:d5:5e:77:02:22:6a:d8:7f:ce:ab:cd:b3:56</fingerprint><privatekey>-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
-----END RSA PRIVATE KEY-----
</privatekey></keypair></createsshkeypairresponse>
Copy the key data into a file. The file looks like this:
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
-----END RSA PRIVATE KEY-----
Save the file.
After you save the SSH keypair file, you must create an instance by using the template that you created at Section 5.2.1, “ Creating an Instance Template that Supports SSH Keys”. Ensure that you use the same SSH key name that you created at Section 5.2.2, “Creating the SSH Keypair”.
Note
You cannot create the instance by using the GUI at this time and associate the instance with the newly created SSH keypair.
A sample curl command to create a new instance is:
curl --globoff http://localhost:<port number>/?command=deployVirtualMachine\&zoneId=1\&serviceOfferingId=18727021-7556-4110-9322-d625b52e0813\&templateId=e899c18a-ce13-4bbf-98a9-625c5026e0b5\&securitygroupids=ff03f02f-9e3b-48f8-834d-91b822da40c5\&account=admin\&domainid=1\&keypair=keypair-doc
Substitute the template, service offering and security group IDs (if you are using the security group feature) that are in your cloud environment.
To test your SSH key generation is successful, check whether you can log in to the cloud setup.
For example, from a Linux OS, run:
ssh -i ~/.ssh/keypair-doc <ip address>
The -i parameter tells the ssh client to use a ssh key found at ~/.ssh/keypair-doc.
With the API command resetSSHKeyForVirtualMachine, a user can set or reset the SSH keypair assigned to a virtual machine. A lost or compromised SSH keypair can be changed, and the user can access the VM by using the new keypair. Just create or register a new keypair, then call resetSSHKeyForVirtualMachine.
CloudStack fournit un accès à une API pour attacher plus de 2KB de données après encodage en base64 à une VM déployée. En utilisant une requête POST HTTP (via POST body), vous pouvez envoyer jusqu’à 32K de données après encodage en base64. Les VM déployées ont ainsi accès aux méta-données d’instance via le routeur virtuel.
Créer une machine virtuelle via l’API : deployVirtualMachine en utilisant le paramètre userdata=
pour inclure les données utilisateurs formatées en base64.
Accéder aux données utilisateur depuis la VM. Une ois que l’adresse IP du routeur virtuel est connue, utiliser les étapes suivantes pour récupérer les méta-données :
Lancer la commande suivante pour trouver le routeur virtuel.
# cat /var/lib/dhclient/dhclient-eth0.leases | grep dhcp-server-identifier | tail -1
Accéder aux données utilisateurs en lancer la commande suivante utilisant le résultat de la commande précédente
# curl http://10.1.1.1/latest/user-data
Les méta-données peuvent être accédées de manière similaire, utilisant une URL de la forme http://10.1.1.1/latest/meta-data/{metadata type}
. (Pour des raisons de compatibilités ascendantes, les anciennes URL http://10.1.1.1/latest/{metadata type}
sont aussi supportées.) Pour le type de méta-données, utiliser au choix :
service-offering
. Une description de l’offre de service des VM.
availability-zone
. Le nom de la Zone
local-ipv4
. L’adresse IP invitée de la VM
local-hostname
. Le nom d’hôte de la VM
public-ipv4
. La première IP publique pour le routeur. (E.g. la première IP d’eth2)
public-hostname
. Identique à public-ipv4
instance-id
. Le nom d’instance de la VM
Cloud-Init peut être utiliser pour accéder aux données utilisateurs depuis les machines virtuelles. Cloud-init peut être installé dans les modèles et néssite aussi les scripts CloudStack password et sshkey (Ajouter un mot de passe de gestion à votre modèle et utiliser les clefs ssh). La gestion du mot de passe utilisateur et l’API resetSSHKeyForVirtualMachine
ne sont pas encore supportés par cloud-init.
Installer le paquet cloud-init dans le modèle :
# yum install cloud-init
or
$ sudo apt-get install cloud-init
Créer un fichier de configuration de source de données : /etc/cloud/cloud.cfg.d/99_cloudstack.cfg
datasource:
CloudStack: {}
None: {}
datasource_list:
- CloudStack
Cet exemple utilise cloud-init pour mettre à jour le système d’exploitation d’une VM nouvellement crée :
#cloud-config
# Upgrade the instance on first boot
# (ie run apt-get upgrade)
#
# Default: false
# Aliases: apt_upgrade
package_upgrade: true
formatée en base64 :
I2Nsb3VkLWNvbmZpZw0KDQojIFVwZ3JhZGUgdGhlIGluc3RhbmNlIG9uIGZpcnN0IGJvb3QNCiMgKGllIHJ1biBhcHQtZ2V0IHVwZ3JhZGUpDQojDQojIERlZmF1bHQ6IGZhbHNlDQojIEFsaWFzZXM6IGFwdF91cGdyYWRlDQpwYWNrYWdlX3VwZ3JhZGU6IHRydWUNCg==
Se référer à la documentation Cloud-Init CloudStack datasource pour les dernières possibilitées. Cloud-Init et source de données Cloud-Init CloudStack ne sont pas supportées par la communauté Apache CloudStack.
CloudStack can deploy guest VMs with Graphics Processing Unit (GPU) or Virtual Graphics Processing Unit (vGPU) capabilities on XenServer hosts. At the time of VM deployment or at a later stage, you can assign a physical GPU ( known as GPU-passthrough) or a portion of a physical GPU card (vGPU) to a guest VM by changing the Service Offering. With this capability, the VMs running on CloudStack meet the intensive graphical processing requirement by means of the high computation power of GPU/vGPU, and CloudStack users can run multimedia rich applications, such as Auto-CAD, that they otherwise enjoy at their desk on a virtualized environment. CloudStack leverages the XenServer support for NVIDIA GRID Kepler 1 and 2 series to run GPU/vGPU enabled VMs. NVIDIA GRID cards allows sharing a single GPU cards among multiple VMs by creating vGPUs for each VM. With vGPU technology, the graphics commands from each VM are passed directly to the underlying dedicated GPU, without the intervention of the hypervisor. This allows the GPU hardware to be time-sliced and shared across multiple VMs. XenServer hosts use the GPU cards in following ways:
GPU passthrough: GPU passthrough represents a physical GPU which can be directly assigned to a VM. GPU passthrough can be used on a hypervisor alongside GRID vGPU, with some restrictions: A GRID physical GPU can either host GRID vGPUs or be used as passthrough, but not both at the same time.
GRID vGPU: GRID vGPU enables multiple VMs to share a single physical GPU. The VMs run an NVIDIA driver stack and get direct access to the GPU. GRID physical GPUs are capable of supporting multiple virtual GPU devices (vGPUs) that can be assigned directly to guest VMs. Guest VMs use GRID virtual GPUs in the same manner as a physical GPU that has been passed through by the hypervisor: an NVIDIA driver loaded in the guest VM provides direct access to the GPU for performance-critical fast paths, and a paravirtualized interface to the GRID Virtual GPU Manager, which is used for nonperformant management operations. NVIDIA GRID Virtual GPU Manager for XenServer runs in dom0. CloudStack provides you with the following capabilities:
Before proceeding, ensure that you have these prerequisites:
Before continuing with configuration, consider the following:
Device | Type |
---|---|
GPU |
|
vGPU |
|
CloudStack follows the below sequence of operations to provide GPU/vGPU support for VMs:
Ensure that XenServer host is ready with GPU installed and configured. For more information, see Citrix 3D Graphics Pack.
Add the host to CloudStack. CloudStack checks if the host is GPU-enabled or not. CloudStack queries the host and detect if it’s GPU enabled.
Create a compute offering with GPU/vGPU support: For more information, see Creating a New Compute Offering..
Continue with any of the following operations:
Deploy a VM.
Deploy a VM with GPU/vGPU support by selecting appropriate Service Offering. CloudStack decide which host to choose for VM deployment based on following criteria:
Migrate a VM.
CloudStack searches for hosts available for VM migration, which satisfies GPU requirement. If the host is available, stop the VM in the current host and perform the VM migration task. If the VM migration is successful, the remaining GPU capacity is updated for both the hosts accordingly.
Destroy a VM.
GPU resources are released automatically when you stop a VM. Once the destroy VM is successful, CloudStack will make a resource call to the host to get the remaining GPU capacity in the card and update the database accordingly.