http://wiki.cs.vt.edu/api.php?action=feedcontributions&feedformat=atom&user=Rhunter 2026-05-30T04:24:38Z User contributions MediaWiki 1.45.3 http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4973 2026-05-11T13:55:41Z

<p>Rhunter: </p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Nodes ==<br /> * Frieren : 128 Cores, 1.1 TB RAM, 8x H200 NVL GPUs (2x 4-way NVLinks)<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> Jobs are typically queued via the &quot;sbatch&quot; command and a control script that tells the queue what resources you need and the actual commands to run.<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s &lt;session_name&gt;<br /> &lt;/pre&gt;<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --cpus-per-task=4 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;<br /> <br /> == Other Useful Commands ==<br /> * squeue - used to show what is in the queue and the status of each job<br /> * scontrol show node - used to show the status of the nodes<br /> * scontrol show job &lt;jobid&gt; - used to show the info of a specific job<br /> * scancel &lt;jobid&gt; - used to cancel a job</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4972 2026-05-11T13:48:39Z

<p>Rhunter: /* Interactive Jobs */</p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> Jobs are typically queued via the &quot;sbatch&quot; command and a control script that tells the queue what resources you need and the actual commands to run.<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s &lt;session_name&gt;<br /> &lt;/pre&gt;<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --cpus-per-task=4 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;<br /> <br /> == Other Useful Commands ==<br /> * squeue - used to show what is in the queue and the status of each job<br /> * scontrol show node - used to show the status of the nodes<br /> * scontrol show job &lt;jobid&gt; - used to show the info of a specific job<br /> * scancel &lt;jobid&gt; - used to cancel a job</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4971 2026-05-11T13:48:08Z

<p>Rhunter: </p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> Jobs are typically queued via the &quot;sbatch&quot; command and a control script that tells the queue what resources you need and the actual commands to run.<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s session_name<br /> &lt;/pre&gt;<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --cpus-per-task=4 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;<br /> <br /> == Other Useful Commands ==<br /> * squeue - used to show what is in the queue and the status of each job<br /> * scontrol show node - used to show the status of the nodes<br /> * scontrol show job &lt;jobid&gt; - used to show the info of a specific job<br /> * scancel &lt;jobid&gt; - used to cancel a job</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4970 2026-05-11T12:52:20Z

<p>Rhunter: /* Other Useful Commands */</p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> Jobs are typically queued via the &quot;sbatch&quot; command and a control script that tells the queue what resources you need and the actual commands you will run.<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s session_name<br /> &lt;/pre&gt;<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --cpus-per-task=4 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;<br /> <br /> == Other Useful Commands ==<br /> * squeue - used to show what is in the queue and the status of each job<br /> * scontrol show node - used to show the status of the nodes<br /> * scontrol show job &lt;jobid&gt; - used to show the info of a specific job<br /> * scancel &lt;jobid&gt; - used to cancel a job</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4969 2026-05-11T12:51:14Z

<p>Rhunter: /* Other Useful Commands */</p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> Jobs are typically queued via the &quot;sbatch&quot; command and a control script that tells the queue what resources you need and the actual commands you will run.<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s session_name<br /> &lt;/pre&gt;<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --cpus-per-task=4 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;<br /> <br /> == Other Useful Commands ==<br /> * squeue - used to show what is in the queue and the status of each job<br /> * scontrol show node - used to show the status of the nodes<br /> * scontrol show job &lt;jobid&gt; - used to show the info of a specific job</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4968 2026-05-11T12:49:15Z

<p>Rhunter: </p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> Jobs are typically queued via the &quot;sbatch&quot; command and a control script that tells the queue what resources you need and the actual commands you will run.<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s session_name<br /> &lt;/pre&gt;<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --cpus-per-task=4 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;<br /> <br /> == Other Useful Commands ==<br /> squeue - used to show what is in the queue and the status of each job<br /> scontrol show node - used to show the status of the nodes<br /> scontrol show job &lt;jobid&gt; - used to show the info of a specific job</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4967 2026-05-11T12:44:05Z

<p>Rhunter: /* Submitting Jobs */</p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> Jobs are typically queued via the &quot;sbatch&quot; command and a control script that tells the queue what resources you need and the actual commands you will run.<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s session_name<br /> &lt;/pre&gt;<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --cpus-per-task=4 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4966 2026-05-11T12:41:31Z

<p>Rhunter: /* Interactive Jobs */</p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s session_name<br /> &lt;/pre&gt;<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --cpus-per-task=4 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4965 2026-05-11T12:40:11Z

<p>Rhunter: /* Interactive Jobs */</p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s session_name<br /> &lt;/pre&gt;<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4964 2026-05-11T12:39:45Z

<p>Rhunter: </p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;<br /> <br /> == Interactive Jobs ==<br /> The preferred method for starting an interactive job is to first create a tmux session so that if you get disconnected you can re-attach to the session.<br /> &lt;pre&gt;<br /> tmux new -s session_name<br /> &lt;/pre<br /> Next setup your environment allocation for your job. Be sure to include a time limit, # of CPUs, RAM, and # of GPUs<br /> &lt;pre&gt;<br /> salloc -t 2:00:00 --mem=8G --gres=gpu:1<br /> &lt;/pre&gt;<br /> At this point, you can monitor the queue and wait for your job to go live using the &quot;squeue&quot; command. Once live you can attach to your job using the srun command.<br /> &lt;pre&gt;<br /> srun --pty /bin/bash <br /> &lt;/pre&gt;<br /> <br /> Please note that you are not limited to just bash but can run entire scripts via the srun command. bash is just the best way to get an interactive shell on the node with which to interact. When you type &quot;exit&quot; you are concluding your srun session. However, this does not conclude your entire interactive session. You have to exit again to exit the salloc session as well. This will conclude your job in the queue. A final exit is require to exit your tmux session but this is optional as many users will keep their tmux session when working with the headnode.<br /> <br /> To re-attach to a tmux session (if you get disconnected or close your ssh window) use the following:<br /> &lt;pre&gt;<br /> tmux a -t &lt;session_name&gt;<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4963 2026-05-11T12:26:45Z

<p>Rhunter: /* Example Batch Script */</p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> <br /> == Example Batch Script ==<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Empire_Cluster&diff=4962 2026-05-11T12:25:49Z

<p>Rhunter: Created page with &quot;== Introduction == Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system. == Account == Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create == Primary Access == Empire headnode access is provided via an SSH session. Connec...&quot;</p> <hr /> <div>== Introduction ==<br /> Empire is the Computer Science production research GPU cluster. It allows faculty and grad students to work on research projects via a queue system.<br /> <br /> == Account ==<br /> Access is controlled by a Computer Science specific account. Access is limited to CS Faculty and Grad students only. If you do not have a CS account you can create one here: https://admin.cs.vt.edu/create<br /> <br /> == Primary Access ==<br /> Empire headnode access is provided via an SSH session. Connect to the headnode via SSH. Linux and Macs usually come with SSH client already active. Windows users can install the client following these directions: https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client<br /> <br /> == Submitting Jobs ==<br /> <br /> == Example Batch Script ==<br /> &lt;code&gt;<br /> #!/bin/bash<br /> ######################################<br /> # Simple GPU submit script for SLURM #<br /> # Run with &quot;sbatch script_name.sh&quot; #<br /> # Variables: %j = job ID #<br /> # Recommend 4 CPUs per 1 GPU request #<br /> ######################################<br /> <br /> #SBATCH --job-name=&quot;gpu_test&quot; # Job name<br /> #SBATCH --output=gpu_test_%j.o # Standard output log file<br /> #SBATCH --error=gpu_test_%j.e # Standard error log file<br /> #SBATCH --nodes=1 # Number of nodes<br /> #SBATCH --ntasks=1 # Number of tasks<br /> #SBATCH --cpus-per-task=4 # CPUs per task<br /> #SBATCH --mem=16G # Requested Memory<br /> #SBATCH --time=00:00:30 # Wall time limit (HH:MM:SS)<br /> #SBATCH --gres=gpu:1 # Request one generic GPU<br /> #SBATCH --partition=batch # Specify the queue name (batch)<br /> <br /> # Start timestamp #<br /> echo -n &quot;Start Time: &quot;<br /> date<br /> <br /> # Load necessary modules (system-specific) #<br /> # module load python<br /> # module load cuda/11.8 # Example CUDA version<br /> <br /> # Activate a Python virtual/conda environment if needed #<br /> # source /path/to/your/env/bin/activate<br /> <br /> # Command(s) to run your program #<br /> # python your_gpu_script.py<br /> echo &quot;Hello World&quot;<br /> <br /> # Finish timestamp #<br /> echo -n &quot;End Time: &quot;<br /> date<br /> &lt;/code&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4953 2025-12-11T16:04:09Z

<p>Rhunter: </p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> == Background ==<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface. Certain ports should NEVER be exposed like Databases and Administrative services.<br /> <br /> <br /> == The Fix ==<br /> <br /> Instead of globally defining the port (which also opens it externally):<br /> &lt;pre&gt;<br /> docker run -p 6379:6379/tcp redis # !!! WRONG !!!<br /> &lt;/pre&gt;<br /> <br /> Bind the port to the localhost only using the following:<br /> &lt;pre&gt;<br /> docker run -p 127.0.0.1:6379:6379/tcp redis<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4952 2025-12-11T16:02:36Z

<p>Rhunter: /* The Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> == Background ==<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface.<br /> <br /> <br /> == The Fix ==<br /> <br /> Instead of globally defining the port (which also opens it externally):<br /> &lt;pre&gt;<br /> docker run -p 6379:6379/tcp redis # !!! WRONG !!!<br /> &lt;/pre&gt;<br /> <br /> Bind the port to the localhost only using the following:<br /> &lt;pre&gt;<br /> docker run -p 127.0.0.1:6379:6379/tcp redis<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4951 2025-12-11T15:41:39Z

<p>Rhunter: /* The Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> == Background ==<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface.<br /> <br /> <br /> == The Fix ==<br /> <br /> Instead of globally defining the port (which also opens it externally):<br /> &lt;pre&gt;<br /> docker run -p 8080:8080/tcp ubuntu bash # !!! WRONG !!!<br /> &lt;/pre&gt;<br /> <br /> Bind the port to the localhost only using the following:<br /> &lt;pre&gt;<br /> docker run -p 127.0.0.1:8080:8080/tcp ubuntu bash<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4950 2025-12-11T15:41:24Z

<p>Rhunter: /* The Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> == Background ==<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface.<br /> <br /> <br /> == The Fix ==<br /> <br /> Instead of globally defining the port (which also opens it externally): %color=red%WRONG<br /> &lt;pre&gt;<br /> docker run -p 8080:8080/tcp ubuntu bash # !!! WRONG !!!<br /> &lt;/pre&gt;<br /> <br /> Bind the port to the localhost only using the following:<br /> &lt;pre&gt;<br /> docker run -p 127.0.0.1:8080:8080/tcp ubuntu bash<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4949 2025-12-11T15:40:32Z

<p>Rhunter: /* The Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> == Background ==<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface.<br /> <br /> <br /> == The Fix ==<br /> <br /> Instead of globally defining the port (which also opens it externally):<br /> &lt;pre %bgcolor=red%&gt;<br /> docker run -p 8080:8080/tcp ubuntu bash # !!! WRONG !!!<br /> &lt;/pre&gt;<br /> <br /> Bind the port to the localhost only using the following:<br /> &lt;pre&gt;<br /> docker run -p 127.0.0.1:8080:8080/tcp ubuntu bash<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4948 2025-12-11T15:40:17Z

<p>Rhunter: /* The Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> == Background ==<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface.<br /> <br /> <br /> == The Fix ==<br /> <br /> Instead of globally defining the port (which also opens it externally):<br /> &lt;pre %bgcolor=lightblue%&gt;<br /> docker run -p 8080:8080/tcp ubuntu bash # !!! WRONG !!!<br /> &lt;/pre&gt;<br /> <br /> Bind the port to the localhost only using the following:<br /> &lt;pre&gt;<br /> docker run -p 127.0.0.1:8080:8080/tcp ubuntu bash<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4947 2025-12-11T15:39:58Z

<p>Rhunter: /* The Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> == Background ==<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface.<br /> <br /> <br /> == The Fix ==<br /> <br /> Instead of globally defining the port (which also opens it externally):<br /> %bgcolor=lightblue%&lt;pre&gt;<br /> docker run -p 8080:8080/tcp ubuntu bash # !!! WRONG !!!<br /> &lt;/pre&gt;<br /> <br /> Bind the port to the localhost only using the following:<br /> &lt;pre&gt;<br /> docker run -p 127.0.0.1:8080:8080/tcp ubuntu bash<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4946 2025-12-11T15:39:37Z

<p>Rhunter: /* The Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> == Background ==<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface.<br /> <br /> <br /> == The Fix ==<br /> <br /> Instead of globally defining the port (which also opens it externally):<br /> &lt;pre&gt;%bgcolor=lightblue%<br /> docker run -p 8080:8080/tcp ubuntu bash # !!! WRONG !!!<br /> &lt;/pre&gt;<br /> <br /> Bind the port to the localhost only using the following:<br /> &lt;pre&gt;<br /> docker run -p 127.0.0.1:8080:8080/tcp ubuntu bash<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4945 2025-12-11T15:36:36Z

<p>Rhunter: </p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> == Background ==<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface.<br /> <br /> <br /> == The Fix ==<br /> <br /> Instead of globally defining the port (which also opens it externally):<br /> &lt;pre&gt;<br /> docker run -p 8080:8080/tcp ubuntu bash # !!! WRONG !!!<br /> &lt;/pre&gt;<br /> <br /> Bind the port to the localhost only using the following:<br /> &lt;pre&gt;<br /> docker run -p 127.0.0.1:8080:8080/tcp ubuntu bash<br /> &lt;/pre&gt;</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4944 2025-12-11T15:31:04Z

<p>Rhunter: /* UFW Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix on the machine running docker, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == Docker exposed ports Fix ==<br /> Background<br /> <br /> Docker ignores most firewall rules and opens ports directly to the external network interface.<br /> <br /> <br /> The Fix<br /> <br /> Instead of globally defining the port (which also opens it externally), bind the port to the localhost only using the following:</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Ubuntu_Upgrade&diff=4903 2025-03-05T08:44:10Z

<p>Rhunter: /* Ubuntu Upgrade Procedure */</p> <hr /> <div>== Ubuntu Upgrade Procedure ==<br /> <br /> [[Overview]]<br /> <br /> This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them.<br /> <br /> [[Assumptions]]<br /> <br /> We assume that you have root or some form of SUDO access.<br /> <br /> [[Steps]]<br /> <br /> * Disable any 3rd party repositories (these will just get in the way later on. you can rename them to .save). If someone included additional repos in the main /etc/apt/sources.list file comment those out and place them in separate files under the /etc/apt/sources.list.d directory.<br /> <br /> * Make sure the system is completely up to date.<br /> <br /> sudo apt update; sudo apt upgrade<br /> <br /> * Once your system is fully up to date, I recommend a reboot.<br /> <br /> * After reboot, migrate to the next LTS version of Ubuntu with do-release-upgrade.<br /> <br /> sudo do-release-upgrade<br /> <br /> *Follow the steps and recommendations (defaults usually work best in most cases) and follow through until the end when it asks you to reboot (this will be the last step). <br /> <br /> *If you get disconnected early for any reason '''DO NOT REBOOT'''!!! Contact TechStaff to help you recover your upgrade. In most cases, you can reconnect to port 1022 or locally via the command:<br /> <br /> screen -r<br /> <br /> *If the command fails for any other reason, look at the listed reasons and take the steps recommended. Again if you have any questions during a difficult upgrade ask TechStaff for advise.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Ubuntu_Upgrade&diff=4902 2025-02-12T07:14:50Z

<p>Rhunter: /* Ubuntu Upgrade Procedure */</p> <hr /> <div>== Ubuntu Upgrade Procedure ==<br /> <br /> [[Overview]]<br /> <br /> This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them.<br /> <br /> [[Assumptions]]<br /> <br /> We assume that you have root or some form of SUDO access.<br /> <br /> [[Steps]]<br /> <br /> * Disable any 3rd party repositories (these will just get in the way later on. you can rename them to .save). If someone included additional repos in the main /etc/apt/sources.list file comment those out and place them in separate files under the /etc/apt/sources.list.d directory.<br /> <br /> * Make sure the system is completely up to date.<br /> <br /> sudo apt update; apt upgrade<br /> <br /> * Once your system is fully up to date, I recommend a reboot.<br /> <br /> * After reboot, migrate to the next LTS version of Ubuntu with do-release-upgrade.<br /> <br /> sudo do-release-upgrade<br /> <br /> *Follow the steps and recommendations (defaults usually work best in most cases) and follow through until the end when it asks you to reboot (this will be the last step). <br /> <br /> *If you get disconnected early for any reason '''DO NOT REBOOT'''!!! Contact TechStaff to help you recover your upgrade. In most cases, you can reconnect to port 1022 or locally via the command:<br /> <br /> screen -r<br /> <br /> *If the command fails for any other reason, look at the listed reasons and take the steps recommended. Again if you have any questions during a difficult upgrade ask TechStaff for advise.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Ubuntu_Upgrade&diff=4901 2025-02-10T16:09:26Z

<p>Rhunter: /* Ubuntu Upgrade Procedure */</p> <hr /> <div>== Ubuntu Upgrade Procedure ==<br /> <br /> [[Overview]]<br /> <br /> This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them.<br /> <br /> [[Assumptions]]<br /> <br /> We assume that you have root or some form of SUDO access.<br /> <br /> [[Steps]]<br /> <br /> * Disable any 3rd party repositories (these will just get in the way later on. you can rename them to .save<br /> <br /> * Make sure the system is completely up to date.<br /> <br /> sudo apt update; apt upgrade<br /> <br /> * Once your system is fully up to date, I recommend a reboot.<br /> <br /> * After reboot, migrate to the next LTS version of Ubuntu with do-release-upgrade.<br /> <br /> sudo do-release-upgrade<br /> <br /> *Follow the steps and recommendations (defaults usually work best in most cases) and follow through until the end when it asks you to reboot (this will be the last step). <br /> <br /> *If you get disconnected early for any reason '''DO NOT REBOOT'''!!! Contact TechStaff to help you recover your upgrade. In most cases, you can reconnect to port 1022 or locally via the command:<br /> <br /> screen -r<br /> <br /> *If the command fails for any other reason, look at the listed reasons and take the steps recommended. Again if you have any questions during a difficult upgrade ask TechStaff for advise.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Ubuntu_Upgrade&diff=4900 2025-02-10T16:08:45Z

<p>Rhunter: /* Ubuntu Upgrade Procedure */</p> <hr /> <div>== Ubuntu Upgrade Procedure ==<br /> <br /> [[Overview]]<br /> <br /> This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them.<br /> <br /> [[Assumptions]]<br /> <br /> We assume that you have root or some form of SUDO access.<br /> <br /> [[Steps]]<br /> <br /> * Disable any 3rd party repositories (these will just get in the way later on. you can rename them to .save<br /> <br /> * Make sure the system is completely up to date.<br /> <br /> sudo apt update; apt upgrade<br /> <br /> * Once your system is fully up to date, I recommend a reboot.<br /> <br /> * After reboot, migrate to the next LTS version of Ubuntu with do-release-upgrade.<br /> <br /> sudo do-release-upgrade<br /> <br /> *Follow the steps and recommendations (defaults usually work best in most cases) and follow through until the end when it asks you to reboot (this will be the last step). <br /> <br /> *If you get disconnected early for any reason '''DO NOT REBOOT'''!!! Contact TechStaff to help you recover your upgrade. In most cases, you can reconnect to port 1022 or locally via the &quot;'''''screen -r'''''&quot; command.<br /> <br /> *If the command fails for any other reason, look at the listed reasons and take the steps recommended. Again if you have any questions during a difficult upgrade ask TechStaff for advise.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Ubuntu_Upgrade&diff=4899 2025-02-10T16:04:49Z

<p>Rhunter: </p> <hr /> <div>== Ubuntu Upgrade Procedure ==<br /> <br /> [[Overview]]<br /> <br /> This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them.<br /> <br /> [[Assumptions]]<br /> <br /> We assume that you have root or some form of SUDO access.<br /> <br /> [[Steps]]<br /> <br /> # Disable any 3rd party repositories (these will just get in the way later on. you can rename them to .save<br /> <br /> # Make sure the system is completely up to date.<br /> <br /> sudo apt update; apt upgrade<br /> <br /> If any errors about 3rd party repositories that can not be found etc then disable those 3rd party repositories and run again. Do this until your system is fully up to date. At this point, I recommend a reboot.<br /> <br /> # Once system is up to date in the current Ubuntu version run do-release-upgrade.<br /> <br /> do-release-upgrade<br /> <br /> Follow the steps and recommendations (defaults usually work best in most cases) and follow through until the end when it asks you to reboot (this will be the last step). <br /> <br /> <br /> If you get disconnected early for any reason '''DO NOT REBOOT'''!!! Contact TechStaff to help you recover your upgrade. In most cases, you can reconnect to port 1022 <br /> <br /> or locally via the &quot;'''''screen -r'''''&quot; command.<br /> <br /> If the command fails for any other reason, look at the listed reasons and take the steps recommended. Again if you have any questions during a difficult upgrade ask TechStaff for advise.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Ubuntu_Upgrade&diff=4898 2025-02-10T16:01:12Z

<p>Rhunter: </p> <hr /> <div>== Ubuntu Upgrade Procedure ==<br /> <br /> [[Overview]]<br /> <br /> This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them.<br /> <br /> [[Assumptions]]<br /> <br /> We assume that you have root or some form of SUDO access.<br /> <br /> [[Steps]]<br /> <br /> 1. Make sure the system is completely up to date.<br /> <br /> sudo apt update; apt upgrade<br /> <br /> If any errors about 3rd party repositories that can not be found etc then disable those 3rd party repositories and run again. Do this until your system is fully up to date. At this point, I recommend a reboot.<br /> <br /> 2. Once system is up to date in the current Ubuntu version run do-release-upgrade.<br /> <br /> do-release-upgrade<br /> <br /> Follow the steps and recommendations (defaults usually work best in most cases) and follow through until the end when it asks you to reboot (this will be the last step). <br /> <br /> <br /> If you get disconnected early for any reason '''DO NOT REBOOT'''!!! Contact TechStaff to help you recover your upgrade. In most cases, you can reconnect to port 1022 <br /> <br /> or locally via the &quot;'''''screen -r'''''&quot; command.<br /> <br /> If the command fails for any other reason, look at the listed reasons and take the steps recommended. Again if you have any questions during a difficult upgrade ask TechStaff for advise.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Ubuntu_Upgrade&diff=4897 2025-02-10T15:58:30Z

<p>Rhunter: </p> <hr /> <div>&lt;u&gt;Ubuntu Upgrade Procedure&lt;/u&gt;:<br /> <br /> Overview:<br /> This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them.<br /> <br /> Assumptions:<br /> We assume that you have root or some form of SUDO access.<br /> <br /> &lt;u&gt;Steps&lt;/u&gt;:<br /> <br /> 1. Make sure the system is completely up to date.<br /> <br /> sudo apt update; apt upgrade<br /> <br /> If any errors about 3rd party repositories that can not be found etc then disable those 3rd party repositories and run again. Do this until your system is fully up to date. At this point, I recommend a reboot.<br /> <br /> 2. Once system is up to date in the current Ubuntu version run do-release-upgrade.<br /> <br /> do-release-upgrade<br /> <br /> Follow the steps and recommendations (defaults usually work best in most cases) and follow through until the end when it asks you to reboot (this will be the last step). <br /> <br /> <br /> If you get disconnected early for any reason '''DO NOT REBOOT'''!!! Contact TechStaff to help you recover your upgrade. In most cases, you can reconnect to port 1022 <br /> <br /> or locally via the &quot;'''''screen -r'''''&quot; command.<br /> <br /> If the command fails for any other reason, look at the listed reasons and take the steps recommended. Again if you have any questions during a difficult upgrade ask TechStaff for advise.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Ubuntu_Upgrade&diff=4896 2025-02-10T14:58:23Z

<p>Rhunter: </p> <hr /> <div>Ubuntu Upgrade Procedure:<br /> <br /> Overview:<br /> This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them.<br /> <br /> Assumptions:<br /> We assume that you have root or some form of SUDO access.<br /> <br /> Steps:<br /> 1. Make sure the system is completely up to date.<br /> <br /> sudo apt update; apt upgrade<br /> <br /> If any errors about 3rd party repositories that can not be found etc then disable those 3rd party repositories and run again. Do this until your system is fully up to date. At this point, I recommend a reboot.<br /> <br /> 2. Once system is up to date in the current Ubuntu version run do-release-upgrade.<br /> <br /> do-release-upgrade<br /> <br /> Follow the steps and recommendations (defaults usually work best in most cases) and follow through until the end when it asks you to reboot (this will be the last step). <br /> <br /> <br /> If you get disconnected early for any reason '''DO NOT REBOOT'''!!! Contact TechStaff to help you recover your upgrade. In most cases, you can reconnect to port 1022 <br /> <br /> or locally via the &quot;'''''screen -r'''''&quot; command.<br /> <br /> If the command fails for any other reason, look at the listed reasons and take the steps recommended. Again if you have any questions during a difficult upgrade ask TechStaff for advise.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Ubuntu_Upgrade&diff=4895 2025-02-10T14:56:03Z

<p>Rhunter: Created page with &quot;Ubuntu Upgrade Procedure: Overview: This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them. Assumptions: We assume that you have root or some form of SUDO access. Steps: 1. Make sure the system is completely up to date. sudo apt update; apt upgrade If any errors about 3rd party repositories that can not...&quot;</p> <hr /> <div>Ubuntu Upgrade Procedure:<br /> <br /> Overview:<br /> This is a rough upgrade procedure that we (TechStaff) recommend for VMs and Servers. Desktops generally follow a GUI interface to complete an upgrade between versions of Ubuntu but this procedure will also work on them.<br /> <br /> Assumptions:<br /> We assume that you have root or some form of SUDO access.<br /> <br /> Steps:<br /> 1. Make sure the system is completely up to date.<br /> <br /> sudo apt update; apt upgrade<br /> <br /> If any errors about 3rd party repositories that can not be found etc then disable those 3rd party repositories and run again. Do this until your system is fully up to date. At this point, I recommend a reboot.<br /> <br /> 2. Once system is up to date in the current Ubuntu version run do-release-upgrade.<br /> <br /> do-release-upgrade<br /> <br /> Follow the steps and recommendations (defaults usually work best in most cases) and follow through until the end when it asks you to reboot (this will be the last step). <br /> <br /> If you get disconnected early for any reason DO NOT REBOOT!!! Contact TechStaff to help you recover your upgrade. In most cases, you can reconnect to port 1022 or locally via the &quot;screen -r&quot; command.<br /> <br /> If the command fails for any other reason, look at the listed reasons and take the steps recommended. Again if you have any questions during a difficult upgrade ask TechStaff for advise.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4893 2025-02-04T21:03:45Z

<p>Rhunter: /* CSRGPU */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: At least 64<br /> *** Ram: 512GB<br /> ** Network: 10Gbit low latency SFP+ interconnect<br /> ** Storage: 143 terabytes of redundant CEPH disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 18<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPUs: Multiple NVidia P40, T4, A2, L40S GPUs<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 237 TB of dedicated CEPH storage<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 73TB<br /> <br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == Shared Storage System ==<br /> An on-premise robust shared storage system is available for departmental use.<br /> * Hardware and software redundant storage<br /> * Encrypted at rest<br /> * Encryption in transit is available<br /> * Can be mounted on multiple machines at the same time<br /> * Available for use on kubernetes clusters<br /> * Currently 180TB raw storage available<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10Gbit interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4890 2024-12-03T14:07:50Z

<p>Rhunter: /* CSRVM */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: At least 64<br /> *** Ram: 512GB<br /> ** Network: 10Gbit low latency SFP+ interconnect<br /> ** Storage: 143 terabytes of redundant CEPH disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 15<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPUs: Multiple NVidia P40, T4, A2 GPUs<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 174 TB of dedicated CEPH storage<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 73TB<br /> <br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10Gbit interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4751 2024-05-07T13:43:14Z

<p>Rhunter: /* UFW Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == UFW Fix ==<br /> coming soon</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4750 2024-05-07T13:42:26Z

<p>Rhunter: /* The Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> == UFW Fix ==<br /> Also note that the fix to allow ufw to control ports in docker is also included as it should for any device on campus which needs a firewall.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4745 2024-03-25T17:01:16Z

<p>Rhunter: </p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;iptables&quot;: false<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart<br /> <br /> <br /> == UFW Fix ==<br /> Also note that the fix to allow ufw to control ports in docker is also included as it should for any device on campus which needs a firewall.</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4744 2024-03-25T16:59:11Z

<p>Rhunter: /* The Fix */</p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;iptables&quot;: false<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4743 2024-03-25T15:21:44Z

<p>Rhunter: </p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> == The Fix ==<br /> To apply the docker fix, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4742 2024-03-25T15:21:27Z

<p>Rhunter: </p> <hr /> <div>== Background ==<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> <br /> == The Fix ==<br /> To apply the docker fix, create a file called /etc/docker/daemon.json with the following:<br /> <br /> &lt;pre&gt;<br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> &lt;/pre&gt;<br /> Followed by:<br /> <br /> sudo service docker restart</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo:Docker_172_Fix&diff=4741 2024-03-25T15:18:45Z

<p>Rhunter: Created page with &quot;Background: VT uses a chunk of the 172 private network address space for it&#039;s internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5...&quot;</p> <hr /> <div>Background:<br /> VT uses a chunk of the 172 private network address space for it's internal private addressing. Docker comes pre-configured to also uses 172.17.0.0/12 which will cause the internal system to ignore any external 172.17.x.x/12 address trying to access the system. To fix this you need to reconfigure your docker to use a different address space like 192.168.x.x/16 or a 10.1.x.x/16 (tech also uses 10.6+.x.x for their networking so this is less safe although 10.5 and lower are guaranteed to be free).<br /> <br /> To apply the docker fix, create a file called /etc/docker/daemon.json with the following:<br /> <br /> {<br /> &quot;default-address-pools&quot;:<br /> [<br /> {&quot;base&quot;:&quot;10.1.0.0/16&quot;,&quot;size&quot;:24}<br /> ]<br /> }<br /> <br /> Followed by:<br /> <br /> sudo service docker restart</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=HowTo&diff=4740 2024-03-25T15:10:16Z

<p>Rhunter: </p> <hr /> <div>*[[Howto::Firewall|Protecting a service using a firewall]]<br /> <br /> *[[Network_Printers|Connect to Shared Printer]]<br /> <br /> *[[CS_Backups|Setting up a back-up to our central backup system]]<br /> <br /> *[[Howto::CSThunderbird|Configuring thunderbird to use CS email]]<br /> <br /> *[[Spam Controls|How to use CS spam controls]]<br /> <br /> *[[Howto::PersonalSite|How to create your personal website]]<br /> <br /> *[[Howto::WebWritableDir|Make a directory writable by webscripts for interactive websites]]<br /> <br /> *[[Howto::SSLRedirect|Redirect a webpage to SSL/HTTPS encrypted on CS Hosting]]<br /> <br /> *[[Share|Connect to a share on share.cs.vt.edu]]<br /> <br /> *[[Howto::MountHome|Mount your CS home directory on your PC]]<br /> <br /> *[[Howto::Docker Registry|Use CS Docker Image Registry]]<br /> <br /> *[[Howto::Export Git|Copy repo between git.cs.vt.edu and version.cs.vt.edu]]<br /> <br /> *[[Howto::Resize LVM|How to resize your VM disk to use full space]]<br /> <br /> *[[Howto::VScode|How to connect VSCode to rlogin.cs.vt.edu]]<br /> <br /> *[[Howto::High Risk|How to make your machine high risk compliant]]<br /> <br /> *[[Howto::Access rlogin service|How to access rlogin/glogin service]]<br /> <br /> *[[HowTo:CS_Launch|Using the CS Launch Service (kubernetes cluster)]]<br /> <br /> *[[HowTo:Docker 172 Fix|Fix your docker install to coexist on VT (172) network]]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4727 2024-01-24T19:30:04Z

<p>Rhunter: /* CBB: Mnemosyne */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: 64 <br /> *** Ram: 512GB<br /> ** Network: 10Gbit low latency SFP+ interconnect<br /> ** Storage: 91 terabytes of dedicated disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 15<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPUs: Multiple NVidia P40, T4, A2 GPUs<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 174 TB of dedicated CEPH storage<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 73TB<br /> <br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10Gbit interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4726 2024-01-24T19:29:42Z

<p>Rhunter: /* Systems Cluster */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: 64 <br /> *** Ram: 512GB<br /> ** Network: 10Gbit low latency SFP+ interconnect<br /> ** Storage: 91 terabytes of dedicated disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 15<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPUs: Multiple NVidia P40, T4, A2 GPUs<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 174 TB of dedicated CEPH storage<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 73TB<br /> <br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10GB interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4725 2024-01-24T19:29:12Z

<p>Rhunter: /* CSRVM */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: 64 <br /> *** Ram: 512GB<br /> ** Network: 10Gbit low latency SFP+ interconnect<br /> ** Storage: 91 terabytes of dedicated disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 15<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPUs: Multiple NVidia P40, T4, A2 GPUs<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 174 TB of dedicated CEPH storage<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10GB interconnected Nodes and Storage<br /> ** Storage: 73TB<br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10GB interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4724 2024-01-24T19:28:34Z

<p>Rhunter: /* CSRGPU */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: 64 <br /> *** Ram: 512GB<br /> ** Network: 10GB low latency SFP+ interconnect<br /> ** Storage: 91 terabytes of dedicated disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 15<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPUs: Multiple NVidia P40, T4, A2 GPUs<br /> ** Network: 10Gbit interconnect<br /> ** Storage: 174 TB of dedicated CEPH storage<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10GB interconnected Nodes and Storage<br /> ** Storage: 73TB<br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10GB interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4723 2024-01-24T19:26:34Z

<p>Rhunter: /* CSRVM */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: 64 <br /> *** Ram: 512GB<br /> ** Network: 10GB low latency SFP+ interconnect<br /> ** Storage: 91 terabytes of dedicated disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 15<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPUs: Multiple Nvidia P40, T4, A2<br /> ** Network: 10Gbit interconnect<br /> ** Storage: Dedicated CEPH shared file system<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10GB interconnected Nodes and Storage<br /> ** Storage: 73TB<br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10GB interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4722 2024-01-24T19:26:00Z

<p>Rhunter: /* CSRGPU */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: 64 <br /> *** Ram: 512GB<br /> ** Network: 10GB low latency SFP+ back-end network interconnecting each node<br /> ** Storage: 91 terabytes of dedicated disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 15<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPUs: Multiple Nvidia P40, T4, A2<br /> ** Network: 10Gbit interconnect<br /> ** Storage: Dedicated CEPH shared file system<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10GB interconnected Nodes and Storage<br /> ** Storage: 73TB<br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10GB interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4721 2024-01-24T19:24:51Z

<p>Rhunter: /* CSRGPU */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: 64 <br /> *** Ram: 512GB<br /> ** Network: 10GB low latency SFP+ back-end network interconnecting each node<br /> ** Storage: 91 terabytes of dedicated disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 15<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPU's: Multiple Nvidia P40, T4, A2<br /> ** Network: 10GB back-end network interconnecting each node<br /> ** Storage: Dedicated CEPH shared file system<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10GB interconnected Nodes and Storage<br /> ** Storage: 73TB<br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10GB interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4720 2024-01-24T19:23:08Z

<p>Rhunter: /* CSRGPU */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: 64 <br /> *** Ram: 512GB<br /> ** Network: 10GB low latency SFP+ back-end network interconnecting each node<br /> ** Storage: 91 terabytes of dedicated disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 10<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPU's: Multiple Nvidia P40, T4, A2<br /> ** Network: 10GB back-end network interconnecting each node<br /> ** Storage: Dedicated CEPH shared file system<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10GB interconnected Nodes and Storage<br /> ** Storage: 73TB<br /> == Kubernetes Clusters ==<br /> === Discovery ===<br /> * Hardware:<br /> ** Nodes: 24 (Compute)<br /> *** Cores: 1100<br /> *** RAM: 3.2TB<br /> ** Storage: 34TB<br /> === Endeavour ===<br /> * Hardware:<br /> ** Nodes: 12 (Compute)<br /> *** Cores: 728<br /> *** GPU's: 12<br /> *** RAM: 5.2TB<br /> ** Storage: 42TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10GB interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter http://wiki.cs.vt.edu/index.php?title=Grant_Proposal&diff=4559 2023-10-27T17:30:30Z

<p>Rhunter: /* CSRGPU */</p> <hr /> <div>= Introduction =<br /> This page has been created as a quick reference which gathers all the available resources in a single location for the purposes of writing Grant Proposals. If you see an outdated resource or a missing resource please contact techstaff@cs.vt.edu.<br /> <br /> = Resources Available in the Department =<br /> == RLogin ==<br /> * Hardware:<br /> ** Nodes: 32 Compute 5 GPU<br /> *** Cores: 32 Intel<br /> *** RAM: 384GB<br /> *** Storage: 1TB<br /> ** Network: 10Gbit interconnect<br /> <br /> == CSRVM ==<br /> To facilitate wide ranging research activities, some of the major services provided by the department include a Computer Science Research Virtual Machine cluster (CSRVM) which has the flexibility to create multi-core large scale VM's in a matter of minutes. <br /> <br /> * Hardware:<br /> ** Nodes: 9<br /> *** Cores: 64 <br /> *** Ram: 512GB<br /> ** Network: 10GB low latency SFP+ back-end network interconnecting each node<br /> ** Storage: 91 terabytes of dedicated disk storage.<br /> <br /> == CSRGPU ==<br /> This GPU Virtual Machine cluster is dedicated to GPU computation research. This is an excellent resource for prototyping small scale models in a virtual GPU environment before scaling up to larger hardware.<br /> * Hardware:<br /> ** Nodes: 10<br /> *** Cores: At least 40<br /> *** Ram: At least 192GB<br /> ** GPU's: Multiple Nvidia P40 and T4's<br /> ** Network: 10GB low latency SFP+ back-end network interconnecting each node<br /> ** Storage: Dedicated CEPH shared file system<br /> <br /> == Systems Cluster ==<br /> In addition, Computer Science has a ten (10) node homogeneous cluster, dedicated to systems research. <br /> * Hardware:<br /> ** Nodes: 10 (Homogeneous)<br /> *** Cores: 48 (Intel)<br /> *** RAM: 256GB<br /> ** Network: 10GB interconnected Nodes and Storage<br /> ** Storage: 73TB<br /> <br /> == CBB: Mnemosyne ==<br /> High memory computation system, dedicated to computational bioinformatics research.<br /> * Hardware:<br /> ** Nodes: 1<br /> *** Cores: 64 (Intel)<br /> *** RAM: 7686GB<br /> ** Network: 10GB interconnected to Storage<br /> ** Storage: 30TB<br /> <br /> == Secure Server Room &amp; Graduate Area ==<br /> The Computer Science department has a secure, modern, climate-controlled server room. The room is equipped with numerous sensors, controls, and backup systems to ensure all servers are continuously operating at peak performance. In addition, there is a separate secure, climate-controlled workspace for graduate students to work directly with servers and equipment, if appropriate.<br /> <br /> = Resources Available from the University = <br /> [https://arc.vt.edu/ Advanced Research Computing - ARC]</div>

Rhunter