Before changing VM settings, identify your host architecture and the files in the download. Most import problems become easier to diagnose once you separate archive extraction, VM configuration, guest boot and network discovery.
Keep an untouched copy of the download and extracted files. Work on a copy, change one setting at a time, and record the exact error. This guide does not prescribe one controller or adapter setting for every Kioptrix image.
First check: can this host run this guest architecture?
Record whether the host is Intel/AMD x86-64 or ARM, then identify the target image’s architecture. A working Kali VM on an Apple Silicon Mac does not establish that an older x86 Kioptrix appliance will run in the same hypervisor.
Broadcom documents Fusion support on Apple Silicon: Fusion virtualizes ARM guests there rather than running x86 guests. Renaming the disk, changing RAM or repeatedly importing it does not resolve that architecture mismatch.
If the target requires x86, choose a compatible x86 host or investigate an explicitly supported emulation path with its own limitations. Record that environment clearly. Do not spend time diagnosing an architecture incompatibility as a DHCP problem.
Second check: what did the archive actually contain?
| Files you have | What they represent | Appropriate next action |
|---|---|---|
| .zip, .7z or .rar | An archive containing the appliance files. | Extract fully to a writable working folder; inspect the contents. |
| .ova | A packaged appliance. | Use the hypervisor’s supported appliance import flow. |
| .ovf with disk files | An appliance descriptor plus referenced disks. | Keep the referenced files together and import the descriptor. |
| .vmx with .vmdk files | A VMware VM configuration with disks. | Open the existing configuration in a compatible VMware product. |
| Only .vmdk | A virtual disk, not necessarily a complete appliance. | If supported, create a compatible VM shell and attach the existing disk; document the settings you supply. |
A VMDK may include a small descriptor and separate extent files. Preserve the complete set and filenames. Do not rename a VMDK to OVA, open an incomplete split disk, or overwrite the target disk by creating a new blank one.
Check the original download page for a published checksum and compare it before working. A matching hash confirms consistency with that published value, not a guarantee that the VM is safe. VulnHub’s FAQ explains common appliance formats and download checks. Use the download guide to identify the intended image and source.
VMware route: open the supplied VMX
Documentation-based workflow. This update did not boot the appliance or verify a particular host build. Broadcom documents the Workstation File → Open route for an existing VM configuration. Menu wording can differ by product and release; record the version you actually use.
- Extract the complete archive into a working folder. Keep the original archive separately. Confirm that the
.vmxconfiguration and every referenced.vmdkfile are present. - In Workstation, choose File → Open and select the supplied
.vmx. Do not select the RAR archive or create a new blank disk over the extracted disk. - Before powering on, open the VM’s settings. Confirm the disk filename points to the extracted working copy. Retain the supplied firmware and controller arrangement initially.
- Review every network adapter. Select the intended isolated lab network, remove unintended outward-facing connections, and record the target MAC. Host-only also connects the host; review routing and sharing separately.
- Power on once and record the first meaningful console state. A login prompt means boot has progressed; it does not identify an IP address or prove the network is isolated.
If a disk-conversion or compatibility-upgrade prompt appears, record it and preserve the original files before deciding. Conversion is not a default troubleshooting step. Source: Broadcom’s VM configuration guidance.
VirtualBox route: attach an existing VMDK
A VMware .vmx is not an OVF appliance descriptor. For an extracted VMDK, create a VM definition and attach that existing disk. Use Import Appliance only when you actually have an OVF/OVA package. Disk-format support does not guarantee that the old guest will boot on your chosen host.
| Documented interface | Path to the existing disk | Check before starting |
|---|---|---|
| VirtualBox 7.1 new-VM workflow | At the hard-disk step, select Use an Existing Virtual Hard Disk File and choose the extracted disk. | The selected path is the working copy, not a newly created empty disk. |
| VirtualBox 7.2 settings route | Select the powered-off VM → Settings → Storage → select its appropriate controller → Add Disk → Hard Disk → choose the existing image. | The disk is attached as a hard disk, not an optical image; controller and firmware fit the guest. |
Choose a guest OS type and architecture matching the appliance. You are reusing an installed guest, so an unattended OS installation is not the task. Avoid guessing a universal RAM, EFI or controller recipe: compare the original configuration and exact error if boot fails. If a new-VM workflow created an empty disk, review the attachment list before starting; keep the original target disk intact.
For a split VMDK, select its descriptor while retaining every extent in the same relative location. Do not attach an individual -flat or numbered extent as though it were the complete descriptor. Do not attach the same writable disk to two running VMs.
Sources: Oracle’s 7.1 existing-disk workflow, 7.2 Storage Settings and virtual disk formats and cloning.
What success looks like, and what to do if it fails
| What you see | What it means | Next action |
|---|---|---|
| The VM appears in the manager. | Its configuration was registered. | Verify disk and adapters before boot. |
| Missing disk or extent filename. | The configuration cannot resolve a required file. | Compare extraction contents and paths; do not create a replacement blank disk. |
| No bootable medium. | The selected boot path has not found a bootable guest. | Check disk attachment, boot order, firmware and controller against the original configuration. |
| Stable guest console/login prompt. | The guest has progressed through boot. | Save this baseline, then identify its current lab-network address. |
| Console works; Kali sees no target. | Import is no longer the first unresolved stage. | Check exact network identity, cable state and addressing. |
A completed incident note
Illustrative scenario, not a tested Kioptrix configuration: a learner has all disk files, but attaches a newly created empty disk instead of the extracted disk.
Stage: guest boot; configuration opens normally.
Symptom: No bootable medium.
Observation: Storage lists a new empty disk; the extracted VMDK is not attached.
Change: power off, attach the existing working-copy descriptor to the appropriate controller.
Verification: compare attachment path, then record the actual boot result.
If unchanged: retain the error and inspect firmware/controller assumptions next.
Network status: not yet checked; do not claim setup is complete.Use the blank record below for your own case. Once boot is stable, the first-session guide takes you from target identification to a saved scan.
Final import checklist
- Record compatibility. Host architecture, operating system, hypervisor/version and target image identity.
- Verify and extract. Keep the original; inspect filenames and extraction errors before opening a VM.
- Choose the correct entry point. Import the appliance or open its existing configuration according to the file set.
- Review hardware before boot. Inspect the disk attachment, guest type and every network adapter. Do not connect an intentionally vulnerable target to a bridged physical LAN by default.
- Boot and capture the first failure. Record the exact screen or message and whether the guest reached a stable console.
- Establish a baseline. Once boot works, record the configuration and a snapshot if supported. Then diagnose network discovery separately.
For OVF/OVA handling, consult VirtualBox’s VM and appliance documentation. An imported configuration can still need review; import success alone does not confirm network isolation or a working guest.
Troubleshoot the stage that actually failed
| Stage and symptom | Inspect first | Avoid |
|---|---|---|
| Archive will not extract | Checksum, complete download, available space and extractor error. | Changing VM networking before files exist. |
| Import rejects the descriptor or disk | Supported format, referenced filenames, missing extents and permissions. | Renaming file extensions to force acceptance. |
| Guest will not boot | Architecture, attached disk, original firmware/controller assumptions and exact boot error. | Changing several controllers and firmware settings simultaneously. |
| Guest reaches a login prompt | Whether this image expects network-based discovery from Kali. | Assuming you must know the target’s console password or resetting it without a reason. |
| Guest boots but has no discovered address | Adapter mode, shared network identity, cable state, DHCP or static configuration and target identity. | Repeatedly reimporting a VM whose boot already works. |
For a boot failure, try a single change only when it follows from the error or appliance requirements. Record the old value, new value and result; revert an ineffective change. This keeps later symptoms interpretable.
A login prompt is often a useful boundary: the guest has progressed beyond import and early boot. Many practice targets are meant to be approached over the lab network rather than through an initial console login. Read the image’s own notes; do not assume the same credentials or behavior across levels.
Copy this import incident record
Image and source URL:
Published checksum / locally computed checksum:
Host architecture and OS:
Hypervisor and version:
Archive filename and extracted file set:
Entry point used (.vmx / .ovf / .ova / existing disk):
Disk, firmware and controller settings:
Every network adapter and its network name:
Failure stage and exact message:
One change tried, previous value and result:
Working baseline / snapshot / unresolved question:Keep paths and logs private when they include personal information. A useful help request can share a sanitized error, file list and environment instead of uploading the whole appliance or a screenshot without context.
Next: prove the network boundary and target identity
After a stable boot, follow the network setup guide. For image-specific preparation, see Level 1 download checks or Level 3 preparation. Keep the successful import configuration in your session notes so a future restore starts from a known state.
Documentation reviewed October 24, 2026. Menu paths are based on the linked vendor documentation. No new appliance import, guest boot or version-specific compatibility test was performed for this update.