Operating Systems Courseworks 2023-2024
Course Number: INFR100792023
Semester Number: 2
Score Out of 100: 50%
Authors: Amir Noohi, Alan Nair
Edinburgh, March 5, 2024
Operating Systems Coursework
1 Introduction 1
1.1 Aims of the Coursework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Required Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Guidelines and Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.1 Late Coursework & Extension Requests . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.2 Declaration of Own Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.3 Guide to the Principled Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Technology Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.2 QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.3 GDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Environment Setup 6
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Using DICE Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Lab Machines in Appleton Tower . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Remote Desktop Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 DICE File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Getting Ready Your Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Running Your VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Configuring and Compiling the Linux Kernel . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1 Downloading Linux Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.2 Creating the Default Configuration File . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.3 Adjusting Configuration for a KVM Guest . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.4 Disabling Unrelated Device Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.5 Compiling the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.6 Output of Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Using QEMU Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 Debugging the Linux Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7.1 Building Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 Running the VM with QEMU for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.9 Setting Breakpoints and Debugging with GDB . . . . . . . . . . . . . . . . . . . . . . . . 11
2.10 Stopping Your VM: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Coursework 0 12
3.1 Goal of the Coursework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1 Task 1: Showing Boot Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Task 2: Writing and Loading a Kernel Module . . . . . . . . . . . . . . . . . . . . 13
3.4 Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Coursework 1: Scheduling Policies 15
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Scoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1 Base Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2 Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.3 Untamperable Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1 Base Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.2 Task 1: Aging Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.3 Task 2: Vruntime Transfer Policy Pair . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5 Testing and Configuring from User Space . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.1 DebugFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.2 System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.3 Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Hints and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.1 Spinlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.2 Useful Linux APIs and Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6.3 CFS Statistics, Load, and Weights . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7 Essential Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Coursework 2: Memory Subsystem 22
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Scoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Base Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.2 Task 1: Shared Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.3 Task 2: Memory Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4 Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Operating Systems Coursework
1 | Introduction
Welcome to INFR100792023 – Operating Systems in the Spring semester of the academic year 2023-24. In
this course, you shall dive head-first into the exciting and complex world of operating systems, gaining
both a strong theoretical foundation and hands-on expertise. This document contains information about
the coursework assignments which account for half of your total grade in this course. There are four
assignments – Coursework 0, 1, 2, and 3.
This Chapter shall outline the aims, expectations, guidelines, and rules we (the course faculty) expect you
(the students taking this course) to abide by, along with the necessary background and skills we expect
you to possess beforehand or develop as the course progresses. Chapter 2 will describe the environment
setup on which you shall do the coursework. Chapters 3, 4, 5, and 6 pertain to Coursework 0, 1, 2, and 3
respectively.
1.1 | Aims of the Coursework
The goal of the coursework is to complement the theoretical side of the course (which will be covered
in lectures and evaluated in the final exam) with a practical side. The lectures will imbibe you with an
abstracted-out view of how an operating system (OS) is structured, and how its various parts interplay
with each other. While doing the coursework, however, you shall perceive how this conceptual design is
fleshed out into a real implementation. Your understanding of an Operating System will be complete as
you will be able to map the implementation to the concepts, and vice-versa.
As an Operating Systems developer, you must be able to navigate through large code bases with many
connected and interacting components. The OS is the most privileged software on any computer system,
and it directly manages and controls access to the physical resources on a system, such as memory,
processor cores, and storage. When you try to implement a seemingly small modification to an existing
OS, you must first understand how the relevant parts interact, because a misunderstanding may result in
a kernel that does not boot or crashes unexpectedly. A buggy OS can be catastrophic if deployed in a
real-world use-case.
On the other hand, the OS is a very extensive and complex piece of software. The Linux kernel, which
you shall use for your coursework, has over 28 million lines of code spread out over 169 thousand files.
Comprehending the purpose of every line in the entire source code is a futile effort, and ultimately
unnecessary if you just want to modify some part of this kernel. Thus, you must be able to judge what to
explore and what to ignore, what is relevant to your task and what is secondary, what must be perceived
comprehensively and what can be safely set aside as an abstraction. This is a very subtle yet critical skill
that differentiates an amateur programmer from a seasoned veteran of systems programming. Doing the
coursework with due diligence shall nudge you to the latter class.
1.2 | Timeline
The below table outlines the schedule for each coursework. Coursework 0, focusing on preparation, is not
marked, but its completion is strongly recommended. Please note that regulations for late submissions
can be found in Section 1.4.1, and all assignments have a deadline of 12 PM.
Table 1.1: Coursework Schedule
Assignment Score Effort Release Date Deadline Feedback By
CW0 0% N/A 30/01/2024 13/02/2024 N/A
CW1 17% 16 Hours 13/02/2024 05/03/2024 19/03/2024
CW2 17% 16 Hours 05/03/2024 19/03/2024 02/04/2024
CW3 16% 16 Hours 19/03/2024 02/04/2024 16/04/2024
1.3 | Required Background
The coursework for this Operating Systems class demands a strong foundation in the C programming
language. As we delve into the intricacies of the Linux kernel, which is predominantly written in C, a high
level of fluency in this language is essential. While it is not a prerequisite to have prior experience with
Operating Systems Coursework
the Linux Operating System itself, even as a user, the key requirement is a robust capability in expressing
complex programming concepts in C.
To support your learning curve, we will provide some basic tutoring in C programming. However, it’s
important to recognize that this assistance will have its boundaries in terms of how comprehensively
a language can be taught within the constraints of the course. The nature of the coursework is such
that it will inherently enhance your proficiency in C. This practical approach to learning through direct
engagement with the Linux source code is designed to solidify your understanding and skills.
However, if you are at the very beginning of your journey with the C language, particularly if concepts such
as pointers are challenging for you, and if you doubt your ability to rapidly acquire a deep understanding of
these concepts, it is crucial to carefully consider your participation in this course. This course is intensive
and assumes a certain level of pre-existing knowledge and comfort with C. For those who are not confident
in their current level of proficiency in C, especially in handling advanced programming constructs, it might
be advisable to seek additional preparation before embarking on this course.
This course is not just about learning how to use the Linux kernel; it is about understanding and modifying
its very foundation. This requires not only a theoretical understanding of programming concepts but also
the practical ability to apply these concepts in a complex, real-world environment. If you are ready for
this challenge and confident in your C programming skills, we welcome you to a journey of deep learning
and practical application in the world of operating systems.
1.4 | Guidelines and Rules
This course operates under three key guidelines and rules: ”Late coursework & extension requests,”
”Declaration of Own Work,” and ”Guide to the Principled Code.” Adherence to these guidelines is critical
for the successful completion of the course. Late submissions and extension requests are governed by
specific rules, academic integrity is paramount in all submissions, and the ability to produce compilable
and runnable code is essential. Each of these aspects will be detailed in their respective subsections,
outlining the expectations and standards required for your coursework.
1.4.1 | Late Coursework & Extension Requests
This course enforces specific policies for late submissions and extension requests. Assignments should be
submitted by the set deadline. However, understanding that unforeseen circumstances can arise, each
coursework has defined late submission rules. These rules, outlining the possibilities for late submissions,
incurred penalties, maximum extension lengths, and other relevant information, are available on the
Course LEARN Page.
In instances impacting your ability to complete coursework on time where late submissions are permitted,
you may request an extension through the online Assessment Support Tool. These requests are reviewed
by the University Extensions and Special Circumstances Service (ESC) team. Due to the time taken for
decision-making, it’s advisable to request extensions as early as possible.
Students registered with the Disability & Learning Support Service with entitlements for extra time on
coursework should apply these adjustments for late submissions. For circumstances preventing timely
submission, you may need to apply for Special Circumstances.
The School of Informatics follows a Late Submission Rules and Penalties Policy in line with the University
Taught Assessment Regulations. For example, Rule 1 allows for a 3-day extension and a 7-day Extra
Time Adjustment (ETA), both combinable. Late submissions without an approved extension incur a 5%
penalty per calendar day for up to 7 days post-deadline, after which a zero score is assigned.
Marks are typically returned within 28 calendar days of the submission deadline. For detailed information
on late submission rules, penalties, and scenarios involving extensions and ETAs, visit https://web.inf.ed.
ac.uk/node/4533.
1.4.2 | Declaration of Own Work
By submitting assignments in this course, you affirm that your work complies with the University’s code
of conduct and the Student Conduct and Assessment regulations. This declaration confirms that, except
where indicated, all submitted work is your own and that you have:
https://web.inf.ed.ac.uk/node/4533
https://web.inf.ed.ac.uk/node/4533
Operating Systems Coursework
■ Read and understood the University’s regulations concerning academic misconduct.
■ Where relevant to the assessment style:
□ Clearly referenced/listed all sources.
□ Correctly referenced and marked all quoted text (from books, web, etc.) with quotation marks.
□ Cited the sources of all images, data, etc., not created by you.
■ Not communicated about the work with other students, either electronically, verbally, or through
any other means, nor allowed your work to be seen by other students.
■ Not used any assessment material from other students, past or present.
■ Not submitted work previously presented for this or any other course, degree, or qualification.
■ Not incorporated work from or sought assistance from external professional agencies, except for
attributed source extracts where appropriate.
■ Complied with all examination requirements as outlined in the examination paper and course/pro-
gramme handbooks.
■ Understood that the University of Edinburgh and TurnitinUK may electronically copy your submitted
work for assessment, similarity reporting, and archival purposes.
■ Understood that it is a violation of the Code of Student Conduct to:
□ Use or assist in using unfair means in any University examination.
□ Engage in any action that disrupts the integrity of the examination process.
□ Impersonate another student or allow another student to impersonate you.
■ Understood that cheating is a grave offence. Any student found to have cheated or attempted to
cheat in an examination may face severe penalties, including failing the examination or the entire
examination diet, or any other penalty deemed appropriate by the University.
For further guidance on plagiarism, you are encouraged to:
■ Consult your course organiser or supervisor for personalized advice and clarification.
■ Visit the University of Edinburgh’s Institute for Academic Development website for resources on
referencing and citations: Referencing and Citations Resources.
■ Refer to the University’s guidelines on academic misconduct to understand what constitutes plagia-
rism and how to avoid it: Academic Misconduct Guidelines.
1.4.3 | Guide to the Principled Code
In this course, the emphasis on producing principled and functional code is critical. Adherence to the
following guidelines is essential for a successful evaluation of your coursework:
■ Compilability: The primary requirement is that your code must compile without errors. Submis-
sions that fail to compile will automatically receive a zero score. It is your responsibility to ensure
that your code is free of compilation errors before submission.
■ Adherence to Skeleton: Each assignment comes with a provided code skeleton which you are
required to follow. Non-compliance with the provided skeleton will lead to an automatic score of zero.
This policy is strict, and no objections to the score will be entertained on grounds of non-adherence.
■ Code Readability: Your code must be neat, clean, and well-organized. Proper formatting,
consistent naming conventions, and logical structuring are expected. Readability is key to both
effective coding practices and ease of assessment.
■ Commenting: Ambiguous or complex sections of code should be accompanied by clear comments.
These comments should explain the rationale behind the chosen approach or clarify complex parts
of the code. The goal is to make your code as understandable as possible.
https://www.ed.ac.uk/institute-academic-development/study-hub/learning-resources/referencing-and-citations
https://www.ed.ac.uk/academic-services/students/conduct/academic-misconduct/what-is-academic-misconduct
Operating Systems Coursework
■ Functional Completeness: Beyond just compiling, your code should correctly implement the
required functionalities as outlined in the assignment brief. Functional completeness will be a
significant factor in the assessment.
Adhering to these principles is not only crucial for your success in this course but also forms the foundation
of good software development practices.
1.5 | Technology Stack
The diagram presented in Figure 1.1 illustrates a high-level design of a computer system. It encapsulates
the multi-layered architecture that defines the interaction between user applications and the physical
hardware of a computer. At the foundation, there is the hardware layer, composed of the essential physical
components such as the CPU, memory, and storage devices. Building upon this, the operating system
layer takes precedence, providing essential services such as process management, memory allocation, and
I/O operations. Further abstracted, the standard library offers a set of predefined functions for performing
fundamental tasks, like file handling and process control, which are utilized by the utilities layer to furnish
tools and applications for end-user interaction.
(CPU, memory, disks, networks, etc.)
Operating System
(process, memory, filesystem, I/O, etc.)
Standard Library
(open, close, read, write, fork, etc.)
(shell, editors, filters, etc.)
System Call
Figure 1.1: Computer System Diagram
In the context of a virtualized system, the depicted model extends by incorporating additional layers to
represent the virtualization aspect (see Figure 1.2). Atop the hardware layer resides the host operating
system, which is responsible for the direct management of the hardware resources. The virtualization
layer, typically provided by software like QEMU, allows for the creation and management of virtual
machines (VMs). Each VM encapsulates a complete set of the layers described above, including its own
guest operating system that operates oblivious to the virtualized nature of the underlying hardware. This
encapsulation allows multiple isolated operating system instances to coexist on a single physical machine,
optimizing resource utilization and providing robust environment isolation.
Operating Systems Coursework
(CPU, memory, disks, Networks, etc.)
(process, memory, filesystem, I/O, etc.)
Hypervisor
(QEMU/KVM, XEN, etc.)
GDB Utility VNC Utility
Standard Library
(open, close, read, write, fork, etc.)
Standard Library
(open, close, read, write, fork, etc.)
Figure 1.2: Virtualized System Diagram
The coursework in this course involves the use of a technology stack consisting of three essential components:
Linux, QEMU, and GDB. Detailed familiarity with these tools is crucial for developing and testing your
code effectively.
1.5.1 | Linux
For your coursework, you will be working with the Linux kernel version 6.1, which is a long-term support
(LTS) release. This version provides stability and a comprehensive feature set, making it ideal for
educational purposes. It’s important to note that throughout the coursework, we will only support the
x86 64 architecture. This focus allows for a standardized development and testing environment that is
widely applicable and relevant in the field.
Remember, all course-related development and testing will be expected to be compatible with the Linux
kernel 6.1 on the x86 64 architecture. This requirement ensures consistency in the coursework and aligns
your learning experience with current industry standards.
1.5.2 | QEMU
Working with an operating system, especially during development and testing phases, inevitably involves
encountering crashes and bugs. Running a buggy OS on actual hardware can be risky. Hence, you will
use virtual machines (VMs) for your coursework. QEMU is a hypervisor that allows the creation and
management of VMs, providing a safe environment for testing. For detailed instructions on using QEMU,
refer to Chapter 2.
1.5.3 | GDB
The GNU Debugger (GDB) is a powerful tool for debugging C programs. It enables you to trace the
execution of a program step-by-step, pause it, and inspect various symbols at runtime. This capability
is invaluable for identifying and fixing errors in your code. You will become familiar with GDB during
Coursework 0, as detailed in Chapter 3.
Each of these tools is integral to the development process in this course. Mastery of Linux, QEMU, and
GDB will not only aid in your coursework but also equip you with valuable skills applicable to a wide
range of software development and systems engineering tasks.
Operating Systems Coursework
2 | Environment Setup
2.1 | Introduction
Welcome to an essential and exciting aspect of your journey in operating system coursework! In this
chapter, we’re going to delve into the fascinating world of testing environments. Understanding where and
how to test your code is not just a step in learning; it’s an adventure in problem-solving and creativity.
In the dynamic field of Linux kernel development, there are several approaches to explore. One effective
and straightforward method is through virtualization. This section is dedicated to guiding you through
this process, focusing on the utilization of University infrastructure.
While this document emphasizes using the university’s infrastructure, it’s essential to acknowledge the
flexibility in your approach to coursework. If you have access to your own infrastructure, you may consider
skipping this chapter entirely. Remember, since university resources are shared, running projects on
your local infrastructure could be faster and more efficient. You’re encouraged to explore and utilize
the resources that best suit your learning style and project requirements. Whether you opt for the
university’s high-performance resources and standardized environment or set up a virtual environment
on your personal system, all coursework will be evaluated equally. This ensures that regardless of the
method chosen, you have the opportunity to achieve full marks. Despite this, please note that support
and guidance will be primarily available for DICE setups.
For students opting to use their personal machines, the process involves a few essential steps. Firstly, it’s
recommended to install a virtualization tool like VMware or VirtualBox. These tools allow you to create
and manage virtual machines (VMs), which provide isolated environments for kernel development without
affecting your main operating system. After setting up the virtualization software, the next step is to
create a VM and install a Linux distribution on it, such as Ubuntu, Fedora, or Debian, which are popular
choices for development work.
Once your Linux environment is ready within the VM, the next task is to install the prerequisites for
compiling the Linux kernel. This typically includes development tools such as the GNU Compiler Collection
(GCC), make, and the ncurses library, among others. After installing these tools, you can proceed to
download the Linux kernel source code and begin the exciting process of compiling and testing. This
approach offers the flexibility of a customizable development environment on your machine while ensuring
that your primary operating system remains unaffected by the development activities. It’s a great way to
learn about system administration and kernel development in a controlled and safe environment.
2.2 | Using DICE Servers
DICE, which stands for Distributed Informatics Computing Environment, is the University’s specialized
computing environment designed to support your journey in Linux kernel development. This platform
offers two primary ways for engaging with coursework: using dedicated lab machines or accessing the
environment remotely.
If you haven’t already created a DICE account, the instruction available at https://computing.help.inf.
ed.ac.uk/accounts provides guidance on how to do so. This account is essential for accessing either the
physical lab machines or the remote desktop service.
2.2.1 | Lab Machines in Appleton Tower
Appleton Tower is equipped with over 300 lab machines, all set up with DICE. These machines are readily
available for in-person use and have been configured with everything you need for your coursework. This
option provides a hands-on experience and direct interaction with the tools and resources necessary for
Linux kernel development.
2.2.2 | Remote Desktop Access
Despite the availability of lab machines, we recommend using the School of Informatics’ remote desktop
service for your coursework. Opting for remote access aligns with the coursework instructions and ensures
a consistent experience across the student body. Remote access allows you to work flexibly from any
location, providing convenience and continuity in your learning process.
https://computing.help.inf.ed.ac.uk/accounts
https://computing.help.inf.ed.ac.uk/accounts
Operating Systems Coursework
For detailed instructions on establishing a connection to the DICE remote desktop server, tailored to various
operating systems, please refer to https://computing.help.inf.ed.ac.uk/remote-desktop. Additionally, it’s
important to note that if you are outside the university’s network and unable to connect to the remote
desktop server, you must use a VPN. The link provided includes comprehensive instructions on how to set
up and use the university’s VPN service.
Once you have connected to the DICE remote desktop server, it’s important to note that this environment
itself does not support virtualization. Therefore, you will need to connect further to specific lab machines
or the student compute server for more advanced capabilities. In this guide, we will walk you through
using the student compute server for this purpose(https://computing.help.inf.ed.ac.uk/compute-servers).
2.2.3 | DICE File System
Upon connecting to any server on DICE, you’ll find yourself within the AFS (Andrew File System), a
shared file system used across all servers. It’s crucial to be aware of the space limitations associated with
using the AFS, as outlined in https://computing.help.inf.ed.ac.uk/afs-quotas. These limitations mean
that AFS may not be suitable as the final location to set up your virtual machine.
For more extensive storage needs, such as storing your virtual machine image, we recommend using the
scratch space available on DICE desktops or servers. Detailed guidance on how to utilize this scratch
space effectively can be found at https://computing.help.inf.ed.ac.uk/scratch-space. This resource will
instruct you on how to use disk scratch space to store your virtual machine image and ultimately bring
up your virtual machine for your coursework.
2.3 | Getting Ready Your Workspace
Once you’ve successfully connected to the DICE remote desktop server, the next step is to connect to the
student compute server or whatever l