ខ្សែសង្វាក់រូបថតម៉ាស៊ីននិម្មិតដែលខូច (.VMDK / .VHDX / .QCOW2) និងការសង្គ្រោះថាស¶

នៅពេលដែលការផលិតម៉ាស៊ីននិម្មិត (VM) នៅលើ VMware ESXi / Workstation, Microsoft Hyper-V, Proxmox VE / QEMU-KVM, ឬ Oracle VirtualBox ស្រាប់តែបដិសេធមិនបើកដំណើរការបន្ទាប់ពីការងារបម្រុងទុកបរាជ័យ ឃ្លាំងទិន្នន័យនឹងអស់ទំហំថាស (0 bytes free) ឬអ្នកគ្រប់គ្រងប៉ះឯកសាររូបថត ការចុចភ័យស្លន់ស្លោតែមួយអាចលុបទិន្នន័យអាជីវកម្មបន្តផ្ទាល់ជាច្រើនខែ ឬច្រើនឆ្នាំ។ រូបថតម៉ាស៊ីននិម្មិតគឺ មិនមែនជាការបម្រុងទុកឯករាជ្យពេញលេញ; ពួកវាមានភាពផុយស្រួយ ** ចម្លងលើការសរសេរ (CoW) ខ្សែសង្វាក់ delta ខុសគ្នា ** (*-000001-delta.vmdk, *.avhdxឬឯកសារបម្រុងទុក .qcow2 overlays) ដែលរាល់ប្លុកនីមួយៗដែលបានសរសេរចាប់តាំងពីរូបថតនោះត្រូវបានថតយកជីវិតទាំងស្រុងនៅក្នុងឯកសារ delta របស់កុមារ ខណៈដែលថាសមូលដ្ឋានដើមបានជាប់គាំងកាលពីអតីតកាល។

ប្រសិនបើអ្នកឃើញកំហុសដូច "The parent virtual disk has been modified since the child was created (Parent CID does not match)" នៅក្នុង VMware, "Cannot boot: The chain of virtual hard disks is broken" នៅក្នុង Hyper-V ឬ "Could not open backing file: L1/L2 table corrupted" នៅក្នុង QEMU/Proxmox ** ចង្អុល VM ឡើងវិញដោយផ្ទាល់នៅ Base Disk (flat.vmdk ឬមូលដ្ឋាន .vhdx) ហើយ​ការ​បើក​វា​ឡើង​គឺ​ស្លាប់ ** ។ ការធ្វើដូច្នេះចាប់ផ្តើមម៉ាស៊ីនមេដូចដែលវាមានកាលពី 6 ខែមុន នៅពេលដែលរូបថតដំបូងត្រូវបានបង្កើត ** ធ្វើឱ្យតំណភ្ជាប់ GUID/CID ឪពុកម្តាយកូនមានសុពលភាពភ្លាមៗ ហើយបង្ហាញរាល់រូបថតដីសណ្តរចាប់តាំងពីកាលបរិច្ឆេទនោះ កំព្រា និងមិនអាចបញ្ចូលគ្នាបាន ** ។

មគ្គុទ្ទេសក៍នេះផ្តល់នូវការស្ថាបនាឡើងវិញនូវខ្សែសង្វាក់រូបថតដែលមិនបំផ្លិចបំផ្លាញមួយជំហានម្តង ៗ ការជួសជុលបឋមកថាឯកសារពិពណ៌នា និងពិធីការទាញយកឯកសារភ្ញៀវក្រៅក្រុមដោយផ្អែកលើ VMware ដោយ Broadcom Knowledge Base Articles (KB 1007969 / 316578 និង KB 1002511), Microsoft Hyper-V Merge-VHD និង Set-VHD លក្ខណៈបច្ចេកទេស, QEMU qemu-img និង libguestfs (guestmount) ស្តង់ដារកោសល្យវិច្ច័យ និងការបោះពុម្ពពិសេស NIST 800-86 ។

ធ្វើដូចនេះឥឡូវនេះ¶

ប្រសិនបើម៉ាស៊ីននិម្មិតបដិសេធមិនចាប់ផ្តើម ឬបោះខ្សែសង្វាក់រូបថតដែលខូច / កំហុសថាសនិម្មិតដែលខូច៖

1. NEVER edit the VM settings to boot directly from the Base Disk (Server.vmdk ឬ Server.vhdx) when delta snapshots (-000001.vmdk ឬ .avhdx) exist in the folder. The moment a guest operating system boots directly off the base parent disk for even 2 seconds, the guest OS writes boot timestamps and NTFS/ext4 journal updates into the base disk, modifying the parent disk's Content ID (CID) in VMware or Linkage GUID / Timestamp in Hyper-V. That single boot breaks the entire chain of child snapshots that depend on the base disk staying bit-for-bit frozen. If your server room is experiencing an active fire, cooling failure, or physical hazard, evacuate and call your local emergency number (911 in the United States and Canada, 112 across the European Union, 999 in the United Kingdom) or check លេខសង្គ្រោះបន្ទាន់.
2. NEVER delete .avhdx, -delta.vmdk, ឬ -sesparse.vmdk files in Windows Explorer or the ESXi Datastore Browser to "free up disk space." Unlike normal temporary files, .avhdx និង -delta.vmdk files ARE your current live hard drive. If a snapshot was created 8 months ago by a stuck Veeam/CommVault backup job and left running, 100 percent of every database transaction, invoice, and file created during the last 8 months is stored inside those .avhdx ឬ -delta.vmdk files. Deleting them deletes all data created since the snapshot started.
3. Copy or clone all .vmdk, .vhdx/.avhdx, ឬ .qcow2 files to an external / secondary storage volume BEFORE running any merge, commit, or repair command. Merging a snapshot chain writes all delta blocks backward into the parent disk in-place. If a merge fails halfway through due to a bad disk sector or datastore full error, both the parent and child disks are corrupted unless you took a raw file copy first.
4. If the hypervisor failed because the host Datastore / Volume hit 100% Full (No space left on device), NEVER try to "Delete / Consolidate Snapshots" until you add free space or clone to a larger datastore. Consolidating a multi-snapshot chain requires temporary scratch space equal to the size of the largest delta disk. Attempting to consolidate on a 99% full datastore will crash the hypervisor mid-commit.
5. Map the exact Parent -> Child dependency chain using read-only inspection commands (vmkfstools -e, Get-VHD, ឬ qemu-img info --backing-chain) before touching a single byte. Every snapshot file header explicitly names the exact parent filename and parent cryptographic ID it expects to sit directly above it.

flowchart TD
    A["VM Refuses to Boot: Broken Snapshot Chain, Parent CID Mismatch, or Corrupt VMDK/VHDX/QCOW2"] --> B["STOP: Do NOT boot the base disk directly, and do NOT delete any -delta.vmdk or .avhdx files"]
    B --> C["Step 1: Check Host Datastore / Volume Free Space (`df -h` / `esxcli storage filesystem list`)"]
    C --> D["Step 2: Copy all base and snapshot files to a secondary backup NAS/SAN/USB drive before modifying"]
    D --> E{"Which Hypervisor / Virtual Disk Format is affected?"}
    E -->|"1. VMware ESXi / Workstation (.vmdk / -flat.vmdk / -delta.vmdk / -sesparse.vmdk)"| F["Inspect text descriptors (`cat *.vmdk`) & check chain (`vmkfstools -e Server-000002.vmdk`)"]
    F --> G{"What is the VMware VMDK fault?"}
    G -->|"Parent CID Mismatch (`parentCID .= CID of parent`)"| H["Edit child text descriptor `.vmdk` so `parentCID` matches parent's `CID`, OR clone active leaf disk to a new consolidated VMDK (`vmkfstools -i`)"]
    G -->|"Missing 1-KB text descriptor `.vmdk` (Only huge `-flat.vmdk` exists)"| I["Calculate exact byte size / 512 sectors and recreate the plain-text `.vmdk` descriptor with `vmkfstools -c`"]
    E -->|"2. Microsoft Hyper-V (.vhdx and .avhdx chain)"| J["Inspect chain from newest `.avhdx` upward: `Get-VHD -Path *.avhdx | Select Path,ParentPath`"]
    J --> K["Relink broken parent pointer (`Set-VHD -Path child.avhdx -ParentPath parent.vhdx -IgnoreIdMismatch`) or offline merge (`Merge-VHD`)"]
    E -->|"3. Proxmox / KVM / QEMU (.qcow2) or VirtualBox (.vdi)"| L["Check `qemu-img info --backing-chain`; repair refcount/L2 tables (`qemu-img check -r all`) or rebase (`qemu-img rebase -u`)"]
    H --> M["Out-of-Band File Rescue Fallback: Mount any chain directly in Read-Only mode via `guestmount --ro` or `7-Zip` / `UFS Explorer`"]
    I --> M
    K --> M
    L --> M

Understanding how virtual machine snapshot chains actually work¶

Whether you run VMware ESXi, Microsoft Hyper-V, Proxmox/KVM, or VirtualBox, every hypervisor implements snapshots using the exact same fundamental architecture: a unidirectional linked list of Read-Only Parent Disks and a Read-Write Child Leaf Delta Disk.

[Base Disk: Server.vmdk / Server.vhdx]  <-- Frozen Read-Only at Snapshot 1 (e.g., Jan 1)
         ^
         | (Points to Parent Path + Parent CID/GUID: 1234abcd)
[Snapshot 1: Server-000001.vmdk / Server_A.avhdx]  <-- Frozen Read-Only at Snapshot 2 (e.g., June 1)
         ^
         | (Points to Parent Path + Parent CID/GUID: 5678ef01)
[Snapshot 2 (Active Leaf): Server-000002.vmdk / Server_B.avhdx]  <-- Active Read/Write Today (Oct 31)

• When the VM wants to write a new block today, it writes ONLY to the bottom leaf file (Snapshot 2)
• When the VM wants to read a block today, the hypervisor checks Snapshot 2 first. If that block was modified since June 1, it reads it from Snapshot 2. If not, it looks up the chain to Snapshot 1. If it wasn't modified there either, it reads the original block from the Base Disk.
• Why chains break: Every child snapshot stores two strict pointers in its header: (1) The file path of its immediate parent, and **(2) A 32-bit Content ID (CID នៅក្នុង VMware) ឬ 128-bit Linkage GUID (ParentUniqueId នៅក្នុង Hyper-V) ដែលបង្កើតឡើងវិញរាល់ពេលដែលឌីសមេត្រូវបានបើកសម្រាប់ការសរសេរ **។ ប្រសិនបើអ្នកណាម្នាក់ផ្លាស់ទីឯកសារ ប្តូរឈ្មោះថតឯកសារ ឬដំឡើងថាសមេក្នុងរបៀបអានសរសេរ នោះមេរបស់មេ។ CID / GUID ការផ្លាស់ប្តូរ ហើយអ្នកមើលការខុសត្រូវភ្លាមៗបដិសេធមិនភ្ជាប់រូបថតកុមារ ដើម្បីការពារអំពើពុករលួយប្លុកស្ងាត់។

បទទី១៖ ការសង្គ្រោះ VMware ESXi & Workstation .vmdk ខ្សែសង្វាក់រូបថត¶

នៅក្នុង VMware ESXi ថាសនិម្មិតតែមួយពិតជាមាន ឯកសារពីរដាច់ដោយឡែក សម្រាប់ថាសមូលដ្ឋាន និង ឯកសារពីរដាច់ដោយឡែក សម្រាប់រាល់រូបថតនីមួយៗ៖ 1. ឯកសារពិពណ៌នាអត្ថបទធម្មតាតូចមួយ (-500-byte) (Server.vmdk និង Server-000001.vmdk) ** ដែលកាន់ CID, parentCIDធរណីមាត្រថាស និងឈ្មោះឯកសារពិតប្រាកដនៃវិសាលភាពប្រព័ន្ធគោលពីរ។ (ចំណាំ៖ ស្តុក ESXi Datastore Browser web GUI លាក់ការផ្គូផ្គង -flat.vmdk និង -sesparse.vmdk ឯកសារគោលពីរ និងបង្ហាញតែរូបតំណាងរួមបញ្ចូលគ្នាតែមួយប៉ុណ្ណោះ អ្នកត្រូវតែប្រើ វគ្គស្ថានីយ SSH នៅលើម៉ាស៊ីន ESXi ដើម្បីមើលឯកសារពិត)។ 2. ** ឯកសារពង្រីកទិន្នន័យគោលពីរច្រើនជីហ្គាបៃ (Server-flat.vmdk សម្រាប់ថាសមូលដ្ឋាន និង Server-000001-sesparse.vmdk ឬ Server-000001-delta.vmdk សម្រាប់រូបថតនីមួយៗ)

សេណារីយ៉ូ 1A៖ ការជួសជុល "The parent virtual disk has been modified since the child was created (Parent CID mismatch)"¶

1. ** SSH ចូលទៅក្នុងម៉ាស៊ីន ESXi ហើយរុករកទៅថតទិន្នន័យរបស់ VM៖**

   cd /vmfs/volumes/<Datastore_Name>/<VM_Folder_Name>/
   ls -la *.vmdk
   

2. ** បោះពុម្ព CID, parentCID, និង parentFileNameHint នៅទូទាំងកម្មវិធីពណ៌នាអត្ថបទទាំងអស់។ .vmdk ឯកសារក្នុងពេលតែមួយ៖ **
3. (សំខាន់៖ រត់តែប៉ុណ្ណោះ cat ឬ grep នៅលើកម្មវិធីពណ៌នាអត្ថបទតូច 500 បៃ .vmdk ឯកសារ មិនមែននៅលើពហុជីហ្គាបៃទេ។ -flat.vmdk ឬ -sesparse.vmdk ឯកសារ)*

   grep -E "CID|parentFileNameHint|Extent description" -A 2 Server.vmdk Server-00000*.vmdk
   

4. ** ប្រៀបធៀប CID របស់ឪពុកម្តាយម្នាក់ៗប្រឆាំងនឹង parentCID របស់កូនភ្លាមៗ៖ មើលលទ្ធផល៖

   Server.vmdk:           CID=1a2b3c4d
                          parentCID=ffffffff   (ffffffff means this is the root Base Disk)
   
   Server-000001.vmdk:    CID=99887766
                          parentCID=55443322   <-- ERROR: Should equal Server.vmdk's CID (1a2b3c4d)
                          parentFileNameHint="Server.vmdk"
   
   Server-000002.vmdk:    CID=aabbccdd
                          parentCID=99887766   <-- OK: Matches Server-000001.vmdk's CID (99887766)
                          parentFileNameHint="Server-000001.vmdk"
   

5. ** ជួសជុលការខូច parentCID នៅក្នុងការពិពណ៌នាកុមារនិងផ្ទៀងផ្ទាត់ជាមួយ vmkfstools -e:**
6. ជាដំបូង បម្រុងទុកឯកសារពិពណ៌នាអត្ថបទ (cp Server-000001.vmdk Server-000001.vmdk.bak)
7. បើក Server-000001.vmdk ក្នុង vi និងផ្លាស់ប្តូរ parentCID=55443322 ទៅ parentCID=1a2b3c4d (ត្រូវគ្នា។ Server.vmdkបច្ចុប្បន្ន CID)
8. សាកល្បងភាពសុចរិតនៃខ្សែសង្វាក់ពីរូបថត ** ថ្មីបំផុត (លេខខ្ពស់បំផុត) ** ដោយប្រើ vmkfstools -e:

   vmkfstools -e Server-000002.vmdk
   

9. ប្រសិនបើខ្សែសង្វាក់នៅដដែល ESXi ចេញលទ្ធផល៖ Disk chain is consistent.
10. ** ការបង្រួបបង្រួមគ្មានការបំផ្លាញ (vmkfstools -i ក្លូនក្រៅកន្លែង)៖**
11. ប្រសិនបើ Server.vmdk ត្រូវបានកែប្រែបន្តិច មុនពេលអ្នកជួសជុល parentCID, កុំបង្រួបបង្រួមនៅនឹងកន្លែងលើច្បាប់ចម្លងតែមួយគត់របស់អ្នក។ ផ្ទុយទៅវិញ ចំណុច vmkfstools -i នៅ ** រូបថតស្លឹកថ្មីបំផុត (Server-000002.vmdk)** ហើយក្លូនខ្សែសង្វាក់ទាំងមូលទៅជា VMDK ថ្មីស្រឡាងតែមួយនៅលើ datastore ដែលមានទំហំទំនេរ៖

    vmkfstools -i Server-000002.vmdk /vmfs/volumes/<Target_Datastore>/Server_Rescue/Server_Merged.vmdk -d thin
    

12. vmkfstools -i អានរាល់ប្លុកពី Server-000002.vmdk ចុះក្រោម Server-000001.vmdk និង Server-flat.vmdk នៅក្នុងមុខងារ Read-Only Mode ដ៏តឹងរ៉ឹង ហើយសរសេរចេញនូវរូបភាពដែលស្អាត និងគ្មានការថតរូប Server_Merged.vmdk ដោយមិនប៉ះឯកសារដើមរបស់អ្នក។

សេណារីយ៉ូ 1B៖ បង្កើតឡើងវិញនូវការបាត់ ឬលុប 500-byte .vmdk អ្នកពិពណ៌នាអត្ថបទនៅពេល Server-flat.vmdk គឺនៅដដែល¶

ពេលខ្លះអ្នកគ្រប់គ្រង ឬស្គ្រីបខូចនឹងលុបចេញ Server.vmdk (ឬវាខូចទៅ 0 bytes) ដែលបណ្តាលឱ្យ Datastore Browser ឈប់បង្ហាញថាសនិម្មិត ទោះបីជា 500-gigabyte ដ៏ធំ Server-flat.vmdk ឯកសារដែលមាន 100 ភាគរយនៃទិន្នន័យពិតប្រាកដរបស់អ្នកនៅតែអង្គុយនៅទីនោះក្នុង SSH (ls -la *-flat.vmdk)

អ្នកអាចបង្កើតអត្ថបទធម្មតាដែលបាត់ Server.vmdk ឯកសារពិពណ៌នាក្នុងរយៈពេល 60 វិនាទីដោយមិនបាត់បង់ទិន្នន័យតែមួយបៃ Server-flat.vmdk:

# 1. Check the exact byte size of your existing Server-flat.vmdk:
ls -l Server-flat.vmdk
# Example output: -rw------- 1 root root 107374182400 Oct 31 12:00 Server-flat.vmdk  (Exactly 107,374,182,400 bytes)

# 2. Create a temporary dummy VMDK of that EXACT byte size in /tmp or the datastore:
vmkfstools -c 107374182400 -d thin temp_dummy.vmdk

# 3. Delete the dummy binary file (temp_dummy-flat.vmdk) and rename the 500-byte descriptor to Server.vmdk:
rm -f temp_dummy-flat.vmdk
mv temp_dummy.vmdk Server.vmdk

# 4. Edit Server.vmdk in 'vi' and change the filename inside quotes from "temp_dummy-flat.vmdk" to "Server-flat.vmdk":
sed -i 's/temp_dummy-flat.vmdk/Server-flat.vmdk/g' Server.vmdk
# (Also delete the line 'ddb.thinProvisioned = "1"' if the original disk was thick-provisioned)

សេណារីយ៉ូ 1C៖ ដោះសោ ក .vmdk ចាក់សោដោយម៉ាស៊ីន ESXi ដែលព្យួរ ឬប្រូកស៊ីបម្រុងទុកគាំង (Cannot open the disk: Failed to lock the file)¶

ប្រសិនបើ VM បដិសេធមិនបើកជាមួយ Failed to lock the file ឬ Cannot open disk: Resource busyម៉ាស៊ីន ESXi មួយផ្សេងទៀតនៅក្នុងចង្កោម (ឬឧបករណ៍ Veeam/backup HotAdd ដែលគាំងកំឡុងពេលបម្រុងទុក) នៅតែរក្សាការចាក់សោឯកសារ SCSI/VMFS -flat.vmdk ឬ -sesparse.vmdk: 1. ពិនិត្យមើលថាតើប្រូកស៊ីបម្រុងទុក VM ដែលគាំងនៅតែមាន VM ផលិតកម្មរបស់អ្នក។ .vmdk ភ្ជាប់ទៅឧបករណ៍បញ្ជា SCSI និម្មិតរបស់វា៖ កែសម្រួលការកំណត់នៃ VMs ប្រូកស៊ី Veeam/CommVault របស់អ្នក ហើយយកថាសផលិតកម្មដែលភ្ជាប់មកជាមួយដែលជាប់គាំង (** ជ្រើសរើស "យកចេញពីម៉ាស៊ីននិម្មិត" កុំ "លុបឯកសារចេញពីឃ្លាំងទិន្នន័យ")។ 2. ** ស្វែងរកអាសយដ្ឋាន MAC ដែលជាម្ចាស់ផ្ទះរបស់ ESXi និងដំណើរការពិភពលោកដែលកាន់សោ VMFS:

vmfsfilelockinfo -p /vmfs/volumes/<Datastore>/<VM_Folder>/Server-flat.vmdk

បទទី 2៖ ការសង្គ្រោះ Microsoft Hyper-V .vhdx និង .avhdx ខ្សែសង្វាក់រូបថត¶

នៅក្នុង Microsoft Hyper-V រាល់ចំណុចត្រួតពិនិត្យ (រូបថត) បង្កើតថាសរឹងនិម្មិតដែលមានផ្នែកបន្ថែម .avhdx (ឬ .avhd នៅលើទ្រង់ទ្រាយ VHD ចាស់) បានកំណត់ឈ្មោះឯកសារ GUID វែងដូច ProdSQL_A1B2C3D4-E5F6-7890-ABCD-1234567890AB.avhdx.

ជំហានទី 1: ធ្វើផែនទីតាមកាលប្បវត្តិពិតប្រាកដ .avhdx មែកធាងឪពុកម្តាយកូននៅក្នុង PowerShell¶

មុននឹងបញ្ចូលគ្នា ឬភ្ជាប់ឡើងវិញនូវអ្វីទាំងអស់នៅក្នុងកម្មវិធីគ្រប់គ្រង Hyper-V សូមបើកបង្អួច Elevated Administrator PowerShell នៅលើម៉ាស៊ីន Hyper-V រុករកទៅកាន់ថតឯកសារដែលមានរបស់អ្នក។ .vhdx និង .avhdx ឯកសារ ហើយដំណើរការបន្ទាត់តែមួយនេះ ដើម្បីបង្ហាញខ្សែសង្វាក់ឪពុកម្តាយ និងកូនពិតប្រាកដពីថ្មីបំផុតទៅចាស់បំផុត៖

# Inspect every .vhdx and .avhdx in the directory, sorted by LastWriteTime:
Get-ChildItem -Filter "*.*vhd*" | ForEach-Object {
    Get-VHD -Path $_.FullName -ErrorAction SilentlyContinue |
    Select-Object Path, ParentPath, VhdType, FileSize, Size
} | Format-List

សូមក្រឡេកមើល Path និង ParentPath វាល។ ពួកគេនឹងបង្ហាញពីលំដាប់ខ្សែសង្វាក់ពិតប្រាកដ៖ - ProdSQL.vhdx -> ParentPath: (blank) (** Root Base Disk, ចាស់ជាងគេ**) - ProdSQL_1111.avhdx -> ParentPath: D:\VMs\ProdSQL.vhdx (កូន១) - ProdSQL_2222.avhdx -> ParentPath: D:\VMs\ProdSQL_1111.avhdx (កូន 2) - ProdSQL_3333.avhdx -> ParentPath: D:\VMs\ProdSQL_2222.avhdx (** ថាសសកម្មថ្មីបំផុត**)

ជំហានទី 2: ជួសជុល "The chain of virtual hard disks is broken" ឬ "Differencing disk parent ID mismatch" (Set-VHD -IgnoreIdMismatch)¶

តើមានអ្វីកើតឡើងប្រសិនបើនរណាម្នាក់បានផ្លាស់ទីថត VM ពី C:\VMs\ ទៅ E:\VMs\ឬចាប់ផ្ដើមដោយចៃដន្យ ProdSQL.vhdx រយៈពេល 5 វិនាទីបណ្តាលឱ្យ ProdSQL_1111.avhdx បរាជ័យជាមួយ៖ The chain of virtual hard disks is broken. The system cannot locate the parent virtual hard disk for the differencing disk ឬ There is a mismatch in the virtual disk identifiers?

ប្រើ Hyper-V PowerShell cmdlet ផ្លូវការ Set-VHD ជាមួយ -IgnoreIdMismatch ទង់ជាតិ (បន្ទាប់ពីការបម្រុងទុកឯកសារជាមុន):

# Relink a child .avhdx to its parent .vhdx/.avhdx (adding -IgnoreIdMismatch if the parent timestamp/GUID shifted):
Set-VHD -Path "E:\VMs\ProdSQL_1111.avhdx" -ParentPath "E:\VMs\ProdSQL.vhdx" -IgnoreIdMismatch

ជំហានទី 3: ការរួមបញ្ចូលគ្នាដោយដៃកុមារកំព្រា .avhdx ខ្សែសង្វាក់ពី NEWEST ទៅ OLDEST (Merge-VHD)¶

នៅពេលដែលភ្នាក់ងារបម្រុងទុក 15 នាក់កំព្រា .avhdx ឯកសារនៅក្នុងថតឯកសាររបស់អ្នកដែលលែងបង្ហាញនៅក្នុងមែកធាង Hyper-V Manager GUI "Checkpoints" ** អ្នកត្រូវតែបញ្ចូលពួកវាដោយដៃនៅក្នុង PowerShell ខណៈពេលដែល VM ត្រូវបានបិទ ** ។

ដំណើរការពាក្យបញ្ជា PowerShell ពិតប្រាកដទាំងនេះនៅលើ ច្បាប់ចម្លងដែលកំពុងដំណើរការ នៃថតឯកសារ៖

# Step 1: Merge Child 3 (Newest) into Child 2:
Merge-VHD -Path "E:\VMs\ProdSQL_3333.avhdx" -DestinationPath "E:\VMs\ProdSQL_2222.avhdx"

# Step 2: Merge Child 2 into Child 1:
Merge-VHD -Path "E:\VMs\ProdSQL_2222.avhdx" -DestinationPath "E:\VMs\ProdSQL_1111.avhdx"

# Step 3: Merge Child 1 into the Base .vhdx:
Merge-VHD -Path "E:\VMs\ProdSQL_1111.avhdx" -DestinationPath "E:\VMs\ProdSQL.vhdx"

បទទី 3: ការសង្គ្រោះ Proxmox VE / QEMU / KVM .qcow2 និង VirtualBox .vdi ច្រវាក់¶

1. ពិនិត្យ និងជួសជុល QCOW2 L1/L2 Cluster & Refcount ដែលខូច (qemu-img check)¶

នៅពេលដែលម៉ាស៊ីន Linux KVM ឬ Proxmox ទទួលរងការដាច់ចរន្តអគ្គីសនីភ្លាមៗដោយគ្មានឃ្លាំងសម្ងាត់ដែលគាំទ្រដោយថ្ម។ .qcow2 ថាសនិម្មិតជាញឹកញាប់បរាជ័យក្នុងការចាប់ផ្ដើមជាមួយ qcow2: Marking image as corrupt: L2 table offset unaligned ឬ Refcount block corrupted. 1. ** ចម្លងដំបូង .qcow2 ឯកសារ (cp vm-100-disk-0.qcow2 vm-100-disk-0.qcow2.bak) ** 2. ** ពិនិត្យមើលខ្សែសង្វាក់គាំទ្រ និងបញ្ជីរូបថតខាងក្នុង៖ **

qemu-img info --backing-chain vm-100-disk-0.qcow2
qemu-img snapshot -l vm-100-disk-0.qcow2

qemu-img check -r all vm-100-disk-0.qcow2

2. ជួសជុលផ្លូវឯកសារបម្រុងទុក QCOW2 ដែលខូច (qemu-img rebase -u)¶

ប្រសិនបើរូបថត QCOW2 ខាងក្រៅ (overlay.qcow2) បរាជ័យក្នុងការបើកដោយសារតែឯកសារគាំទ្រមេរបស់វា (base.qcow2) ត្រូវ​បាន​ផ្លាស់​ទី​ទៅ​កាន់​ថត​ថ្មី ឬ​ឃ្លាំង​ផ្ទុក ធ្វើ​បច្ចុប្បន្នភាព​ទ្រនិច​ឯកសារ​គាំទ្រ​ដោយ​មិន​មាន​សុវត្ថិភាព (-u, តែបឋមកថា) របៀបដោយមិនសរសេរប្លុកទិន្នន័យឡើងវិញ៖

qemu-img rebase -u -b /new/path/to/base.qcow2 -F qcow2 overlay.qcow2

3. ធ្វើឱ្យខ្សែសង្វាក់ QCOW2 ឬ VMDK ឬ VHDX ដ៏ផុយស្រួយឱ្យទៅជារូបភាពឯករាជ្យថ្មី (qemu-img convert)¶

ឧបករណ៍មួយដែលអាចប្រើប្រាស់បានច្រើនបំផុតក្នុងការសង្គ្រោះម៉ាស៊ីននិម្មិតគឺ qemu-img convert (ដែលអានពីដើម .qcow2, .vmdk, .vhdx, .vhd, និង .vdi) នៅពេលអ្នកចង្អុលបង្ហាញ qemu-img convert នៅ រូបថតស្លឹកថ្មីបំផុត នៃខ្សែសង្វាក់ដែលមានសុពលភាព វាអានឋានានុក្រមឪពុកម្តាយ និងកូនទាំងមូលនៅក្នុង របៀបអានតែប៉ុណ្ណោះ ដ៏តឹងរឹង** ហើយសរសេរចេញនូវឌីសនិម្មិតថ្មី ដែលមិនមានថតដោយខ្លួនឯង នៅលើឧបករណ៍ផ្ទុកសង្គ្រោះរបស់អ្នក៖

# Non-destructively flatten an entire QCOW2, VMDK, or VHDX chain into a single clean image:
qemu-img convert -p -O qcow2 top_snapshot_leaf.qcow2 /mnt/rescue_storage/flattened_clean.qcow2

បទទី 4៖ ការសង្គ្រោះឯកសារក្រៅបណ្តាញ (ការទាញយកឯកសារនៅពេលដែល VM នៅតែមិនដំណើរការ)¶

តើមានអ្វីកើតឡើងប្រសិនបើប្រព័ន្ធប្រតិបត្តិការភ្ញៀវនៅខាងក្នុងថាសនិម្មិតមិនអាចដំណើរការបាន ឬរូបថតកណ្តាលនៅក្នុងខ្សែសង្វាក់ត្រូវបានខូចខាតដោយផ្នែក ហើយអ្នកត្រូវដកមូលដ្ឋានទិន្នន័យ SQL ចេញ (.mdf/.ldf), ឯកសារ QuickBooks, /var/lib/mysqlឬឯកសាររបស់ក្រុមហ៊ុនក្នុងរយៈពេល 30 នាទីបន្ទាប់?

អ្នកមិនចាំបាច់ចាប់ផ្ដើមម៉ាស៊ីននិម្មិតដើម្បីទាញយកឯកសារនៅក្នុងដ្រាយវ៍រឹងនិម្មិតរបស់វានោះទេ។ ប្រើឧបករណ៍ម៉ោនក្រៅបណ្តាញដែលមិនបំផ្លាញទាំងបីនេះ៖

វិធីសាស្រ្ត 1: ម៉ោនណាមួយ។ .vmdk, .vhdx, .qcow2, ឬ .vdi នៅក្នុងរបៀបអានបានតែនៅលើលីនុចដោយប្រើ libguestfs (guestmount / qemu-nbd)¶

ដំឡើង libguestfs-tools (sudo apt install libguestfs-tools qemu-utils នៅលើអ៊ូប៊ុនទូ / ដេបៀន / ប្រូម៉ូក) ហើយភ្ជាប់ ** រូបថតស្លឹកថ្មីបំផុត ** នៅក្នុងរបៀបដ៏តឹងរឹង ** អានតែប៉ុណ្ណោះ (--ro) **៖

# Option A: Using guestmount (Automatically detects internal guest LVM/partitions and mounts read-only):
sudo mkdir -p /mnt/vm_rescue
sudo guestmount -a /path/to/Newest_Leaf_Snapshot.vmdk -i --ro /mnt/vm_rescue
# (If guest OS partitions fail auto-inspection due to dirty NTFS journal, list partitions with 'virt-filesystems -a disk.vmdk -l'
# and mount the specific partition directly with '-m /dev/sda2 --ro -o norecover')

# Option B: Attaching the virtual disk chain as a Read-Only Network Block Device (/dev/nbd0):
sudo modprobe nbd max_part=16
sudo qemu-nbd --read-only --connect=/dev/nbd0 /path/to/Newest_Leaf_Snapshot.qcow2
sudo partprobe /dev/nbd0
lsblk /dev/nbd0
# Now mount /dev/nbd0p2 read-only (with -o ro,norecover for NTFS or -o ro,noload for ext4):
sudo mount -o ro,norecover /dev/nbd0p2 /mnt/vm_rescue

វិធីសាស្រ្តទី 2: ការស្រង់ចេញបានតែអានភ្លាមៗនៅលើ Windows ដោយប្រើ 7-Zip ឬ Disk Management -> Attach VHD (Read-Only)¶

• ** ការប្រើប្រាស់ 7-Zip (ដំណើរការលើ .vmdk, .vhdx, .vhd, .qcow2, និង .vdi):** ចុចកណ្ដុរស្ដាំលើឯកតាឬរុញភ្ជាប់ .vmdk, .vhdx, ឬ .qcow2 file នៅលើ Windows ហើយជ្រើសរើស 7-Zip -> Open Archive។ 7-Zip ញែកតារាងភាគថាស GPT/MBR និងប្រព័ន្ធឯកសារ NTFS/ext4 នៅខាងក្នុងថាសនិម្មិតក្នុងរបៀបអានបានតែ 100% ដែលអនុញ្ញាតឱ្យអ្នកអូស និងទម្លាក់ថតភ្ញៀវត្រង់ទៅលើផ្ទៃតុរបស់អ្នកក្នុងរយៈពេលប៉ុន្មានវិនាទី។
• ** ការប្រើប្រាស់ Windows Disk Management (សម្រាប់ .vhdx / .avhdx): ** បើក diskmgmt.msc -> ** សកម្មភាព -> ភ្ជាប់ VHD ** -> រកមើលទៅ ** ស្លឹកថ្មីបំផុត។ .avhdx** (ឬ .vhdx), ** ធីកប្រអប់សម្រាប់ [X] Read-only (សំខាន់៖ កុំ​ភ្លេច​ពិនិត្យ​មើល​តែ​អាន​ប៉ុណ្ណោះ បើ​មិន​ដូច្នេះ​ទេ Windows នឹង​កែប្រែ​បឋមកថា​ថាស)** ហើយ​ចុច យល់ព្រម។ ដ្រាយ C: និង D: របស់ VM របស់អ្នកលេចឡើងភ្លាមៗនៅក្នុង Windows File Explorer ។

វិធីសាស្រ្តទី 3: ការស្ថាបនាឡើងវិញនូវខ្សែសង្វាក់ដែលខូចខាតយ៉ាងធ្ងន់ធ្ងរជាមួយ UFS Explorer Professional Recovery¶

ប្រសិនបើថាសមេនៅក្នុងខ្សែសង្វាក់ VMDK ឬ VHDX ត្រូវបានចាប់ផ្ដើម និងកែប្រែដោយចៃដន្យ ឬប្រសិនបើ VMFS/NTFS datastore ខូចបានបំបែកផ្នែកនៃ -sesparse.vmdk ឬ .avhdx ឯកសារដូច្នេះឧបករណ៍ hypervisor ច្រានចោលវា ** UFS Explorer Professional Recovery ** (ឬ ** R-Studio Technician ) អនុញ្ញាតឱ្យអ្នកប្រមូលផ្តុំឌីសមូលដ្ឋានឆៅដោយដៃ និងរូបភាពដីសណ្តរបស់កូននីមួយៗទៅជា ** ជង់ដីសណ្តនិម្មិត ផ្ទាល់ខ្លួននៅក្នុង RAM ផ្នែកទន់ ដោយឆ្លងកាត់ hypervisor ។ CID/GUID ពិនិត្យបឋមកថាដើម្បីឆ្លាក់ និងទាញយកឯកសារភ្ញៀវដែលនៅដដែល។

បទទី 5៖ ការសង្គ្រោះឯកសារកំណត់រចនាសម្ព័ន្ធ VM ដែលកំព្រា (.vmx, .xml, ឬ <vmid>.conf)¶

ពេលខ្លះខ្សែសង្វាក់ថាសរឹងនិម្មិតខ្លួនឯង (*.vmdk, *.vhdx, ឬ *.qcow2) គឺនៅដដែល 100 ភាគរយនៅលើអារេផ្ទុក ប៉ុន្តែឯកសារកំណត់រចនាសម្ព័ន្ធតូចដែលកំណត់ប្លង់ផ្នែករឹងរបស់ម៉ាស៊ីននិម្មិត (.vmx នៅក្នុង VMware ESXi, <GUID>.vmcx / .xml នៅក្នុង Hyper-V ឬ /etc/pve/qemu-server/<vmid>.conf នៅក្នុង Proxmox VE) ត្រូវបានខូច លុបដោយចៃដន្យ ឬសូន្យចេញកំឡុងពេលម៉ាស៊ីនគាំង។

ប្រសិនបើអ្នកបង្កើតសែល VM ជំនួសដោយឧបករណ៍បញ្ជាការផ្ទុកនិម្មិតខុស ឬរបៀបកម្មវិធីបង្កប់ ប្រព័ន្ធប្រតិបត្តិការភ្ញៀវនឹងគាំងភ្លាមៗនៅពេលចាប់ផ្ដើមជាមួយ INACCESSIBLE_BOOT_DEVICE (វីនដូ) ឬទម្លាក់ទៅក្នុង ក dracut / initramfs សែលសង្គ្រោះបន្ទាន់ (លីនុច) ។ ផ្គូផ្គងការកំណត់ផ្នែករឹងទាំងបួននេះទៅនឹងការកំណត់រចនាសម្ព័ន្ធភ្ញៀវដើមរបស់អ្នក មុនពេលភ្ជាប់ថាសនិម្មិតដែលបានសង្គ្រោះរបស់អ្នក៖

សំណួរដែលគេសួរញឹកញាប់¶

ប្រភពបានពិនិត្យ¶

• VMware ដោយ Broadcom មូលដ្ឋានចំណេះដឹងបច្ចេកទេស៖ KB 1007969 / 316578 (ការដោះស្រាយ "ថាសនិម្មិតមេត្រូវបានកែប្រែតាំងពីកុមារត្រូវបានបង្កើត" CID Mismatch Errors), KB 1002511 (បង្កើតឡើងវិញនូវកម្មវិធីពិពណ៌នាថាសម៉ាស៊ីននិម្មិតដែលបាត់ .vmdk ឯកសារ) និង KB 10051 (ការយល់ដឹងអំពីរូបភាពម៉ាស៊ីននិម្មិតនៅក្នុង ESXi)។
• Microsoft Learn / Windows Server Hyper-V Engineering Documentation: Hyper-V PowerShell Reference for Get-VHD, Set-VHD -IgnoreIdMismatch, និង Merge-VHD ការរួមបញ្ចូលឌីសភាពខុសគ្នាក្រៅបណ្តាញ។
• គម្រោង QEMU & Red Hat Enterprise Linux Virtualization Documentation: ផ្លូវការ qemu-img សៀវភៅដៃ (info --backing-chain, check -r all, rebase -u, convert) និង libguestfs (guestmount --ro) អានតែការត្រួតពិនិត្យថាសនិម្មិត។
• ឯកសារបច្ចេកទេស Oracle VirtualBox៖ VBoxManage showmediuminfo និង clonemedium ស្ថាបត្យកម្មរូបភាពប្លែកៗ.
• វិទ្យាស្ថានស្តង់ដារ និងបច្ចេកវិទ្យាជាតិ (NIST សហរដ្ឋអាមេរិក)៖ ការបោះពុម្ពផ្សាយពិសេស NIST 800-86៖ ការណែនាំអំពីការរួមបញ្ចូលបច្ចេកទេសកោសល្យវិច្ច័យទៅក្នុងការឆ្លើយតបឧប្បត្តិហេតុ (ការរក្សារូបភាពម៉ាស៊ីននិម្មិត)។

ការណែនាំដែលពាក់ព័ន្ធ¶

• អារេ NAS និង RAID ត្រូវបានបំផ្លាញ ការបរាជ័យនៃដ្រាយច្រើន និងការស្ដារ ZFS/Btrfs
• NVMe ឬ SSD ភ្លាមៗចូលទៅក្នុងរបៀបបានតែអាន ឬបាត់ពី BIOS
• ការបរាជ័យនៃដ្រាយវ៍រឹង និងការសង្គ្រោះទិន្នន័យសង្គ្រោះបន្ទាន់
• ការបរាជ័យក្នុងការចាប់ផ្ដើមប្រព័ន្ធលីនុច និងការជួសជុល GRUB
• Windows Blue Screen (BSOD) និងការជួសជុលចាប់ផ្ដើម
• ការបម្រុងទុកកុំព្យូទ័រ៖ យុទ្ធសាស្ត្រ 3-2-1 និងការសង្គ្រោះគ្រោះមហន្តរាយ
• លេខអាសន្នសកល