In ESXi 6, how do I make a .vmdk with a createType="fullDevice"

[kbulgrien4freed]

I want a VM to be able to attach a physical device so it can initialize it.  I searched and found

references to the `vmkfstools` utility but suspect that this is not the right tool to use as I cannot

seem to locate command-line arguments that seem to correlate with "fullDevice" .vmdk files.

I also found a reference to a tool called `vmware-vdiskmanager`, but I cannot find it in my ESXi

host.

From past messages it seems that sometimes mapping physical disks into a VM is discouraged,

but a goal here is to allow a VM to create a disk image that will ultimately be dismounted and

used elsewhere.  Presently, physical systems to do this task, but there is some motivation to

try to move this capability into a VM.

It is starting to appear that this might be rather clunky as /dev/disks shows the device node

name as containing details specific to the physical media.  For now, that is not a detractor.

I'm using the Essentials Kit and have a 6.0.0 host with access to the host command-line, web,

and non-web, clients.

In summary, what client or command-line tool process is used to create a "fullDevice" that can

be assigned to a VM?

[a_p_ · Accepted solution]

Welcome to the Community,

I think that what you are looking for on ESXi is a RAW device mapping. The "FullDevice" type is/was used for products like VMware Workstation.

see Raw Device Mapping for local storage (1017530) | VMware KB

André

[kbulgrien4freed]

Hmm.  Interesting.

https://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf refers to ESXi and lists "fullDevice" as a valid createType.

'vmkfstools' was used as described in that document and the disk even showed up in the Windows 7 VM.  The process being moved into the VM uses Windows 7 'diskpart' and troubles were encountered including a 0x80070057 error level.  While digging into that error, by trying various approaches to try to resolve the problem, at some point a message occurred:   "Virtual Disk Service error: The specified disk is not convertible.  CDROMs and DVDs are examples of disks that are not convertable."  As it seemed odd to have encountered a restriction that seemed to correlate what I'd done with CDROMs and DVDs, I got to wondering if I had picked the wrong method of exposing these disks to the VM and went searching for more clues.

Presently it seems plausible that the 'diskpart' 0x80070057 error level is likely somehow associated with using 'diskpart /s script.txt' non-interactively.  Running 'diskpart' interactively by manually issuing disk configuration commands seems to work fine, so perhaps I went down a rabbit trail just because something that works on an ancient Windows XP system stopped working when I tried to re-deploy the scripted process under Windows 7.

At this point, it seems prudent to make sure the VM can do what needs to be done to the media even if the process has to change (due to VM OS differences).

Thanks.  I'll update the thread when it becomes evident that the VM can perform intended operations.

[kbulgrien4freed]

Indeed, it was possible to partition, format, write the disk from within the VM and then use/boot it on other hardware.

There was apparently no need to use createType="fullDevice".

Caveat:

RDM media not attached to a dedicated virtual controller appears to present difficulty when attempting 'detach' of the RDM media while the VM is running.  The referenced document does not point this detail out, though it is alluded to, almost as an afterthought, in a related blog post:  RDM mapping of local SATA storage for ESXi | David Warburton (see the note below step 8).  When adding RDM media to the VM Virtual Hardware, by default the new device is attached to controller 0.  When a dedicated controller is not already configured in the VM, add one before adding new RDM media.  Then, while adding the new RDM media to the VM, expand the new disk configuration detail and select the dedicated controller for the Virtual Device Node.  Also consider Disk Mode: "Independent - Persistant" and Sharing: "No sharing".  These changes from the default settings allow the RDM media to be "ejected" from within the VM while it is running.