|
|
|
@ -2028,7 +2028,7 @@ def cli_vm_snapshot_import(
|
|
|
|
)
|
|
|
|
)
|
|
|
|
def cli_vm_backup():
|
|
|
|
def cli_vm_backup():
|
|
|
|
"""
|
|
|
|
"""
|
|
|
|
DEPRECATED: Use 'pvc vm snapshot' commands instead. 'pvc vm backup' commands will be removed in PVC 0.9.100.
|
|
|
|
DEPRECATED: Use 'pvc vm snapshot' commands instead. 'pvc vm backup' commands will be removed in a future version.
|
|
|
|
|
|
|
|
|
|
|
|
Manage backups of VMs in a PVC cluster.
|
|
|
|
Manage backups of VMs in a PVC cluster.
|
|
|
|
"""
|
|
|
|
"""
|
|
|
|
@ -2059,7 +2059,7 @@ def cli_vm_backup():
|
|
|
|
)
|
|
|
|
)
|
|
|
|
def cli_vm_backup_create(domain, backup_path, incremental_parent, retain_snapshot):
|
|
|
|
def cli_vm_backup_create(domain, backup_path, incremental_parent, retain_snapshot):
|
|
|
|
"""
|
|
|
|
"""
|
|
|
|
DEPRECATED: Use 'pvc vm snapshot' commands instead. 'pvc vm backup' commands will be removed in PVC 0.9.100.
|
|
|
|
DEPRECATED: Use 'pvc vm snapshot' commands instead. 'pvc vm backup' commands will be removed in a future version.
|
|
|
|
|
|
|
|
|
|
|
|
Create a backup of virtual machine DOMAIN to BACKUP_PATH on the cluster primary coordinator. DOMAIN may be a UUID or name.
|
|
|
|
Create a backup of virtual machine DOMAIN to BACKUP_PATH on the cluster primary coordinator. DOMAIN may be a UUID or name.
|
|
|
|
|
|
|
|
|
|
|
|
@ -2107,7 +2107,7 @@ def cli_vm_backup_create(domain, backup_path, incremental_parent, retain_snapsho
|
|
|
|
)
|
|
|
|
)
|
|
|
|
def cli_vm_backup_restore(domain, backup_datestring, backup_path, retain_snapshot):
|
|
|
|
def cli_vm_backup_restore(domain, backup_datestring, backup_path, retain_snapshot):
|
|
|
|
"""
|
|
|
|
"""
|
|
|
|
DEPRECATED: Use 'pvc vm snapshot' commands instead. 'pvc vm backup' commands will be removed in PVC 0.9.100.
|
|
|
|
DEPRECATED: Use 'pvc vm snapshot' commands instead. 'pvc vm backup' commands will be removed in a future version.
|
|
|
|
|
|
|
|
|
|
|
|
Restore the backup BACKUP_DATESTRING of virtual machine DOMAIN stored in BACKUP_PATH on the cluster primary coordinator. DOMAIN may be a UUID or name.
|
|
|
|
Restore the backup BACKUP_DATESTRING of virtual machine DOMAIN stored in BACKUP_PATH on the cluster primary coordinator. DOMAIN may be a UUID or name.
|
|
|
|
|
|
|
|
|
|
|
|
@ -2147,7 +2147,7 @@ def cli_vm_backup_restore(domain, backup_datestring, backup_path, retain_snapsho
|
|
|
|
@click.argument("backup_path")
|
|
|
|
@click.argument("backup_path")
|
|
|
|
def cli_vm_backup_remove(domain, backup_datestring, backup_path):
|
|
|
|
def cli_vm_backup_remove(domain, backup_datestring, backup_path):
|
|
|
|
"""
|
|
|
|
"""
|
|
|
|
DEPRECATED: Use 'pvc vm snapshot' commands instead. 'pvc vm backup' commands will be removed in PVC 0.9.100.
|
|
|
|
DEPRECATED: Use 'pvc vm snapshot' commands instead. 'pvc vm backup' commands will be removed in a future version.
|
|
|
|
|
|
|
|
|
|
|
|
Remove the backup BACKUP_DATESTRING, including snapshots, of virtual machine DOMAIN stored in BACKUP_PATH on the cluster primary coordinator. DOMAIN may be a UUID or name.
|
|
|
|
Remove the backup BACKUP_DATESTRING, including snapshots, of virtual machine DOMAIN stored in BACKUP_PATH on the cluster primary coordinator. DOMAIN may be a UUID or name.
|
|
|
|
|
|
|
|
|
|
|
|
@ -3866,8 +3866,6 @@ def cli_storage_osd_create_db_vg(node, device, wait_flag):
|
|
|
|
Only one OSD database volume group on a single physical device, named "osd-db", is supported per node, so it must be fast and large enough to act as an effective OSD database device for all OSDs on the node. Attempting to add additional database volume groups after the first will result in an error.
|
|
|
|
Only one OSD database volume group on a single physical device, named "osd-db", is supported per node, so it must be fast and large enough to act as an effective OSD database device for all OSDs on the node. Attempting to add additional database volume groups after the first will result in an error.
|
|
|
|
|
|
|
|
|
|
|
|
WARNING: If the OSD database device fails, all OSDs on the node using it will be lost and must be recreated.
|
|
|
|
WARNING: If the OSD database device fails, all OSDs on the node using it will be lost and must be recreated.
|
|
|
|
|
|
|
|
|
|
|
|
A "detect" string is a string in the form "detect:<NAME>:<HUMAN-SIZE>:<ID>". Detect strings allow for automatic determination of Linux block device paths from known basic information about disks by leveraging "lsscsi" on the target host. The "NAME" should be some descriptive identifier, for instance the manufacturer (e.g. "INTEL"), the "HUMAN-SIZE" should be the labeled human-readable size of the device (e.g. "480GB", "1.92TB"), and "ID" specifies the Nth 0-indexed device which matches the "NAME" and "HUMAN-SIZE" values (e.g. "2" would match the third device with the corresponding "NAME" and "HUMAN-SIZE"). When matching against sizes, there is +/- 3% flexibility to account for base-1000 vs. base-1024 differences and rounding errors. The "NAME" may contain whitespace but if so the entire detect string should be quoted, and is case-insensitive. More information about detect strings can be found in the manual.
|
|
|
|
|
|
|
|
"""
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
|
|
|
retcode, retmsg = pvc.lib.storage.ceph_osd_db_vg_add(
|
|
|
|
retcode, retmsg = pvc.lib.storage.ceph_osd_db_vg_add(
|
|
|
|
@ -3936,7 +3934,7 @@ def cli_storage_osd_add(
|
|
|
|
|
|
|
|
|
|
|
|
DEVICE must be a valid block device path (e.g. '/dev/nvme0n1', '/dev/disk/by-path/...') or a "detect" string. Partitions are NOT supported. A "detect" string is a string in the form "detect:<NAME>:<HUMAN-SIZE>:<ID>". The path or detect string must be valid on the current node housing the OSD.
|
|
|
|
DEVICE must be a valid block device path (e.g. '/dev/nvme0n1', '/dev/disk/by-path/...') or a "detect" string. Partitions are NOT supported. A "detect" string is a string in the form "detect:<NAME>:<HUMAN-SIZE>:<ID>". The path or detect string must be valid on the current node housing the OSD.
|
|
|
|
|
|
|
|
|
|
|
|
A "detect" string is a string in the form "detect:<NAME>:<HUMAN-SIZE>:<ID>". Detect strings allow for automatic determination of Linux block device paths from known basic information about disks by leveraging "lsscsi" on the target host. The "NAME" should be some descriptive identifier, for instance the manufacturer (e.g. "INTEL"), the "HUMAN-SIZE" should be the labeled human-readable size of the device (e.g. "480GB", "1.92TB"), and "ID" specifies the Nth 0-indexed device which matches the "NAME" and "HUMAN-SIZE" values (e.g. "2" would match the third device with the corresponding "NAME" and "HUMAN-SIZE"). When matching against sizes, there is +/- 3% flexibility to account for base-1000 vs. base-1024 differences and rounding errors. The "NAME" may contain whitespace but if so the entire detect string should be quoted, and is case-insensitive. More information about detect strings can be found in the pvcbootstrapd manual.
|
|
|
|
A "detect" string is a string in the form "detect:<NAME>:<HUMAN-SIZE>:<ID>". Detect strings allow for automatic determination of Linux block device paths from known basic information about disks by leveraging "lsscsi"/"nvme" on the target host. The "NAME" should be some descriptive identifier that would be part of the device's Model information, for instance the manufacturer (e.g. "INTEL") or a similar unique string (e.g. "BOSS" for Dell BOSS cards); the "HUMAN-SIZE" should be the labeled human-readable size of the device (e.g. "480GB", "1.92TB"); and "ID" specifies the Nth 0-indexed device which matches the "NAME" and "HUMAN-SIZE" values (e.g. "2" would match the third device with the corresponding "NAME" and "HUMAN-SIZE"). When matching against sizes, there is +/- 3% flexibility to account for base-1000 vs. base-1024 differences and rounding errors. The "NAME" may contain whitespace but if so the entire detect string should be quoted, and is case-insensitive. More information about detect strings can be found in the pvcbootstrapd manual.
|
|
|
|
|
|
|
|
|
|
|
|
The weight of an OSD should reflect the ratio of the size of the OSD to the other OSDs in the storage cluster. For example, with a 200GB disk and a 400GB disk in each node, the 400GB disk should have twice the weight as the 200GB disk. For more information about CRUSH weights, please see the Ceph documentation.
|
|
|
|
The weight of an OSD should reflect the ratio of the size of the OSD to the other OSDs in the storage cluster. For example, with a 200GB disk and a 400GB disk in each node, the 400GB disk should have twice the weight as the 200GB disk. For more information about CRUSH weights, please see the Ceph documentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
