Using cloud services as glorified drive: virtual iSCSI targets (part VI)

[continued from part V]

Since recent vintage Windows Server machines can function as “virtual” iSCSI targets, a storage solution can be built out of any cloud hosting provider such as Amazon EC2 or Windows Azure. Simply request new computing instances running the appropriate Windows server release, then configure the OS with an iSCSI software target accessible from the Internet. This post walks through the steps, assuming remote-desktop connection to the server. (The same work flow can also be automated with PowerShell scripting or using a server management console pointed at the VM instance.)

Broadly speaking, there are two parallel tasks, one for setting up the target and the initiator. These are somewhat intertwined because target configuration requires an identifier for the expected initiator.

Creating an iSCSI target

  • Add the iSCSI target role to Windows Server. Following the pattern started in Server 2008, the operating system has a modular feature set which can be activated on demand, instead of containing the kitchen sink of functionality. This will add a “File and storage services” option to the Server Manager dialog, used in the next series of steps.
  • Select the link to create a new iSCSI virtual target. This will kick start a wizard.

iSCSI_target_disk_setup     iSCSI_name_initiator

  • The first step is creating a virtual disk. That’s right– iSCSI targets in Windows are backed by VHDs. This becomes a case of nested disk virtualization: a virtual machine running Server 2012 and backed by VHD  image– or equivalent format for VMware, Xen etc.– itself will include a virtual disk on its file system. We must go deeper.
  • The dialog will also prompt for the expected ID of initiators connecting to this target. There are multiple ways to identify an initiator, none of them particularly intuitive. Easiest option is to copy paste the iSCSI Qualified Name or IQN style address that is automatically generated by each Windows instance acting as initiator. This name can be obtained from the “Configuration” tab in iSCSI Initiator Properties dialog, which is shown in the screenshots below. (For now skip any additional authentication settings.)
  • Once the target is created, both the virtual disk and the target backed by that disk will appear in the iSCSI node under Server Manager.

iSCSI_target_done   ServerManager_iSCSI_status

Connecting to the iSCSI target

  • Start the iSCSI Initiator application built into Windows 7/8.
  • Easiest way to locate targets is letting Windows perform the discovery work. In the iSCSI Initiator Properties dialog, switch over to the “Discovery” tab and click on “Discover portal” button to specify the network location of the remote VM running Windows Server. This could be an IP address or DNS name. In the example below it is pointing to a local virtual machine addressed in private network space.

Initiator_DiscoveryTab    Initiator_FoundTarget

  • Switching back to the “Targets” tab and if necessary clicking “Refresh” shows the iSCSI targets located at that portal. A single server can offer multiple iSCSI targets; in the above example we only configured one target backed by one virtual disk.
  • Clicking on “Connect” brings up a dialog, with the option to add this target to favorites already opted-in. Leaving that checkbox on is recommended. Windows will attempt to reconnect to these targets after reboots and similar events resulting in disconnect.


  • Finally after clicking OK to confirm the connection… nothing. An observant user may notice the status switched from “inactive” to “connected” but the rest of the system appears unaware of any new storage appearing. No new drives show up in Explorer, not even a notification about removable drive being connected. What happened?  The problem is that VHD created is a blank slate. Not only does it contain no data, it has not even been formatted with a filesystem such as NTFS. Switching over to the Disk Management snap-in (accessible from Computer Management) shows that a new disk has appeared but is listed as “Not initialized.”


  • Fixing that requires a few more steps. These are strictly one-time initialization procedures that permanently setup a file-system structure inside the VHD. They will not have to be performed again when connecting to the iSCSI target in the future. First one is right-clicking and selecting “Initialize disk” from the context menu to initialize the disk. (For this application, choosing GUID partition table over MBR is fine, since the disk can only be accessed by recent vintage Windows instances that support iSCSI anyway.) Second part is creating one or more partitions on the initialized drive. Simplest approach is to allocate the entire space to a single primary partition. Finally the partition is formatted using a file-system such as NTFS.
  • Once the formatting is complete, a new disk will appear in Explorer corresponding to the remote iSCSI target, with the volume name and drive letter assigned in the formatting step. This drive is now usable from any application that can leverage local , which is transparently routed over the network to the remote virtual machine containing the iSCSI target disk.
  • More importantly for our purposes, the mapped disk supports BitLocker-To-Go encryption. Right-clicking on the disk icon will bring up the option to enable BitLocker full volume encryption.

After BL2G is enabled, all data written to the iSCSI target is automatically encrypted. The cloud provider hosting the VM behind that target sees only encrypted blocks being output by BitLocker. This is an important point: even though there is a virtual machine running a fully functional Windows Server operating system to emulate the iSCSI target, the encryption is not done there. BitLocker is not applied at the remote Windows Server VM. Doing so would be futile for protecting against attacks from the service provider. With commodity hardware, cloud platform has full control over the execution of any code inside the VMs it hosts and can subvert any encryption. In this design all cryptography takes place locally on the local user machine. For all the fancy capabilities available in that remote VM running Windows Server, it is only used to store opaque blocks encrypted before they are released to the cloud and only decrypted once they reach the user machine.

[Continued: iSCSI caveats]


3 thoughts on “Using cloud services as glorified drive: virtual iSCSI targets (part VI)

  1. Since using iSCSI on private Windows server requires this server to be up, isn’t it easier to access remote VHD there just attaching it on client PC through plain old network share?

    • addition: requirements to hide non-encrypted data from virtual host are satisfied in this way. access to VHD will be done on block level, not file level

    • As in create a share on the remote Windows server, place a VHD file in that share, mount the share locally and then mount the VHD from inside?
      Yes that would work too. That solution is identical to the previous one in terms of keeping a VHD in the cloud. But the CIFS protocol used to access it from SMB share would have similar problem of requiring access to large sections of the file. (The emulated virtual disk is being accessed at block level, but the backing file at the remote-share is not. Network shares accessed via SMB/CIFS are not block devices.)

      iSCSI has the advantage that access is at block-level end to end.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s