9  Virtual Machines

9.1 General Information

9.1.1 Win VM #1

  • Resource Name: PSYCH-GEN-022219
  • Deployment name: optimize_win
  • IP: 128.104.221.25
  • CPUs: 1
  • Cores per socket: 1
  • Memory: 16 GB
  • HD space: 100 GB

9.1.2 Win VM #2

  • Resource Name: PSYCH-GEN-025563
  • Deployment name: supercomputer
  • IP: 10.128.254.117
  • CPUs: 1
  • Cores per socket: 1
  • Memory: 128 GB
  • HD space: 100 GB

9.1.3 Linux VM

  • System: Ubuntu 24.04.3 LTS
  • Desktop Environment: XFCE4
  • Remote Access: RDP (Remote Desktop Protocol)
  • IP: 128.104.50.166
  • CPUs: 1
  • Cores per socket: 1
  • MemoryL 128 GB
  • HD Space: 100 GB

9.1.4 Hardware specs

As of March 2024 CCI KB lists the following hardware specs for VMs:

  • Server: Dell R740XD vSAN Ready Node
  • CPU: Intel Xeon Gold 6258R CPU @ 2.70GHz
  • Memory: Dual Rank x4 PC4-25600R (DDR4-3200) Registered CAS-22
  • Storage: All-Flash vSAN
  • Cache Disks: 1.6TB Flash NVMe PCIe 8GT/s
  • Capacity Disks: 7.68TB SAS 12Gb/s
  • Network: Redundant 25Gb/s SFP28 Network adapters

9.1.5 A note on “Cores per socket” and “available cores”

Conversations with CCI support indicate that all of the hardware cores for a specific CPU are shared among whomever connects to that CPU - not just users on one VM, but any VM with access to that CPU:

“The physical CPUs are shared resources and are managed by the CPU scheduler. The CPU scheduler determines which VMs use the processors and when. It maximizes the utilization of the processors and ensures all VMs get their time on a processor.”

Cores per socket, on the other hand, has nothing to do with the number of cores the CPU has, and for our purposes we leave it at the default of 1: “That feature is available because there are operating systems and applications with license limits based on sockets. In those cases, it may be to your advantage to configure more than 1 core per socket.”

9.2 Administration

The VMs are administered through the CCI Cloud Console.

  1. Visit CCI Cloud Console.
  2. The first thing you should see, should be “Select your domain”. Select “ad.wisc.edu”
  3. Authenticate with your NetID.
  4. After you are logged in, click “Service Broker”.
  5. In the left sidebar is you will see “Deployments”. Click to expand that, and then click “Virtual Machines”.

There are 2 main uses for the Admin console. You can edit the VM configurations, but you can also connect to them if Remote Desktop/ssh are not available.

9.2.1 Editing Virtual Machines

You can edit RAM, HD space (ie boot disk), and number of CPUs.

  1. Follow the steps above to get logged in.
  2. While viewing the list of VMs, click the 3-dot menu for the VM you wish to edit.
    • To edit CPUs and RAM, select “Resize”.
    • To edit HD size, select “Resize Boot Disk”

9.2.2 Connecting to the VM via the admin console

This will only be done if SSH & Remote desktop are NOT available to you. See below for the normal way to make connections.

  1. While viewing the list of VMs, click the 3-dot menu for the VM you wish to connect.
  2. Select “Connect to Remote Console”.
  3. A new browser window will open showing the VM connection.
    • For Windows machines, you must use the item near the top that says “Send Ctrl+Alt+Del” to bring up the login fields.

9.3 Ubuntu VM Setup

9.3.1 Initial System Configuration

The Linux VM was configured with a RDP (Remote Desktop Protocol) using the XFCE4 desktop environment. This setup was chosen for many reasons:

  1. Cross-platform compatability (Windows, Mac, Linux clients)
  2. Supports multi-user (multiple lab members can connect simultaneously)
  3. Stability (XFCE4 avoids Ubuntu 24.04’s Wayland/RDP compatibility issues)
  4. Resource Efficiency (almost double RAM efficiency compared to GNOME)

For visibility, these were the commands that were ran to setup the initial system:

From a ROOT SSH:

# 1. update system packages 
sudo apt update && sudo apt upgrade -y

# 2. install RDP server and desktop environment
sudo apt install -y xrdp xfce4 xfce4-goodies

# 3. configure XFCE as default desktop for RDP users
sudo bash -c 'echo "xfce4-session" > /etc/skel/.xsession'
sudo sed -i 's/allowed_users=console/allowed_users=anybody/' /etc/X11/Xwrapper.config

# 4. enable and start RDP service
sudo systemctl enable --now xrdp
sudo adduser xrdp ssl-cert
sudo systemctl restart xrdp

# 5. open firewall for RDP connections
sudo ufw allow 3389/tcp

9.3.2 Creating User Accounts on the Linux VM

For each lab member who needs access to the Ubuntu VM:

From a ROOT SSH:

# 1. create user account (replace 'username' with NetID)
sudo adduser username

# follow the prompts:
# - Enter password (twice)
# - Press Enter to skip optional fields (Full Name, etc.)
# - Press Y to confirm

# 2. set up desktop session for user's RDP
echo "xfce4-session" | sudo tee /home/username/.xsession

Example:

sudo adduser cjanssen3
echo "xfce4-session" | sudo tee /home/cjanssen3/.xsession

Optional: Grant admin privileges

sudo usermod -aG sudo username

9.4 Connection Information

9.4.1 Granting access

There are 3 steps required before a user can connect to these machines:

  1. Users must be granted access via netID by John or Susan through Manifest which is UW’s Active Directory service.
    • See this KB page for instructions on using Manifest.
    • The manufest group to add them to is called “CCI-GS-PSYCH-GEN-USER”
  2. On the VM, the Administrator must create a user account and give it a password. These user accounts must be “Local” accounts, and cannot be administrators. (NB the administrator password is in Lastpass, both in the lab account and shared with John). To add an account:
    • Click the Start button and Type “Control Panel” to bring up the Control Panel
    • Click “User Accounts”.
    • Click “User Accounts” again, then “Manager another account”
    • Click “Add a new user” and follow all the prompts.
  3. After the user is created, you must also grant this user permission to use Remote Desktop to connect.
    • In the Control Panel search for the word “Remote”.
    • Click “Select users who can use Remote Desktop”
    • An intermediate window may or may not come up. If so click “Select Users” again.
    • Type the user name, then click “Add” and then “Okay”

Keep in mind, if a user needs access on all 3 VMs, steps 2 & 3 must be repeated for each VM.

9.4.2 Connecting (after access is granted)

  • Each lab member must use the account username for the specific VM they plan to use. See Susan to have one created for you. The username you are given will match your netID, and the password will intially be a generic one.
  • It is recommended that you immediately change your VM machine account password to match your netID password, to make it easier to connect going forward. Otherwise it will default to your local computer credentials and you will have to select “Use another account” each time.
  • You must be on a wired LAN machine in the psych building, or authenticated through GlobalProtect.
    • If you are on a campus WIFI, you must use eduroam and not UWNet (the latter is not considered secure enough and connections from it are denied, even through GlobalProtect)

9.4.2.1 Windows machines

  1. Use Remote Desktop using the IP listed above for the VM you are connecting to.
  2. For credentials, use the local account username/password that was created for you.

9.4.2.2 Linux machine

(Assuming that your user has been created using the process described above)

For Windows users:

  1. Press Win + R
  2. type mstsc and enter
  3. Insert the Linux IP Address into the “Computer” field
  4. Connect
  5. Enter User and Password
  6. Click “OK”

For Mac Users:

  1. Open Remote Desktop app of choice (Windows App is recommended)
  2. Click “+ Add PC”
  3. Enter Linux IP Address in “PC Name”
  4. Add
  5. Double-click the connection
  6. Enter User and Password

For Linux Users:

  1. Open Remmina
  2. Click “+”
  3. Select protocal: “RDP”
  4. Server: Enter Linux IP Address
  5. Enter User
  6. Enter Password
  7. Click “Save and Connect”

Quick Connect:

remmina -c rdp://128.104.50.166

9.5 UW Documentation

https://kb.wisc.edu/search.php?q=cci+virtual is the list of existing documentation from DoIt about VMs.