How to Add a Physical Disk to a Virtual Machine on VMware Workstation

Connecting a physical storage unit directly to a virtual machine in VMware Workstation seems practical. People who deal with dual-boot systems often think about this method. Also, people who need raw storage performance often consider this method.

In this guide, I cover the VMware physical drive add process in fine detail. As of 2026, I base this on current Workstation Pro releases shaped under Broadcom. We will talk through every trap you may hit, the 2 TB wall, and the deadly risks BitLocker can create, one by one.

But first, I must give a clear warning. This process is not at all like creating an ordinary virtual storage unit. Raw storage access bypasses the hypervisor layer and reaches straight to the hardware. As a result, both its benefit and its risk are very high.

So why take this much risk? The answer is quite simple: performance and direct access. Raw storage access gives you serious gains, mainly on database servers or video editing stations. On top of that, raw storage access also offers serious gains for dual-boot Windows setups. Still, you must know the limits of these gains.

When Should You Use a VMware Raw Disk?

First, let us start with the basic definition. A VMware physical disk is a setup. This setup presents a real hard drive on your host machine directly to your virtual machine. Or it presents a specific part of that storage unit directly to your virtual machine.

In this method, the hypervisor does not pass storage input-output requests through its own file system layer. Instead, the virtual machine reaches the physical hardware directly.

Here is a key distinction: VMware Workstation creates a special VMDK descriptor file called rawDisk for this process. This file does not hold real data.

But you cannot attach a disk without understanding the hypervisor level. At this stage, you should get clear info about VMware Workstation virtualization architecture. Grasping the virtualization layer prevents possible hardware locks from the start.

It only acts as a pointer that defines the path to the target physical drive. So when you see a file with a .vmdk extension, keep in mind that it is a bridge, not a container.

You must not confuse this structure with your standard virtual unit. A normal .vmdk file is a single file that grows to huge sizes on your host operating system.

In raw mapping, however, there is only a descriptor of a few kilobytes. The difference completely changes the balance between performance and portability.

Key Difference Between a Raw Disk and a Virtual Disk (VMDK)

Understanding the difference between the two structures is the first must for a correct decision. A virtual unit is a purely software abstraction layer. Raw storage, on the other hand, removes this layer and reaches straight to the hardware. This key difference brings a set of practical results with it.

The most striking row in the table is the one about snapshot support. When you add a physical drive, you lose your ability to take snapshots in most cases. This is a detail that throws your rollback plan out the window from the start. Plus, this situation severely limits portability.

On the other hand, you feel the performance gap mainly in workloads that need heavy input-output. For database work or large file copies, raw storage access provides a clear gain.

Also, raw storage access provides a clear gain in video render processes. Still, the size of this gain varies based on the storage unit you use and the type of workload.

In Which Scenarios Does Raw Disk Make Sense?

Adding a physical drive is not right for every need. In some scenarios, this method really produces sensible results. Below, I list cases I often meet in the field where raw storage use really helps.

• Dual-boot scenarios: If you run Windows and Linux on the same physical media in separate partitions, you may want to open the current setup in a virtual machine. Raw disk mapping gives access to the current operating system without a reinstall.
• Data recovery and forensics: You need raw access to inspect a problem drive or an unresponsive system in a virtual setting. Physical mapping offers a way to analyze data without putting it at risk on the host side.
• Tests that need high I/O: If you run database benchmarks or storage performance tests, raw storage access gives more realistic results. However, you should use a reserved, non-production unit for these tests.
• USB and external drive tests: If you want to present a USB stick to a virtual machine, raw mapping offers a practical fix. Also, if you want to present an external medium to a virtual machine, raw mapping again offers a practical fix. Still, you should also consider the USB passthrough feature in this scenario.

The common point in this list is this: we usually isolate or back up the target drive. Attaching a medium that holds production data as raw does not fit any scenario in the list. So when you decide, you should weigh the value of the data first, then the performance need.

Adding a Physical Drive in VMware Workstation: Step-by-Step Process

Now we move to the hands-on part. This process needs careful prep and the right order. Skipping steps or changing the order invites hard-to-reverse errors. Following the steps below in full is vital.

Prep: Power Off the VM, Run as Admin, and Detach the Disk from the Host

First of all, you must fully power off the virtual machine. Suspending or pausing is not enough. VMware does not allow you to add a physical drive to a running VM. So power off the VM first, and make sure its state is “Powered Off.”

Next, run VMware Workstation as an administrator. The UAC (User Account Control) mechanism in Windows can limit the permissions needed to access physical media.

Without admin rights, the system denies physicaldrive access. So you should right-click the app and use the “Run as administrator” option.

Your system should have a clean VMware Workstation Pro setup for Windows. When admin permits are missing, you can never reach physical devices. Doing your prep in full will protect you from later errors.

Finally, detach the target drive from the host operating system. Open the disk management panel in Windows. Right-click the target unit and remove the drive letter. This step prevents a file system clash between host and guest. If you can put the unit in offline mode, that is an even safer approach.

Users who skip this prep stage often hit the “Physical Disk is already in use” error. This error shows that the host operating system has an open handle on the target unit.

Moreover, this error shows that another app has an open handle on the target unit. To fix it, you need to delete .lck files or use diskpart to make the medium offline.

Adding Hardware: ‘Use a Physical Disk’ Choice and Full Disk / Partition Decision

With the VM off, open the virtual machine settings. On the Hardware tab, click the “Add” button. From the list of hardware types, select the “Hard Disk” option. When you click Next, storage type choices will appear.

Here is a key fork: “Create a new virtual disk,” “Use an existing virtual disk,” or “Use a physical disk.” You should pick the third option, “Use a physical disk (for advanced users).” This option opens the door to raw access.

On the next screen, you will make two key choices. First, you should pick which physical drive to use. In the list that opens, you will see numbers like “PhysicalDrive0” and “PhysicalDrive1”.

These numbers match the order in Windows disk management panel one to one. To avoid picking the wrong drive, always check the capacity and model info.

The second choice is about scope of use. “Use entire disk” assigns the whole medium to the virtual machine. With “Use individual partitions,” you attach only specific parts.

If the unit holds other data and you want to give only part of it to the VM, you should use the second option. However, partition-based access raises the risk of a signature clash.

After you make your choice, VMware asks for a location and name for the .vmdk descriptor file. You can accept the default settings. However, keep in mind that this file appears in the VM configuration folder. In the last step, click “Finish” to complete the process.

SCSI Controller Choice and Step-by-Step Results of the 2 TB Limit

Another key setting you meet when you add a physical drive is the SCSI controller type. By default, Workstation uses the LSI Logic controller.

However, in some cases, alternatives like BusLogic or LSI Logic SAS can also come into play. Controller choice directly affects both performance and the maximum size limit.

As of 2026, current Workstation Pro releases can reach an upper limit of up to 8 TB for virtual units. However, this limit varies based on controller type.

For example, the BusLogic controller tops out at 2 TB. On top of that, LSI Logic controllers allow up to 8 TB. Also, NVMe controllers allow up to 8 TB. In raw mapping, the case is different: Workstation applies a hard 2 TB limit for raw storage.

The practical result of this limit is this: you cannot attach a medium above 2 TB as raw. If you try, VMware either rejects the process or gives access to only the first 2 TB of the unit.

The rest of the space stays out of reach. So if you work with large storage units, you should consider alternative methods.

Key Limits: The 2 TB Wall, BitLocker Risk, and Disk Signature Clash

The risks of raw mapping are not just about a wrong step. Structural limits and encryption layers make this method fully unusable in some cases. In this section, I will detail the three biggest blocks you meet most often.

The 2 TB Limit: When It Applies and How to Beat It (or Not)?

The 2 TB limit is the strictest rule of raw mapping. This limit comes from the addressing architecture of the Workstation rawDisk descriptor. Below, the table sums up when this limit applies and what happens when you try to beat it.

So is there a way to beat this limit? Short answer: no in Workstation. Long answer: for media above 2 TB, you should take a different approach.

For instance, split the unit into 2 TB parts. Make each part a separate physical drive. Also, read the steps to increase VMware disk capacity. However, this method makes management complex and cuts the performance gain.

As an alternative, you can consider conversion methods. You take the physical medium into an image file. After that, you convert this file into a virtual unit.

This method is a cleaner way to beat the 2 TB limit. Still, this process removes the direct access gain. So if your performance hope is high, you must accept this trade-off.

Deadly Risk of Adding Raw Disk to BitLocker and Encrypted Disks

BitLocker encryption is the most dangerous crossing point of raw drive use. You attach an encrypted medium to a virtual machine as raw. However, in this case, the BitLocker pre-boot authentication mechanism cannot come into play.

The reason is that the virtual machine cannot reach TPM (Trusted Platform Module) hardware directly. In this case, even if the guest operating system sees the unit, it cannot reach its content.

Worse, BitLocker sometimes marks the medium as “encrypted and locked.” The host operating system cannot notice this state and may try to write to the unit.

This clash leads to corruption of encryption metadata. As a result, neither host nor guest can reach the data on the storage. If you have no recovery key, you lose the data for good.

The only safe way to remove this risk is to disable encryption before you attach the physical drive. Turning off BitLocker requires the decrypt process to finish. This process can take hours based on unit size. So do not rush and do not interrupt the process.

On the other hand, if the data on the medium is not critical for you, you can fully remove BitLocker. Also, if you use the unit only for tests, a fresh format may be more practical. However, even in this case, the risk of a signature clash between host and guest remains.

Disk Signature Clash and Duplicate Disk Error

A disk signature is identity data. This info sits at the start of every medium. Also, the operating system uses this info to identify the unit in a unique way. In raw mapping, both host and guest see the same physical device. If both sides read the same signature, Windows detects a clash. As a result, Windows takes one of the units offline.

This state often shows itself with this error message: “The disk is offline because it has a signature collision with another disk that is online.” The error appears mainly after cloning or a snapshot. This happens because the clone process also copies the signature of the source unit. When two media have the same signature, Windows disables the second one for safety.

To fix it, you should use the diskpart tool. In an admin command prompt, type diskpart, then list the media with list disk. Select the problem unit with select disk X and run the uniqueid disk command.

You can clear the clash by setting a new signature value. As an alternative, you can also right-click the unit in the disk management panel and use the “Online” option. This action triggers Windows to create a new signature.

Hands-On Visual Guide: Creating a VM with a Raw Disk

Now that we understand the theory, we will go step by step with real screenshots. By studying the images with care, you can apply the process on your own system one to one.

Prep Stage: Target Drive Detection and Admin Rights

Step 1

First, find your target storage unit. Open the “This PC” window in Windows Explorer. Note the drive you want to attach. In our example, it shows as SANDISK (E:). Always check the unit letter and capacity.

Step 2

Next, right-click the VMware Workstation shortcut. From the menu, select “Run as administrator.” This step is vital for permits to access the physical device. Without rights, the raw mapping process fails.

Step 3

When the app opens, make sure the target unit is offline. You can remove the drive letter with the Disk Management panel.

In the image, a red box highlights the SANDISK unit shown as Disk 1. To prevent a clash between host and guest, do not skip this step.

Virtual Machine Hardware Setup with the VMware Wizard

Step 1

To create a virtual machine, choose “Create a New Virtual Machine.” In the wizard that appears, select “Custom (advanced).” This choice gives full access rights to hardware settings.

Step 2

On the hardware compatibility screen, pick a current release. For example, you can use “Workstation 25H2 or later”. In this way, both performance and hardware support stay at the top level.

Step 3

For the operating system install, select “I will install the operating system later”. This step lets us set up a new VM without harming the current operating system. Leaving the install for later is a safer approach for raw mapping.

Step 4

Set the guest operating system type. In our example, we picked “VMware ESX”. You can pick the one that fits your scenario. This choice helps VMware optimize hardware profiles.

Step 5

Give your virtual machine a name and set its location. For example, you can use the name “VMware ESXi”. Pick a folder with enough space as the location. This step prevents file clutter.

Hardware and Resource Assignments

Step 1

Assign the CPU core count. For example, you can pick 2 processors and 4 cores (8 total). You can raise or lower this number based on your need. Too much assignment can lower host performance.

Step 2

Set the memory amount for the virtual machine. In our example, we picked 6144 MB (6 GB). Take care not to exceed the amount your operating system recommends. Otherwise, you will strain your host system.

Step 3

Pick the network type. In our example, I selected “Use network address translation (NAT)“. This choice lets the VM reach the outside world through the host.

If you want an isolated network, you can choose the Host-Only option.

Step 4

Set the I/O controller type. Select the recommended “Paravirtualized SCSI” option. This controller offers better performance on modern operating systems. Some old systems may need LSI Logic.

Step 5

Pick the disk type. The “SCSI” option is ideal for most scenarios. But you should pick NVMe for apps that need very high speed. However, SCSI is usually more compatible in raw disk mapping.

Physical Drive Mapping and Raw Access Parameters

Step 1

On the disk selection screen, select “Use a physical disk (for advanced users)”. This is the key step that enables raw access. We will not use the standard virtual disk options.

Step 2

Pick the physical device. In our example, we picked “PhysicalDrive1.” Select the “Use entire disk” option. If you want to attach only a specific partition, you can use the “Use individual partitions” option.

Step 3

Set a name for the disk file. This file is the .vmdk descriptor that holds only mapping info, not real data. For example, you can use the name “VMware ESXi.vmdk”. Check the settings and click the “Finish” button.

Setup Check and .vmx Parameters

Step 1

When the wizard ends, a summary screen appears. Here, check the memory, CPU, and disk settings one last time. Make sure the physical drive is set up the right way. Then click the “Finish” button to create the VM.

Step 2

After you create the VM, check the hardware list. On the Hard Disk row, you should see “Using device \\.\PhysicalDrive1.” This phrase shows that the raw mapping succeeded.

Step 3

Finally, confirm that VMware wrote the setup correctly in the background. Right-click the VM from the left menu and select “Open VM directory”. In the folder, find the configuration file with a .vmx extension.

Step 4

Open the .vmx file with Notepad. Look for the line scsi0:0.deviceType = "rawDisk". This parameter proves that raw access is active. If this line is missing, you must redo the process from the start.

Step 5

When the process ends, check the target unit state in Windows Explorer again. If the drive letter is gone, the host cannot see the unit. This shows that the virtual machine uses the storage in a safe way.

Performance Truth: Is Raw Disk Really Faster?

The most wondered side of raw drive use is the performance promise. Many sources on the internet claim that raw disk is “much faster.”

However, real-world tests show that this claim depends heavily on conditions. Now, we will put the performance hope on a realistic base.

Raw Disk vs. Virtual VMDK: I/O Depth, Caching, and Delay Comparison

Raw mapping bypasses the hypervisor file system layer. This shortens the input-output path and in theory cuts delay. A virtual unit, on the other hand, works through the host file system.

First, the hypervisor handles every I/O request. Then the host operating system handles this request. At last, the physical storage handles this request. These extra layers can create clear delay, mainly in small and random I/O.

As you can see, the biggest gain of raw drive access is the short I/O path. However, you do not feel this gain to the same degree in every workload.

In sequential read/write work, the gap is minimal. Database work with high random I/O density can make the raw disk stand out. Also, review other VMware virtual disk performance settings.

When Is the Performance Hope Not Realistic?

Raw drive use is not a cure-all. In some cases, the performance gain never happens or is not as big as you expect. Here are the main cases where this hope is not realistic:

• If the host side already has an NVMe SSD: Modern NVMe drives offer very high IOPS and low delay. As a result, the extra load of the hypervisor layer stays unimportant in practice. In this case, moving to raw drive use does not give a notable gain.
• If the workload is mainly sequential I/O: In sequential work like large file copy, fixed-size VMDK shows performance very close to a physical disk. Also, VMDK delivers performance very close to a physical drive in sequential work like video render or backup.
• If the host side has heavy resource use: Raw mapping turns off the host cache. This can lower the overall host performance. The effect becomes clear, mainly if you run more than one VM.
• If the unit is near the 2 TB limit: Even in large media below the limit, addressing efficiency can drop. This can overshadow the performance gain.

So before you move to raw drive use, you should confirm whether the current bottleneck is really in the storage layer.

If a bottleneck comes from CPU, memory, or network, changing the medium type does nothing. Do not make this decision without performance tests.

Rollback Protocol: Removing the Physical Drive from the VM and Giving It Back to the Host

Removing the physical drive in a safe way is just as vital as adding it. A wrong removal step can make the host operating system fail to see the unit or cause signature issues. Now, let us go through the rollback protocol step by step.

Remove the Disk from VM Settings: What to Do Without Deleting the .vmdk File

The first step is to fully power off the virtual machine. You cannot do the removal while the VM runs. After the VM powers off, open the virtual machine settings.

On the Hardware tab, select the physical drive you want to remove. Click the “Remove” button. VMware will take the descriptor out of the VM setup.

However, here is a point you should note: the Remove action does not delete the .vmdk file. It only takes it out of the VM hardware list. The file stays in the VM folder.

If you delete the file by hand, you may hit a problem when you want to attach the same medium again in the future. So before you delete the file, make sure you really do not need it.

After you remove the mapping, you can restart the VM. However, the host operating system may still see the unit as “in use.” In this case, you should open the disk management panel and check the medium state. If the unit looks offline, right-click and use the “Online” option.

Host Cannot See the Disk: Restoring the Drive Letter and Fixing the Duplicate Disk Problem

In some cases, after you remove the medium from the VM, the host operating system does not see the unit. This usually comes from the drive letter being gone.

To assign a drive letter to the unit again, open the disk management panel. Right-click the storage unit. Then use the “Change Drive Letter and Paths” option. Finally, click “Add” to assign a new letter.

If the system marks the unit as “duplicate”, a signature clash is present. In this case, you must recreate the signature with the diskpart tool.

In an admin command prompt, follow these steps: diskpart → list disk → select disk X → uniqueid disk. Clear the clash by setting a new GUID.

Decision Tree and Scenario Matrix: When Not to Use Raw Disk?

Raw mapping use is not the right answer in every scenario. In this section, we will make clear when you should avoid raw disk and what the alternatives are.

Goal-Based Decision Flow: Four Scenarios, Four Different Results

The decision flow below sums up four typical scenarios you may meet and the best approach for each one.

1. Scenario: Open a dual-boot Windows setup in a VM. The target medium is the physical drive that holds Windows. Result: You can use a physical disk, but only if BitLocker is absent and the unit is under 2 TB. Otherwise, VMDK conversion is safer.
2. Scenario: Get high IOPS for a database test. The target is a non-production test medium. Result: A physical disk makes sense, but if the host has an NVMe SSD, the gap may be minimal. Run a benchmark first.
3. Scenario: Attach a medium that holds production data to a VM. The target is a storage unit with critical data. Result: Never use raw mapping. The risk of data loss is too high. You should pick VMDK conversion or network sharing.
4. Scenario: Present a medium above 2 TB to a VM. The target is large-capacity storage. Result: You cannot use a physical disk (2 TB limit). You need partitioning or VMDK conversion.

This flow shows which factors come first when you decide. Data safety must always come before performance. If a scenario has a data loss risk, take the physical disk option off the table.

Risk-Benefit Matrix: Raw Disk, Virtual VMDK, and Conversion Method Compare

The matrix below puts the three methods side by side in terms of risk and benefit. You can use this table as a quick reference when you decide.

The most important result the matrix points to is this: raw mapping makes sense only if performance is critical and data safety is second.

Otherwise, fixed-size VMDK is a more balanced choice in almost every scenario. The conversion method, on the other hand, is ideal for those who need portability and snapshots.

Further Reading Sources for Raw Disk

For those who want to study the topics in this guide in more depth, I suggest a few authoritative sources. Broadcom official docs offer the most current and reliable steps for the physical drive add process. In particular, the article Broadcom KB 308502 serves as a reference for fixing the “Physical Disk is already in use.” error.

For official tables on size compatibility and controller limits, you can review the Broadcom Disk Size Compatibility page. This page clearly shows which controller allows which size.

For more technical details on signature clashes and RDM mappings, you can look at Microsoft signature clash docs. These sources will give you a solid base for the troubleshooting process.

Adding a Physical Disk in VMware: Risks, Fixes, and Everything You Need to Know

Conclusion: Should You Add a Physical Disk or Pick an Alternative?

The moment of choice has come. Physical disk use is a strong tool in the right scenario. However, in the wrong scenario, it leads to serious data loss and hours of recovery work. So when you decide, you should act on data, not emotion.

One-Sentence Decision Summary

Use a physical disk if your target storage unit is under 2 TB and has no BitLocker encryption. Also, pick this path if you can take the data loss risk. Otherwise, create a fixed-size VMDK. As an alternative, you can pick the conversion method.

Short Goal-Based Recommendation Table

Last Checklist Before You Apply

• Did you back up the target storage unit?
• Is the unit under 2 TB?
• Did you disable BitLocker?
• Did you fully power off the virtual machine?
• Did you run VMware as admin?
• Did you remove the drive letter of the target unit?
• Did you put the medium in offline mode?
• Did you pick the right PhysicalDrive number?
• Did you check the SCSI controller type?
• Did you review the rollback protocol (removal steps)?

Do not start the process before you check every item in this list. Each item exists to protect you from a potential disaster.

Keep in mind: raw mapping does not open a door with no return. But if you do it wrong, closing that door will be very hard.