mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 19:02:31 +00:00
docs: review disk manager documentation in all seven translations
This commit is contained in:
Jonatan
@@ -20,7 +20,7 @@
|
||||
},
|
||||
"iommu": {
|
||||
"heading": "IOMMU groups — why the whole card leaves at once",
|
||||
"body": "PCI passthrough is done per <strong>IOMMU group</strong>, which is the smallest unit the CPU's IOMMU can isolate. Everything inside a group moves together. If your SATA controller shares its IOMMU group with the USB controller, passing the SATA card to a VM also takes the USB ports with it — often undesirable.",
|
||||
"body": "The isolation boundary for PCI passthrough is the <strong>IOMMU group</strong>, the smallest unit the CPU’s IOMMU can isolate. Devices in the same group cannot be isolated from each other. If a SATA controller shares its group with a USB controller, passing through SATA may also require releasing USB from the host, or may prevent passthrough. It does not automatically assign every device in the group to the VM.",
|
||||
"outro": "ProxMenux shows the IOMMU group next to each device and warns you when a group carries more than just the controller you want. You can still proceed if the extra devices in the group are acceptable (all disk controllers, for example), or back out if they are not."
|
||||
},
|
||||
"prereqs": {
|
||||
@@ -97,7 +97,7 @@
|
||||
"busyBody": "Another process still holds the PCI device. Most common causes: a previous VM that crashed without releasing it, or the host kernel reclaimed it on the last boot. Run <code>lspci -nnk -s <addr></code> to see which driver is bound; it should be <code>vfio-pci</code>. A full host reboot usually clears this.",
|
||||
"noDisksTitle": "Guest sees the controller but not the disks",
|
||||
"noDisksBody": "The controller model lacks an in-guest driver. Linux almost never hits this; Windows does — install the vendor driver (e.g. LSI / Broadcom for older SAS HBAs) while the card is detached, then reboot with the card attached.",
|
||||
"sharedTitle": "Shared IOMMU group also exports an unrelated device",
|
||||
"sharedTitle": "The IOMMU group includes an unrelated device",
|
||||
"sharedBody": "Options: (a) move the card to a different PCIe slot to change its group, (b) enable <em>ACS override</em> in the kernel to split groups (security trade-off — research before applying), or (c) pick a different card in a cleaner group."
|
||||
},
|
||||
"related": {
|
||||
|
||||
@@ -46,19 +46,19 @@
|
||||
"mode": "1. Wipe all",
|
||||
"part": "Destroyed",
|
||||
"data": "Signatures wiped",
|
||||
"useCase": "Starting fresh: everything on the disk goes, ready for a new layout."
|
||||
"useCase": "Remove partitioning and metadata to prepare a new layout. This does not overwrite all user data."
|
||||
},
|
||||
{
|
||||
"mode": "2. Remove FS labels",
|
||||
"part": "Preserved",
|
||||
"data": "Preserved",
|
||||
"useCase": "Clears stale ZFS / LVM / RAID signatures so the disk stops being auto-claimed, without touching the data."
|
||||
"useCase": "Removes stale ZFS / LVM / RAID signatures so the disk is no longer auto-claimed. Bulk user data is not overwritten, but removing signatures can make it inaccessible."
|
||||
},
|
||||
{
|
||||
"mode": "3. Zero all data",
|
||||
"part": "Preserved",
|
||||
"data": "Destroyed (zeroed)",
|
||||
"useCase": "Sanitise before handing the disk over, keeping the existing partition layout."
|
||||
"useCase": "Overwrite the existing partitions with zeros while keeping the partition table. Unallocated space and SSD spare areas are not covered; this is not a complete device sanitization guarantee."
|
||||
},
|
||||
{
|
||||
"mode": "4. Full format",
|
||||
|
||||
@@ -52,7 +52,7 @@
|
||||
"intro": "For every selected image ProxMenux asks:",
|
||||
"items": [
|
||||
"<strong>Interface</strong> — <code>scsi</code> (default), <code>virtio</code>, <code>sata</code> or <code>ide</code>. Matches how the guest will see the disk.",
|
||||
"<strong>SSD emulation</strong> — only offered for non-VirtIO interfaces. Adds <code>ssd=1</code> so the guest advertises the disk as solid-state (useful for OS-level TRIM / alignment).",
|
||||
"<strong>SSD emulation</strong> — only offered for non-VirtIO interfaces. Adds <code>ssd=1</code> so the guest recognizes a solid-state disk. Discard/TRIM support must be configured separately.",
|
||||
"<strong>Bootable</strong> — if yes, ProxMenux adds the disk to the boot order so it becomes the primary boot device of the VM."
|
||||
]
|
||||
},
|
||||
@@ -73,7 +73,7 @@
|
||||
"noImagesTitle": "\"No compatible disk images found\"",
|
||||
"noImagesBody": "The script scanned the directory but found no <code>.img</code> / <code>.qcow2</code> / <code>.vmdk</code> / <code>.raw</code> file. Check the extension (case matters), that the file sits directly in the selected directory (no sub-directories are searched) and that permissions allow root to read it.",
|
||||
"slowTitle": "Import is slow",
|
||||
"slowBody": "VMDK → QCOW2 → raw conversions are CPU- and I/O-bound. Import speed depends on the source read speed, the target storage write speed and CPU for decompression. Prefer raw or qcow2 sources when possible.",
|
||||
"slowBody": "Conversions between VMDK, QCOW2 and raw can be limited by CPU and I/O. Import speed depends on source reads, target writes and any decompression work. Prefer raw or qcow2 sources when possible.",
|
||||
"uefiTitle": "Imported disk boots into UEFI shell",
|
||||
"uefiBody": "The image was built for legacy (SeaBIOS) but the VM uses OVMF (or vice versa). Either switch the VM's BIOS in Proxmox to match the image, or rebuild the image in the correct mode before importing."
|
||||
},
|
||||
|
||||
@@ -27,7 +27,7 @@
|
||||
"At least one physical disk not in use by the host or any other guest."
|
||||
],
|
||||
"warnTitle": "Privileged container required",
|
||||
"warnBody": "Direct device passthrough to an LXC container only works if the container is <strong>privileged</strong>. If the script detects <code>unprivileged: 1</code> in the config it offers to convert it in place (edits <code>/etc/pve/lxc/<CTID>.conf</code>). Cancel if you cannot accept the security trade-off of a privileged container."
|
||||
"warnBody": "This script requires a <strong>privileged</strong> container for its direct disk attachment. If it detects <code>unprivileged: 1</code>, it offers to edit <code>/etc/pve/lxc/<CTID>.conf</code> in place. This changes the security model and does not remap existing file ownership. Back up the container and verify ownership before accepting, or rebuild it as privileged."
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Step-by-step",
|
||||
@@ -83,9 +83,9 @@
|
||||
"troubleshoot": {
|
||||
"heading": "Troubleshooting",
|
||||
"unprivTitle": "\"Cannot continue with an unprivileged container\"",
|
||||
"unprivBody": "You declined the conversion offer. Either re-run and accept the conversion, or convert the container manually by editing <code>/etc/pve/lxc/<CTID>.conf</code> and replacing <code>unprivileged: 1</code> with <code>unprivileged: 0</code>. You can also rebuild the container as privileged if you prefer not to convert in place.",
|
||||
"unprivBody": "You declined the conversion. The flag in <code>/etc/pve/lxc/<CTID>.conf</code> changes from <code>unprivileged: 1</code> to <code>unprivileged: 0</code>, but that alone does not convert existing UID/GID ownership. Back up and handle the ownership mapping before accepting an in-place conversion; alternatively restore or rebuild the container as privileged.",
|
||||
"permsTitle": "Permissions inside the container are wrong",
|
||||
"permsBody": "Mounts from the host into a privileged container land as <code>root:root</code>. If the service inside the CT runs as a different user (e.g. <code>www-data</code> for Nextcloud), <code>chown</code>/<code>chmod</code> inside the container to match its UID/GID after the first mount."
|
||||
"permsBody": "Existing file ownership is retained when a partition is mounted into a privileged container; a newly formatted filesystem is often owned by <code>root:root</code>. If the service runs as another user (e.g. <code>www-data</code> for Nextcloud), inspect its UID/GID and adjust the required files with <code>chown</code>/<code>chmod</code>. Changes also affect the underlying disk."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "What this does",
|
||||
"body": "This is a raw-disk passthrough: the guest OS sees the drive as a real block device (with its SMART data and native geometry). The disk is attached via its <code>/dev/disk/by-id/…</code> path — not <code>/dev/sdX</code> — so the assignment does not break if disk controllers enumerate devices in a different order on the next boot."
|
||||
"body": "This attaches a raw physical disk as the backing device for a virtual disk interface. The guest does not automatically receive native SMART data or the physical controller’s features; use controller PCI passthrough when those are required. The disk is attached through <code>/dev/disk/by-id/…</code>, not <code>/dev/sdX</code>, so a changed device enumeration order at boot does not break the assignment."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "How the script runs",
|
||||
@@ -49,7 +49,7 @@
|
||||
"items": [
|
||||
"<strong>SCSI</strong> — modern default for Linux and Windows with VirtIO-SCSI drivers installed.",
|
||||
"<strong>SATA</strong> — broad compatibility, works out of the box on virtually every guest.",
|
||||
"<strong>VirtIO</strong> — paravirtualised block device, fastest but requires guest drivers.",
|
||||
"<strong>VirtIO</strong> — efficient paravirtualised block device; requires guest drivers.",
|
||||
"<strong>IDE</strong> — for legacy guests that lack any of the above drivers."
|
||||
]
|
||||
},
|
||||
@@ -63,7 +63,7 @@
|
||||
"heading": "Manual equivalent",
|
||||
"body": "The script is a wrapper around <code>qm set</code>. The exact command for a single disk looks like this:",
|
||||
"migrationTitle": "Live migration is not possible",
|
||||
"migrationBody": "A VM with a passthrough disk is <strong>tied to the host that exposes that disk</strong>. Live migration to another Proxmox node will fail because the target node does not see the same <code>/dev/disk/by-id/…</code> path. Use replication or backup/restore instead, or pick virtual disks on shared storage if you need mobility.",
|
||||
"migrationBody": "A VM with a physical passthrough disk is <strong>tied to the host that exposes that disk</strong>. Another node normally lacks the same <code>/dev/disk/by-id/…</code> path and disk data. Back up and transfer that data separately, or use managed virtual disks on shared or supported replicated storage for mobility; do not assume Proxmox storage replication covers this device.",
|
||||
"shareTitle": "Do not share a physical disk between VMs",
|
||||
"shareBody": "Attaching the same physical disk to two VMs at the same time will corrupt data on next write. ProxMenux detects this situation and blocks it, but if you bypass the script (direct <code>qm set</code>), make sure only one guest ever mounts the disk."
|
||||
},
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox Disk Manager — Attach Disks to VMs / LXC, SMART Tests, Wipe | ProxMenux",
|
||||
"description": "Manage physical disks on a Proxmox VE host with ProxMenux: pass disks through to VMs or LXC containers (qm set scsi/sata/virtio, pct mp), import qcow2 / vmdk / vdi disk images, pass through whole HBAs or NVMe controllers, safely wipe disks and run SMART self-tests.",
|
||||
"description": "Manage physical disks on a Proxmox VE host with ProxMenux: attach disks to VMs or LXC containers (qm set scsi/sata/virtio, pct mp), import img / qcow2 / vmdk / raw disk images, pass through whole HBAs or NVMe controllers, wipe disks with safety checks and run SMART self-tests.",
|
||||
"ogTitle": "Proxmox Disk Manager — Attach Disks to VMs / LXC, SMART Tests, Wipe",
|
||||
"ogDescription": "Attach disks to VMs / LXC, import disk images, PCI passthrough for controllers, safe wipe and SMART tests on Proxmox VE.",
|
||||
"twitterTitle": "Proxmox Disk Manager | ProxMenux",
|
||||
@@ -14,7 +14,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "What this menu is for",
|
||||
"body": "Every option here operates on <strong>physical disks already visible to the Proxmox host</strong>. The menu is split in three groups — <strong>VM</strong> (attach disks or import images into a virtual machine), <strong>LXC</strong> (attach disks to a container), and <strong>Utilities</strong> (safe format, SMART health). Safety checks apply everywhere: system disks and disks already in use are hidden or blocked."
|
||||
"body": "These tools work with <strong>physical disks visible to the Proxmox host and image files stored on it</strong>. The menu has three groups: <strong>VM</strong> (attach disks or import images), <strong>LXC</strong> (attach disks to a container), and <strong>Utilities</strong> (formatting and SMART health). Attachment and wipe operations hide or block system disks and disks already in use; SMART checks can inspect those disks without wiping them."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Opening the menu",
|
||||
@@ -32,7 +32,7 @@
|
||||
"Add Controller or NVMe to VM"
|
||||
],
|
||||
"lxcTitle": "LXC",
|
||||
"lxcBody": "Tools that operate on existing containers. Direct device passthrough needs a privileged container; the script offers to convert it if necessary.",
|
||||
"lxcBody": "Tools for existing LXC containers. This script requires a privileged container and offers to change the flag when needed. Read the conversion and file-ownership cautions on the tool page first.",
|
||||
"lxcItems": [
|
||||
"Import Disk to LXC"
|
||||
],
|
||||
@@ -69,7 +69,7 @@
|
||||
},
|
||||
"lxc": {
|
||||
"heading": "LXC",
|
||||
"intro": "Tools that operate on existing LXC containers. Direct device passthrough requires a privileged container; the script offers to convert the container if needed.",
|
||||
"intro": "Tools for existing LXC containers. This script requires a privileged container and offers to change the flag when needed. Read the conversion and file-ownership cautions on the tool page first.",
|
||||
"options": [
|
||||
{
|
||||
"icon": "Boxes",
|
||||
@@ -98,8 +98,8 @@
|
||||
]
|
||||
},
|
||||
"safety": {
|
||||
"title": "Safety rules shared by every option",
|
||||
"intro": "ProxMenux filters out anything that could harm the host:",
|
||||
"title": "Safety rules for disk attachment and wiping",
|
||||
"intro": "Attachment and wipe operations filter out devices that could harm the host:",
|
||||
"items": [
|
||||
"The <strong>system disk</strong> (root pool, swap, active ZFS / LVM / RAID members) is always hidden.",
|
||||
"Disks <strong>mounted</strong> anywhere on the host are hidden or blocked at execution.",
|
||||
|
||||
@@ -55,11 +55,11 @@
|
||||
}
|
||||
],
|
||||
"tipTitle": "Long tests survive terminal close",
|
||||
"tipBody": "A long test is queued <em>inside the drive</em> — it does not depend on the ProxMenux process staying alive. You can close the terminal, reboot the Proxmox host (the test picks up where it left off on some drives) or just come back later and use <strong>Check test progress</strong> to see the result."
|
||||
"tipBody": "A long test runs <em>inside the drive</em> and does not depend on the ProxMenux process staying alive. You can close the terminal and return later to <strong>Check test progress</strong>. A host reboot, controller reset or power loss may interrupt the test and its result collector; do not assume it will resume automatically."
|
||||
},
|
||||
"json": {
|
||||
"heading": "JSON export for the Monitor",
|
||||
"intro": "Every run writes a timestamped JSON file to <code>/usr/local/share/proxmenux/smart/<disk>/</code>. The structure is:",
|
||||
"intro": "Status, short-test and progress actions write a timestamped JSON file to <code>/usr/local/share/proxmenux/smart/<disk>/</code>; long-test results are collected in the background. The full-report action only displays its report. The structure is:",
|
||||
"outro": "The ProxMenux Monitor picks these up to render health trends per disk; old files are rotated out automatically once the retention limit is reached."
|
||||
},
|
||||
"steps": {
|
||||
@@ -89,7 +89,7 @@
|
||||
},
|
||||
{
|
||||
"title": "Review results",
|
||||
"bodyRich": "Status and report are printed to the terminal and written to JSON. For long tests, return later and run <strong>Check test progress</strong> on the same disk to see the outcome.",
|
||||
"bodyRich": "Status and reports are shown in the terminal; JSON export is performed for supported actions as described above, not for Full report. For long tests, return later and run <strong>Check test progress</strong> on the same disk to see the outcome.",
|
||||
"img": "/disk/smart/quick-status.png",
|
||||
"alt": "Quick health status output",
|
||||
"caption": "Quick health status output (SATA — smartctl -H + -A)"
|
||||
@@ -106,7 +106,7 @@
|
||||
"noSmartTitle": "\"Could not read SMART data from /dev/sdX\"",
|
||||
"noSmartBody": "The disk is probably behind a RAID / SAS controller that does not pass SMART through. With megaraid-based cards, try <code>smartctl -d megaraid,N /dev/sdX</code>. For HBAs in IT mode the direct invocation works.",
|
||||
"longTitle": "Long test never completes",
|
||||
"longBody": "The test is queued on the drive firmware and pauses if the disk is under heavy load. Running it overnight on an idle system usually works. You can also check <code>smartctl -c</code> to see percentage remaining; if it is stuck at a fixed LBA, the disk is failing at that sector."
|
||||
"longBody": "The drive runs the test in firmware, and heavy I/O can delay completion. Try an idle period such as overnight. For SATA/SAS, <code>smartctl -c</code> shows the remaining percentage; inspect the self-test log for completion status and any failing LBA. A reported read failure needs investigation; slow progress alone does not prove a bad sector."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
@@ -124,7 +124,7 @@
|
||||
{
|
||||
"href": "/docs/help-info/zfs-commands",
|
||||
"label": "ZFS Management commands",
|
||||
"tail": " — zpool scrub for the storage-layer equivalent of SMART tests."
|
||||
"tail": " — zpool scrub verifies ZFS data checksums and complements hardware SMART tests."
|
||||
},
|
||||
{
|
||||
"href": "/docs/monitor/dashboard/storage",
|
||||
|
||||
Reference in New Issue
Block a user