Data Centers optimize

Transferring files to vSphere VMs without using guest networking

In this blog post, Rickatron shows how to transfer files to a VM without using the guest TCP/IP address.

Depending on a number of factors, moving content to a virtual machine may not be able to use the VM’s network interface. This can be due to firewall restrictions which may allow select administration protocols like SSH or Remote Desktop, yet may not allow file transfer protocols like FTP, web access, CIFS or SMB.

I recently read a great post by fellow blogger Eric Siebert where he shows one way to move files to vSphere VMs without using the IP interface. Eric’s tip discussed creating an .ISO file that is mapped to the VM’s inventory, with the .ISO file having the files needed by the guest operating system. Eric’s post inspired me to come up with a few additional ways to transfer files to the guest VM without using the networkfor whatever reason the network isn’t available.

For vSphere environments, we don’t have the easiest mechanism to do this: shared folders. The shared folder technique is common in the Type 2 hypervisor space with products such as VMware Workstation and Oracle VirtualBox. vSphere environments don’t have the shared folder mechanism, however. Outside of the .ISO mounting trick, there are still some additional options to move files to VMs without leveraging the VM’s IP address.

iSCSI LUN mount

If you have a SAN controller that you are comfortable provisioning temporary LUNs upon, it may be handy to make volumes and assign it to a VM for a periodic file exchange. There are options with this process, specifically; the iSCSI Initiator in the guest VM can be used to access the LUN that contains the formatted volume. The iSCSI initiator in Windows is shown below in Figure A. The connect button will latch a LUN onto the local drive inventory of a Windows system:

Figure A

iSCSI Connection for Inactive LUN

iSCSI Connection for Inactive LUN

This can also be done at the host level via a raw device mapping (RDM). The RDM would be presented directly to the VM from the ESX(i) host, and the guest VM would rescan the bus and see the virtual disks in its inventory. To prevent any housekeeping and stale data challenges, consider using a virtual SAN controller or otherwise development-class of storage for a practice like this.

Map a VMDK disk

If you have made up a VMDK disk that has the files that are needed by the VM, you can add that individual VM to the inventory of the VM. The VM can be added dynamically (hot-add) to the running VM, and if a file system is on the VMDK that is recognized by the VM, it can access it immediately upon rescan of the virtual SCSI bus. There are two caveats to this practice related to removal and housekeeping. There is no hot-remove that can be done through the UI of the vSphere Client, which means the VM would have to be powered off to have the added VMDK removed. Secondly, this may lead to a littering of un-inventoried VMDKs on datastores in the vSphere infrastructure.

RDP drive redirection

In the case where certain administrative protocols like Remote Desktop are permitted, we can leverage the drive redirection capability to permit file transfer to the VM. This is only permitted for Windows systems, however. Figure B shows how drive redirection is configured on the connection panel: Figure B

RDP Drive Redirection Configuration

RDP Drive Redirection Configuration

If you want to disable drive redirection via Group Policy for RDP, check out this blog post of mine earlier on this topic.

One problem, many solutions

One of the things I love best about virtualization is that there are a number of ways to solve many problems. Do you employ any special techniques to transfer files to VMs without using native file transfer over the guest VM interface? Share your comments below.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

0 comments