I'm trying to setup a VMware Virtual Machine under a Windows 10 host.

I currently have 1 hard drive split into 2 partitions, currently using Ubuntu with dual boot.

I would like to mount the Ubuntu as a guest in Windows host.

I have been trying to setup the Ubuntu partition using the Physical Disk option under VMware (I've tried IDE, SCSI, Sata). If I tell the VMware to use entire disk, I will get "current disk is in use" message. If I select only the relevant Linux partitions, it will say "Cannot find operating system".

What's strange is my Linux partition is showing up as "Efi system" under File System column, whereas I thought it was supposed to say "Linux" under File System. Should I try to first change the file system of that partition to Linux instead of Efi? (How would I do that?)

VMware should be able to let me run an Ubuntu partition as a guest even if it is on the same hard drive as the host, right?

Edit: To clarify, the above info is reported by VMware-Workstation.

However, under Ubuntu Gparted this is how my partitions look like:

My current SSD harddrive is currently setup this way (according to Linux GParted)

  • /dev/nvme0n1p1 ntfs (diag)
  • /dev/nvme0n1p2 fat32 (boot,esp)
  • /dev/nvme0n1p3 unknown (msftres) [Microsoft Reserved Partition whatever that is]
  • /dev/nvme0n1p4 ntfs (msftdata) [This is the Windows 10 partition]
  • /dev/nvme0n1p5 ext4 (boot, esp) [This is my Ubuntu partition]
  • /dev/nvme0n1p6 linux-swap
  • /dev/nvme0n1p7 ntfs (hidden, diag)

GParted also reports that mount point / is on nvme0n1p5 & mount point /boot/efi on nvme0n1p2.

[now I'm confused, did my Ubuntu machine boot from nvme0n1p5 (with flag boot) or nvme0n1p2 (with mount point /boot/efi)?]

Anyway, I've tried to attach both partitions to Physical Disk hard drive option of Windows 10 VMWare-Workstation but the machine still won't boot the guest Ubuntu.

I can dual-boot (by switching "hard drive order" in BIOS - [even though there's only one harddrive!]) but what I would like to do is to boot & run the Ubuntu partition from within Windows.

Edit 2:

I think I might be understanding the problem a bit more:

  1. upon first boot, I select Windows 10 EFI as boot option
  2. in windows, I setup a virtual machine to run the second partition in the same hard drive that's currently running as host
  3. but to boot the second partition, I must tell virtual machine setup to run the same EFI boot manager as (1)
  4. it fails to run the EFI boot manager (is it in use?) and drops me to an Internal EFI shell
  5. from EFI Shell I can select a filesystem and cd into /efi/boot and see some .efi files there, but I don't know how to boot from those .efi files.

Can anyone tell me how to boot an .efi file from the Internal EFI Shell?

  • Two questions: 1) What are you using? ([VMware] is a firm, please change the tags to [vmware-player], [wmware-workstation] etc). 2) [u]EFI used a FAT32 partition to boot all OS from. That one might be in use. Can you make more explicit what you mean when you write that linu xis showing up as efi system?
    – Hennes
    Jul 29, 2017 at 16:36
  • Thanks or the reply. 1) VMware-Workstation Trial. 2) I've updated my current hard drive structure in the original post.
    – Azrudi
    Jul 29, 2017 at 19:01
  • I think my problem is the EFI system. I tried Oracle Virtualbox and went through the vboxmanage setup to use a raw disk - and once I've attached the raw disk to Virtualbox, it still won't let me boot as normal or as EFI. 1) booting normally results in no operating system found 2) choosing "boot EFI instead of BIOS" brings me to a strange EFI Internal Shell Menu and I can return to EFI Boot Manager and navigate "Set Boot Option" to find grubx64.efi, but selecting that file does nothing but I'm stabbing in the dark actually.
    – Azrudi
    Jul 29, 2017 at 20:15
  • ESP (EFI system partition) is the partition usually used to store the bootloaders for all operating systems. There usually is only one sunch partition and unless you have a MAC it is formatted with FAT32. Now when I look at /dev/nvme0n1p5 I see it is ext4 and it is your Ubuntu partition. It is also marked esp. That confuses me.
    – Hennes
    Jul 30, 2017 at 9:15
  • re 3). I am out of my depth here. But can you check that the ESP is not already mounted by windows? Most of the time windows does seem to leave it alone (inf act, I had to force my current windows install to map a drive letter to it), but checking newer hurts. Otherwise good post. I hope it gets answered with a proper solution.
    – Hennes
    Jul 30, 2017 at 9:19

2 Answers 2


Some of this has already been addressed in comments, and I'm not an expert on VMware products, but:

Your first problem is the partition type code on /dev/nvme0n1p5. According to your parted summary, this partition has its "boot, esp" flag set. (For reasons that would be a digression, "boot" and "esp" are redundant flag names that refer to the same thing, so they always appear together in recent versions of parted.) In parted, "flags" on GPT disks can be either partition attributes or partition type codes, and the "boot, esp" flag is a type code for the EFI System Partition (ESP). This flag should NOT be set on a Linux root (/) partition -- or on any other Linux-only partition. As the Wikipedia page to which I linked explained, the ESP is a FAT partition that holds boot loaders and related files for all OSes. Your /dev/nvme0n1p5 should use the Linux Filesystem Data type code, which parted identifies as an absence of partition type-code flags on a partition with a Linux filesystem.

At a minimum, you'll need to give VMware access to both /dev/nvme0n1p2 and /dev/nvme0n1p5, but you may want to give access to /dev/nvme0n1p6, too, since that's the Linux swap space. Fixing this partition access issue will not fix your overall problem, but it's likely to be a necessary prerequisite.

To the rest, I strongly recommend you read a bit about how an EFI-based computer boots. Specifically, read at least one, and preferably all three, of the following:

The internal EFI shell you describe is similar to a DOS prompt, a Command Prompt window in Windows, or a Bash shell in Linux. You can use commands like cd to change directories, ls or dir to see files, etc.; most of these commands are borrowed from DOS/Windows or Unix. EFI programs, including EFI boot loaders, have .efi extensions, and you run them by typing their names, as in:


Ubuntu installs its EFI boot loader as EFI\ubuntu\grubx64.efi, although this is usually launched via a pre-bootloader called shimx64.efi. Shim is signed by Microsoft's Secure Boot key and extends the computer's Secure Boot subsystem to enable GRUB and the Linux kernel to boot. You'll need to launch via shimx64.efi if your virtualized environment is set up with Secure Boot enabled. If not, you can run either shimx64.efi or grubx64.efi.

One complication is that GRUB may choke on a view of the disk that doesn't match that of the original disk -- that is, if the real partition 5 appears to be partition 2, GRUB might flake out and refuse to work. If this happens, I recommend switching to another boot loader for at least one environment (real vs. virtualized). If each environment uses its own boot loader, then their configurations can differ radically and the two environments won't step on each other. Also, some boot loaders won't care about changed partition numbers. This is true of my rEFInd boot manager, for instance. I'd like to emphasize, though, that I don't know if GRUB will flake out. Its configuration file does typically include references to partition numbers (which suggests that it might flake out), but it also includes "search" commands that might override those (which suggests it might be OK). Also, I don't know how VMware manages the mapping of partitions; they might keep the same partition numbers, in which case there should be no problems because of this.

Another question is whether the host OS will allow you to map the ESP, since it may be in use or off-limits for this. If so, you may need to create a virtual disk or another partition to be used as an ESP for the virtual environment. You can then copy the boot loader from the real ESP to the virtual one, or install a different boot loader there.

Finally, as described in the readings I've recommended, EFI-based computers rely on NVRAM-resident data to locate the boot loader. Most virtualization software creates "fake" NVRAM data, so a VM won't boot normally unless you create fresh NVRAM entries to point to the boot loader. You can use the EFI shell to launch your OS once, but then you'll need to register the boot loader with the VM. In Ubuntu, you'd use efibootmgr to do this:

sudo efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\ubuntu\\grubx64.efi -L ubuntu

This example records \EFI\ubuntu\grubx64.efi on Ubuntu's /dev/sda1 as a boot loader. You must change the details as necessary for your setup. Note that the disk and partition IDs are those in the virtual machine, not in the host environment.

One caveat with this is that some VMs "forget" their NVRAM entries when you shut them down. This is true of VirtualBox, for instance. I have no idea if VMware does any better. If not, you may need to copy the boot loader to the fallback filename (EFI\BOOT\bootx64.efi) on the ESP. This approach is described in more detail in my page on EFI boot loaders, and I think also in Adam Williamson's blog.

  • Thank you, i'll go over this tonight. Seems very comprehensive. I want to ask this now though, just to clarify : I should be able to type shimx64.efi in its directory in (I think /boot/EFI) the Internal EFI shell and if there aren't any other problems I should normally be able to boot the Linux guest? I will read the blogs and your response in further detail when I get back home tonight. I have removed the boot and esp flag in nvme0n1p5 using the free Minitool Partition Wizard for Windows but still see no difference before your reply.
    – Azrudi
    Aug 2, 2017 at 14:59
  • Hi Rod, I read through the third link. Most of it were a bit over my head at this time but I read the part about the EFI stub loader. I tried to replicate but got weird errors that I don't understand: i.imgur.com/F4RRACw.png It says invalid parameters but I've included all the relevant parameters. Can you help translate in layman terms? Note that I think the EFI partition itself is fine because I can boot Ubuntu if I boot from the BIOS (the one where I press the del key when manufacturer logo appears)
    – Azrudi
    Aug 2, 2017 at 22:53
  • 3
    I've got it to work! Made 3 changes: 1) removed the boot & esp flag with Minitool Partition Wizard, and labelled it as msftdata partition (or Partition ID = Windows Basic Data Partition in Minitool) 2) changed under VM>Settings>Options>General>Version from Ubuntu to Ubuntu 64-bit 3) changed hard drive under VM>Settings>Hard Disk (SCSI)>check EFI partition, root partition and swap partition, then click Advanced button and picked Mode>Independent>Non-persistent Now it works! Without (3) I got "inaccessible hard disk \\.\PhysicalDrive0". Marked this as solution.
    – Azrudi
    Aug 2, 2017 at 23:29

I was having a similar problem, but with two NVMe drives in a Dell Precision 7730.

I had Ubuntu 21.04 installed on one NVMe and installed Windows 20H2 on a different NVMe. I thought I would create an Ubuntu VM in Workstation 16.1 for Windows, and assign the entire already existing Ubuntu NVMe as physical disk for Ubuntu VM.

The problem was, since the Ubuntu NVMe already had an EFI partition, Windows behavior is to automatically install its EFI data in the same location. That caused VMware Workstation to be unable to use the entire Ubuntu NVMe because of the EFI partition being associated with Windows.

I shrunk the Windows drive down as far as I could in Windows Disk Management (the smaller the partition, the faster it can be moved) and moved the partition 500 MB towards the end in Gparted using an Ubuntu live USB. There was also a 16 MB partition I moved 500 MB to the right (towards the end).

I used Gparted to make a 500 MB partition on the Windows NVMe (in the 500 MB space I created by moving the two partitions), formatted it FAT32 and set partition flags to "esp".

Then, I created /mnt/nvme0 and /mnt/nvme1 folders, and mounted the Ubuntu NVMe's EFI partition to /mnt/nvme0, the new Windows EFI partition to /mnt/nvme1. I moved /mnt/nvme0/"System Volume Information" folder and /mnt/nvme0/EFI/BOOTX64.EFI to /mnt/nvme1/"System Volume Information" and /mnt/nvme1/EFI/BOOTX64.EFI, respectively.

I reboot out of the Ubuntu live USB and checked the location of the Windows boot manager in BIOS to make sure it would load from the new EFI partition. Then, I booted into Windows and edited the VM in Workstation.

The settings I currently have which are working are as follows:

Hard Disk (NVMe): Using device \\.\PhysicalDrive0
Disk file: C:\Users\user\Virtual Machines\Ubuntu-NVMe\Ubuntu-NVMe.vmdk

Disk information:
Device: \\.\PhysicalDrive0
Access: Using whole disk
Capacity: 238.5 GB

I was warned by Workstation when trying to use SCSI for a physical disk that it could operate very slowly, so I chose NVMe - but that makes the most sense, anyway, since it is in fact an NVMe drive.

Everything operates normal - Workstation can "take over" the entire NVMe drive, now that each drive has their own separate EFI partitions, and boot Ubuntu from the EFI and boot partitions, utilize the swap, and access the root just as if the drive were booting from bare metal.

The one caveat I would mention is I have not tried to take snapshots using this configuration, but I imagine it is either impossible, or would be very costly in terms of space consumption, so I have not bothered to test it. For that reason, if I were to do this again from scratch, I might choose ZFS as root file system for its snapshot capabilities.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .