...
Abiquo stores some information in VMs as metadata and allows users to store custom metadata too. To access metadata, use the link with the "rel" value of "metadata" in the VM.
The Writing metadata will overwrite ALL existing metadata, so the first step is to retrieve the existing metadata in the appropriate format. Abiquo recommends JSON format. Then add new metadata keys and values as required.
Note: Do not use a conversion tool to convert between JSON and XML format because this may produce an incompatible data transfer object.
Always use the existing metadata as the starting point for creating a new object to write. This is because writing metadata will overwrite ALL existing metadata.
| Excerpt | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
For the metadata attribute/object, Abiquo has the reserved keys that are described in the following table.
|
...
| Code Block |
|---|
{
"title": "metadata",
"rel": "metadata",
"type": "application/vnd.abiquo.metadata+json",
"href": "https://mjsabiquo.bcn.abiquo.com:443/api/cloud/virtualdatacenters/2/virtualappliances/2/virtualmachines/24/metadata"
}, |
There is also a metadata attribute in the VM with a null value, but the correct way to access metadata is using the metadata link.
Retrieve existing VM metadata
...
Prepare a VM startup script
The platform will store the VM startup script is stored in the VM metadata under the startup-script key.
Abiquo supports cloud-setup config scripts with cloud-init templates in private cloud, and in public cloud.
To add the startup script to the JSON object, you will need to escape any special characters, such as quotation marks, in the script.
...
| Code Block |
|---|
{
"links": [],
"metadata": {
"monitoring-metrics": [
{
"name": "cpu_time"
},
{
"name": "used_mem"
}
],
"startup-script": "#cloud-config\r\nhostname: \"userdatahostname\"\r\nusers:\r\n - name: \"myuser\"\r\n \t# mkpasswd --method=SHA-512 --rounds=4096 mypass\r\n passwd: \"$6$rounds=4096$aD0didNw/$Pau0z3YK2Ss5MWYoxScEedfMa.1N5qRqK0xYrgs79qdjHdoFUIRmVXpeEewDduSbImu7sqIjSRm40xO6PpJhk/\" \r\n groups:\r\n - \"sudo\"\r\nssh_authorized_keys:\r\n - \"ssh-rsa USER_ID_RSA.PUB\""
}
} |
So that's a wrap! 
...
Access metadata as part of the VM
Here we made a GET request to obtain the VM object and removed the links to make it smaller. The Here, the metadata object is part of the VM but the links list is not shown.
| Code Block |
|---|
{
"id": 24,
"uuid": "2fade39a-fe59-44b4-be3f-b96b63b48153",
"name": "ABQ_2fade39a-fe59-44b4-be3f-b96b63b48153",
"label": "VM_metadata",
"description": "A virtual machine",
"cpu": 1,
"ram": 48,
"vdrpEnabled": true,
"vdrpPort": 0,
"idState": 1,
"state": "NOT_ALLOCATED",
"idType": 0,
"type": "MANAGED",
"highDisponibility": 0,
"password": "uMvMpfyD",
"metadata": {
"monitoring-metrics": [
{
"name": "cpu_time"
},
{
"name": "used_mem"
}
],
"startup-script": "#cloud-config\r\nhostname: \"userdatahostname\"\r\nusers:\r\n - name: \"myuser\"\r\n \t# mkpasswd --method=SHA-512 --rounds=4096 mypass\r\n passwd: \"$6$rounds=4096$aD0didNw/$Pau0z3YK2Ss5MWYoxScEedfMa.1N5qRqK0xYrgs79qdjHdoFUIRmVXpeEewDduSbImu7sqIjSRm40xO6PpJhk/\" \r\n groups:\r\n - \"sudo\"\r\nssh_authorized_keys:\r\n - \"ssh-rsa USER_ID_RSA.PUB\""
},
"monitored": true,
"protected": false,
"variables": {},
"creationTimestamp": 1520865331000,
"backuppolicies": [],
"generateGuestInitialPassword": false,
"natrules": [],
....
}
|
However, So the appropriate most complete and most convenient way to work with VM metadata is using the metadata link!
...
If you ever need to delete the VM metadata, just send a DELETE request to the metadata link. But remember that this request will delete ALL metadata, leaving just the empty links list and the null metadata key, as shown in the first example about where when we retrieved the empty metadata object.
Related links
API references about working with VM metadata:
...