Job Coding Feed
This is a walkthrough of setting up virtual Linux machine hosted by Hyper-V and being able to share files between the host OS and the Linux machine. For those curious on what this post will accomplish, here is a breakdown of what will follow:
- Setup a internal virtual switch in Hyper-V
- Allow internet connection sharing to the internal virtual switch
- Connect to the Linux virtual machines via PuTTY
- Mount a Windows drive so that the Linux machine can access those files
I’m not new to Linux virtualization on client Hyper-V. I’ve written about my struggles before. When I first wrote it, I had a whole list of complaints that made my life difficult, but if you read the entire post, the latter half contains workarounds for my issues. Now, after more than a year in passing, I’ve decided to write a little tutorial for those who are having troubles working with Linux virtualized through Hyper-V.
It should be noted that when I say “client Hyper-V” I’m talking about the feature starting in Windows 8 that allows non-server grade computers to partake in virtualization. Gone are the days of partitioning drives in order to dual boot operating systems. Now the only limitation is how many operating systems one can running simultaneously before they exhaust RAM.
There is the traditional version of Hyper-V, which is ran off a server and boosts additional features dealing with recovery GPU virtualization, but for the most part, they are the same.
These instructions should work for other versions of Hyper-V and other versions of Linux, but these are the requirements for client Hyper-V.
- 64-bit system that has Second Level Address Translation (SLAT).
- 4 GB of RAM
- Client Hyper-V is enabled. In Powershell code:
Enable-WindowsOptionalFeature –FeatureName Microsoft-Hyper-V -All
- Administrator privileges on the Window’s and Linux boxes
Navigate to the folder that is supposed to be accessed from the Linux machines and enable sharing. Remember the UNC path to that location. Generally it is of the form
\\%COMPUTERNAME% followed by the file path without
%SystemDrive%. For instance, I store my source code in
C:\Projects, which when shared is
Next, navigate to the Hyper-V and create a new virtual switch connected to the internal network. I chose the name “Internal Switch”. Having an internal switch allows communications among virtual machines alongside host communications.
Now, enable Internet Connection Sharing (shown in next screenshot). The internal switch that was previously created will be used as the wired hub. What this means is that the host and the virtual machines can access the outside internet, but the outside world cannot access the virtual machines. This even includes other computers on the same network connection as the host. This is a pro and a con, depending on how one looks at it. The virtual machines are secure from outsiders, but to work on the virtual machines when not on the host, one would have to RDP into the host first. This sounds like a pain, but in reality, I have never needed to work on the virtual machines when I’m not on the host.
Always install from an .iso image, as it is by far the easiest and quickest. In the following screenshots, I’m installing Fedora 18 from an .iso image. I normally run my Linux virtual machines at 512MB of RAM. It doesn’t sound like much, but there has only ever been a couple instances when I’ve needed to restart a virtual machine with 1024MB (ironically, it was this installation of Fedora and F# when I couldn’t wait for swap space). Otherwise, I can run a node and flask webserver at the same time and still have plenty of RAM left for development.
At this point, I’m assuming that the Linux version is installed. The first order of business is to start the ssh daemon. Hyper-V doesn’t have the best support for Linux machines, and so there are severely limited screen resolutions and third party products such as connection via VNC doesn’t solve this problem. By allowing clients to connect through ssh, we can connect the Linux and Windows host through PuTTY.
service sshd start started the ssh daemon on Fedora.
Next step is to point PuTTY to our Linux machine. Execute
ifconfig eth0 on the Linux machine and copy that IP address into PuTTY and login.
This is only a terminal view of the Linux machine. If a graphical interface for programs is necessary, enable X11 Forwarding using Xming and PuTTY
To enhance the colors of the terminal, I recommend 4bit.
Mounting the Shared Folder
At this point, if there is no need to mount a shared folder, then there is no need to continue.
/etc/hosts and append a line that contains the IP address of the host machine and the host machine’s name. This allows us to refer the host machine by name instead of IP address. For instance, here is what my hosts file looks like.
I recommend storing the username and password to access the shared in a secure file on the Linux machine in the following format (I called the file .smbcredentials). We’ll use this file to connect to shared folder.
/etc/fstab the following line is added, which allows the shared folder to be
mounted. Only the first two paths should be of interest in the file. The first one is where the share is located and the second is where to mount it on Linux machine.
//Nick-PC8/Projects /mnt/Windows cifs credentials=/home/nick/.smbcredentials,iocharset=utf8,soft,file_mode=0777,dir_mode=0777,uid=1000,gid=1000 0 0
Finally, to top everything off, the last commands makes the directory and mounts the shared folder.
mkdir /mnt/Windows mount /mnt/Windows
There are a couple of annoyances and enhancements. An annoyance is clock drift. When the host machine is put to sleep, the clocks on the Linux virtual machines stop. Then when the host machine is awaken, the Linux virtual machines don’t correct themselves, or if they do, it is in small corrections, as changes in large amount of time can cause undefined behavior in programs. Thus, whenever I resume work on the virtual machines I execute
sudo ntpdate pool.ntp.org, which forces synchronization of the time. I have not noticed any undefined behavior.
An enhancement that applies to all users of PuTTY is a terminal multiplexer, which essentially allows for multiple terminals in a single PuTTY session. Instead of having five PuTTY sessions open and juggling them; simply have one with five terminals.