Finish Windows VM - BYUHPC/7lbd GitHub Wiki

These next steps will all be changes that will need to be made permanent to the Windows VM that you built previously. Launch the VM read-write inside a network namespace to make these changes. This may be done by creating a maintenance copy of the 7lbd_ood code in your own sandbox and launching the VM read-write. These customizations need to be done on a cluster node inside of a 7lbd job so the SMBD mounts will be available. Make sure that you are working on a copy of your VM and make a habit to keep the last few copies of your VM in case you make a huge mistake. Also make sure that the VM image file pointed to when creating the overlay file in script.sh.erb is a soft link as described in the Windows Image Management article.

Set a "permanent" password for user1

Previously, the password for user1 was set to something temporary so the password could be left in test scripts. Now that the initial testing is complete, set the password for user1 to something more permanent. This password will still be needed to do maintenance on the user1 account.

Network drives

Configure network drives on the VM by creating persistent mapped drives and adding a hosts file to the VM since there is no DNS server.

This line of code in the script.sh.erb when qemu is run is key to understanding the network situation for mounting Samba shares:

-netdev user,id=net0,net=169.254.100.0/24,dhcpstart=169.254.100.15,host=169.254.100.2,hostfwd=tcp::3389-:3389 \

Among other things, the above netdev parameter in the qemu-kvm command line states what IP address the host computer will use inside the network namespace. In this case, the host IP address is set to 169.254.100.2. That means our samba shares will be accessed at the address \169.254.100.2\sharename.

This IP address won't look exceptionally great to our users, so let's edit the c:\windows\system32\drivers\etc\hosts file on our Windows VM as Administrator and create an entry for 169.254.100.2. This is the same concept as editing the /etc/hosts file in Linux as root. In our case we added the following line at the end of the hosts file:

169.254.100.2  orc

Now our shares are accessible at the path \\orc\sharename instead of \\169.254.100.2\sharename

Now as user1, in the File browser, right click on "This PC" and select "Map Network Drive". Select a drive letter, fill in the path to your samba share (\orc\sharename) and be sure to select "Reconnect at sign-in". So for instance, if we set the h: drive to be \orc\home, and in our samba config in OOD we set the "home" share to be \home$USER, then the h: will be every user's own home folder on the Linux host, but inside the VM. Repeat this process for as many shares as you need to set up.

map_drive

Windows licensing

There are several options for activating Windows licensing. There are Enterprise licenses for air-gapped Windows systems. Another option is to boot the VM at least once every 6-months read-write with network access (or via proxy server) to your institutions KMS server. Regardless of what you do, this needs to be addressed before your VMs stop working. There are so many ways to do this, but we just remind you that this will be a problem that needs to be solved.

Software installation

Install all necessary software. Make sure to log in as user1 and launch all of the software and have sane defaults as part of the user1's profile on image. This will speed up logins and software load times for everyone if this has already been done on the user1 profile.