Add language tags to untagged code blocks in aether-help-texts
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
parent
959cc0162c
commit
d22ff57cc7
|
|
@ -875,7 +875,7 @@ Cluster groups directly influence where new instances are created. Understanding
|
|||
|
||||
When creating or moving an instance, you can target a specific cluster group using the `@` prefix. For example, on the command line:
|
||||
|
||||
```
|
||||
```bash
|
||||
`# Launch an instance on any member of the "gpu" group
|
||||
incus launch images:debian/12 my-instance --target=@gpu
|
||||
|
||||
|
|
@ -2182,7 +2182,7 @@ For local storage drivers, the pool must be configured on **each cluster member
|
|||
|
||||
For example, creating a ZFS pool across a three-member cluster via the CLI:
|
||||
|
||||
```
|
||||
```bash
|
||||
`# Step 1: Define per-member configuration
|
||||
incus storage create my-pool zfs source=/dev/sdX size=10GiB --target=server1
|
||||
incus storage create my-pool zfs source=/dev/sdX size=15GiB --target=server2
|
||||
|
|
@ -3648,7 +3648,7 @@ Snapshots capture the state of a volume at a point in time. They are useful for
|
|||
|
||||
Snapshots can be created manually via the CLI:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus storage volume snapshot create <pool> <volume> [<snapshot_name>]`
|
||||
```
|
||||
|
||||
|
|
@ -3679,7 +3679,7 @@ snapshots.pattern = {{ creation_date|date:'2006-01-02_15-04-05' }}`
|
|||
|
||||
To restore a volume to a previous snapshot state:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus storage volume snapshot restore <pool> <volume> <snapshot_name>`
|
||||
```
|
||||
|
||||
|
|
@ -3694,7 +3694,7 @@ To restore a volume to a previous snapshot state:
|
|||
|
||||
Instead of overwriting the current volume, you can restore a snapshot into a brand new volume:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus storage volume copy <pool>/<volume>/<snapshot> <target_pool>/<new_volume>`
|
||||
```
|
||||
|
||||
|
|
@ -3808,7 +3808,7 @@ How volumes behave in a cluster depends on the storage driver:
|
|||
|
||||
Copy a custom volume from one pool to another (or within the same pool with a different name):
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus storage volume copy <source_pool>/<volume> <target_pool>/<new_name>`
|
||||
```
|
||||
|
||||
|
|
@ -3829,7 +3829,7 @@ Flags:
|
|||
#### Move or Rename a Volume
|
||||
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus storage volume move <source_pool>/<volume> <target_pool>/<new_name>`
|
||||
```
|
||||
|
||||
|
|
@ -3850,7 +3850,7 @@ Flags:
|
|||
|
||||
For local storage drivers, you can copy or move volumes between cluster members:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus storage volume copy <pool>/<vol> <pool>/<vol> --target=<source_member> --destination-target=<target_member>`
|
||||
```
|
||||
|
||||
|
|
@ -3865,7 +3865,7 @@ This does not apply to shared drivers (Ceph, CephFS, etc.) where volumes are alr
|
|||
|
||||
Copy or move volumes between completely separate Incus servers:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus storage volume copy <source_remote>:<pool>/<vol> <target_remote>:<pool>/<vol>`
|
||||
```
|
||||
|
||||
|
|
@ -3880,7 +3880,7 @@ Transfer modes via `--mode`: `pull` (default), `push`, or `relay`.
|
|||
|
||||
To move an instance (and its root volume) to a different storage pool:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus move <instance_name> --storage <target_pool>`
|
||||
```
|
||||
|
||||
|
|
@ -3900,7 +3900,7 @@ For offline backup or transfer between environments, you can export volumes to a
|
|||
#### Export a Volume
|
||||
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus storage volume export <pool> <volume> [<output_file>]`
|
||||
```
|
||||
|
||||
|
|
@ -3923,7 +3923,7 @@ Flags:
|
|||
#### Import a Volume
|
||||
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus storage volume import <pool> <file_path> [<volume_name>]`
|
||||
```
|
||||
|
||||
|
|
@ -4351,7 +4351,7 @@ ISO attachment is done from the **Instances** tab. When editing or creating a VM
|
|||
|
||||
Incus CLI equivalent:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus config device add my-vm install-media disk pool=default source=ubuntu-24.04 io.bus=virtio`
|
||||
```
|
||||
|
||||
|
|
@ -4924,7 +4924,7 @@ Before applications can connect to buckets on **local storage pools** (dir, btrf
|
|||
|
||||
This is a server-level configuration done via CLI:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus config set core.storage_buckets_address :8555`
|
||||
```
|
||||
|
||||
|
|
@ -5057,7 +5057,7 @@ After creating a bucket and obtaining your access key and secret key, you can co
|
|||
#### MinIO Client (mc)
|
||||
|
||||
|
||||
```
|
||||
```bash
|
||||
`# Set up a connection alias
|
||||
mc alias set incus https://<server>:8555 <access_key> <secret_key> --api S3v4 --insecure
|
||||
|
||||
|
|
@ -5078,7 +5078,7 @@ mc mirror ./localdir incus/<bucket_name>/`
|
|||
#### AWS CLI
|
||||
|
||||
|
||||
```
|
||||
```bash
|
||||
`# Configure credentials (enter access key, secret key, region: us-east-1)
|
||||
aws configure
|
||||
|
||||
|
|
@ -5099,7 +5099,7 @@ aws --endpoint-url https://<server>:8555 s3 sync ./localdir s3://<bucket_name>/
|
|||
#### s3cmd
|
||||
|
||||
|
||||
```
|
||||
```bash
|
||||
`# Create ~/.s3cfg with:
|
||||
[default]
|
||||
access_key = <access_key>
|
||||
|
|
@ -5121,7 +5121,7 @@ s3cmd get s3://<bucket_name>/myfile.txt`
|
|||
#### rclone
|
||||
|
||||
|
||||
```
|
||||
```bash
|
||||
`# Add to ~/.config/rclone/rclone.conf:
|
||||
[incus]
|
||||
type = s3
|
||||
|
|
@ -5577,7 +5577,7 @@ Devices are identified by their **unique name**. If the same device name appears
|
|||
|
||||
To prevent an instance from inheriting a device from a profile without providing a replacement, you can use a device of type `none` with the same name (via CLI):
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus config device add myinstance eth0 none`
|
||||
```
|
||||
|
||||
|
|
@ -5592,7 +5592,7 @@ The `none` type creates nothing inside the instance — it purely blocks inherit
|
|||
|
||||
To see the final computed configuration after all profile merging and overrides, use the CLI:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus config show <instance> --expanded`
|
||||
```
|
||||
|
||||
|
|
@ -6210,7 +6210,7 @@ Cloud-init is an industry-standard tool for automating the initial setup of clou
|
|||
###### Example: Vendor Data in a Profile
|
||||
|
||||
|
||||
```
|
||||
```yaml
|
||||
`#cloud-config
|
||||
package_upgrade: true
|
||||
packages:
|
||||
|
|
@ -9020,7 +9020,7 @@ This is essential for **multi-user environments** where you want to prevent proj
|
|||
|
||||
**Granular control via CLI:** While AETHER provides the master restricted toggle, individual restriction categories can be fine-tuned via the Incus CLI. For example, you can enable restrictions overall but allow nesting for Docker use cases:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus project set my-project restricted=true
|
||||
incus project set my-project restricted.containers.nesting=allow`
|
||||
```
|
||||
|
|
@ -10360,7 +10360,7 @@ The **Delete** button permanently removes an instance and all its snapshots. Thi
|
|||
|
||||
For critical production instances, you can set `security.protection.delete=true` in the instance configuration. This prevents the instance from being deleted until the protection is explicitly removed. This is configured via the Incus CLI:
|
||||
|
||||
```
|
||||
```bash
|
||||
`incus config set <instance-name> security.protection.delete=true`
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue