# Virtuozzo
## Overview
Storware Backup & Recovery supports backup for Virtuozzo using the following strategy:
Disk attachment
* proxy VM installed in each AZ
* volume data transferred via cinder-based disk attachment
### Backup strategies
#### Disk Attachment
Storware Backup and Recovery supports the **disk attachment method** using Virtuozzo APIs, enabling backup of environments with API-managed storage (e.g., Ceph RBD or other compatible backends).
This approach allows Storware to attach volumes to the node (acting as a proxy) and perform backups directly from mounted disks. It is particularly useful in environments where direct hypervisor access is limited.
**Incremental backup** is supported using Storware Generic Incremental.
#### Backup Process
The disk attachment backup workflow includes:
* A **crash-consistent snapshot** created via Virtuozzo API
* Optional **application-consistent backup** using pre/post snapshot command execution
* **Metadata export** from Virtuozzo APIs
* Volumes created from snapshots are **attached one by one** to the Storware node
* Data is read directly from the attached volumes
If the virtual machine is based on an image and the **“download image”** option is enabled:
* Data is retrieved directly via API
* The VM is recreated based on metadata and downloaded images
### **Supported features**
**Supported backup strategies:** Disk attachment
| | Disk attachment |
| ------------------------------------------------------------------- | ------------------------- |
| Supported versions | 7.0, 7.1, 7.2 |
| The last snapshot is kept on the hypervisor for incremental backups | Yes |
| Access to hypervisor OS required | No |
| Proxy VM required | Yes |
| Full backup | Supported |
| Incremental backup | Supported \* |
| Restore | Supported |
| File-level restore | Supported |
| VM disk exclusion | Supported |
| Quiesced snapshots | Supported \*\* |
| Snapshots management | Supported \*\*\* |
| Pre/post command execution | Supported |
| Access to VM disk backup over iSCSI | Supported |
| VM name-based policy assignment | Supported |
| VM tag-based policy assignment | Supported |
| Power-on VM after restore | Not Supported (always on) |
*\* Ceph RBD volumes only*\
\&#xNAN;*\*\* Hypervisor dependent*\
\&#xNAN;*\*\*\* Without snapshot revert*
### Network requirements
#### Disk attachment
**Connection URL:** `https://KEYSTONE_HOST:5000/v3`
| Source | Destination | Ports | Description |
| ------ | --------------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Node | Keystone, Nova, Glance, Cinder, Neutron | ports that were defined in endpoints for Virtuozzo services | API access to the Virtuozzo management services - using endpoint type that has been specified in hypervisor manager details |
| Node | Ceph monitors | 3300/tcp, 6789/tcp | if Ceph RBD is used as the backend storage - used to collect changed-blocks lists from Ceph |
#### Disk attachment
**Connection URL:** `https://KEYSTONE_HOST:5000/v3`
| Source | Destination | Ports | Description |
| ------ | --------------------------------------- | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| Node | Keystone, Nova, Glance, Cinder, Neutron | ports that were defined in endpoints for Virtuozzok services | API access to the OpenStack management services - using endpoint type that has been specified in hypervisor manager details |
## General configuration
1. Go the **Virtual Environments -> Virtualization Providers** and click **Create**
2. Select **Virtuozzo**
3. In the **General** tab:
1. **Node configuration**\
For the nodes communicating with Virtuozzo
2. **URL**\
Keystone API URL, e.g. `https://10.201.32.40:5000/v3`
3. **Region**\
Provide the name of your region (each region must be added as a separate hypervisor manager
4. **Trust certificates**\
If you're using certificates that may not be trusted by you nodes - e.g. self-signed - you can enable this toggle. By default they will be imported automatically when connecting for the first time anyway.
4. In the **Virtuozzo settings** tab:
1. **Endpoint interface type**\
**I**nterface type used to connect to the OpenStack services' endpoints returned from your Keystone
2. **Download image from glance:**
1. when enabled - this setting **only applies when OS (boot) volume is either:**
1. **nova volume**
2. **cinder volume from image**
2. the image will be downloaded **only if the OS (boot) volume is not excluded**.
3. this setting will **download the OS image from glance** instead of the OS (boot) volume
4. this means that **changes applied to the OS (boot) volume will be discarded**, and the original glance image (the one used to create the instance, and in the resulting backup) will be later used for recovery
5. this may be useful for a disk-attachment strategy (**where nova volumes are not supported**), and you still need to recover the instance to another OpenStack, where this image doesn't exist.
5. In the **Authentication domain** tabs
1. **Name**\
Name of domain
2. **User**\
OpenStack user
3. **Default project**\
Name of default project in the domain being defined
4. **DomainI ID** -\
Optional domain ID
5. **Password**\
OpenStack user password
6. Save and **run first inventory sync**
7. When your environment uses an **NFS storage backend**, make sure to enable QCOW2 file support. Otherwise, backup snapshots will create RAW files (instead of QCOW2):
1. it's recommended to set these values in `/etc/cinder/cinder.conf`:
Copy
```
default_volume_type = nfs
nfs_sparsed_volumes = true
nfs_qcow2_volumes = true
volume_driver = cinder.volume.drivers.nfs.NfsDriver
enabled_backends = nfs
```
8. Run both full and incremental backups to verify the setup.
## Virtuozzo Access Keys
During Inventory Synchronization, Storware Backup & Recovery scans all Keypairs (to which a user has access) and stores them as Access Keys. When restoring an instance, the user can specify the Access Key.
{% hint style="info" %}
**Note:** If the access key selected for restore is no longer present in the Virtuozzo environment, it will be restored.
{% endhint %}
## Virtuozzo Flavor
During Inventory Synchronization, Storware Backup & Recovery scans all Flavors and saves their configuration. When restoring an instance, the user can specify the flavor.
{% hint style="info" %}
**Note:** If the flavor selected for restore is no longer present in the Virtuozzo environment, it will be restored with the same configuration and availability as the original flavor.
{% endhint %}
## Limitations
* Storware Backup & Recovery does not backup and restores keypairs that user used in Storware Backup & Recovery doesn't have access to. The restored instance will have no keypairs assigned. In such a case, the keypairs have to be backed up and restored manually under the same name before restoring the instance.
* Only QCOW2/RAW files are supported as the backend.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.storware.eu/protecting-virtual-machines/virtual-machines/virtuozzo.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.