VMLab: Difference between revisions

From Unallocated Space
Jump to navigation Jump to search
No edit summary
No edit summary
 
(10 intermediate revisions by 2 users not shown)
Line 3: Line 3:
The rationale for this implementation was to reduce the barrier for project creation and facilitate ad hoc experimentation. It was my goal to make this minimally intimidating for inexperienced users.
The rationale for this implementation was to reduce the barrier for project creation and facilitate ad hoc experimentation. It was my goal to make this minimally intimidating for inexperienced users.


A secondary goal was to add
A secondary goal was to make sure this would be as useful as possible for instructors and members who wanted to run in-house services.
I thought it easiest if those who were less confident had a familiar interface and I didn't suspect anyone regardless of experience will be offended by a GUI, so I opted for a browser based system.
I thought it easiest if those who were less confident had a familiar interface and I didn't suspect anyone regardless of experience will be offended by a GUI, so I opted for a browser based system.


Line 9: Line 9:
Here's a link of just the interface: https://raw.githubusercontent.com/kimchi-project/kimchi/master/docs/kimchi-templates.png
Here's a link of just the interface: https://raw.githubusercontent.com/kimchi-project/kimchi/master/docs/kimchi-templates.png


<H1>EXPERIMENTATION IS ENCOURAGED!</H1>
<H1>How does it work?</H1>


From the web interface, users can create VM's (guests) from template (Pre-made / provisioned VM's), monitor usage, and access the console.
From the web interface, users can create VM's (guests) from template (Pre-made / provisioned VM's), monitor usage, and access the console. That means that any device that can run a web browser can in essence be used as a powerful server or specialized lab environment. This is good for classes, or designing your own services to run in the space.


Anyone on the UAS network can access the VM-lab.
<H2>Login Info </H2>
<H2>Login Info </H2>


These credentials are suitable for anyone looking to use the vmlab as a sandbox.
[https://10.0.1.8:8001 Kimchi]
<br> If you want a specialized machine/template, ask flay</br>


[https://10.0.0.20:8001 Kimchi]
You can use your LDAP credentials.
<br>uname: vmlab
<br>pw: uas


<br><br>
<br> If you want a specialized machine/template to clone later, ask flay</br>


<h2>VMLABS physical Specs</h2>
<h2> Requesting a VM </h2>
<br>
Ask flay on slack and tell him exactly what you need. If you're not sure, explain your goal and he'll try to set it up. If you need something more complex feel free to ask for administrative access to make your own.
MODEL:Dell Poweredge R710
Every student Guest (VM) will be set up via administrator-created template.
OS:Ubuntu CentOS 7 LTS: 3.10.0-327.el7.x86_64
<br>RAM: 190GB
<br>CPU: 2 x Intel Xeon x5560 (2.8GHZ) [https://ark.intel.com/products/37109/Intel-Xeon-Processor-X5560-8M-Cache-2_80-GHz-6_40-GTs-Intel-QPI]
<br>HDD: 1.4TB
RAID: 6


<h3> Administrator Notes </h3>
When creating a new Guest requiring internet access you'll have to add the "phybridge" device (located in kimchi under the admin account) you MUST do this after creating the guest. Create the guest, power it off, edit it, add the bridged adapter, restart. Then you can modify the device to assign a static ip. In the centOS minimal boxes this can be done via the respective /etc/sysconfig/network-scripts/ifcfg-eth file


<h2> System Architecture </h2>
Don't give Guests names which contain spaces. You'll get insane errors.
Every student Guest (VM) will be set up via administrator-created template.


<h3>Important Paths</h3>
This is where all iso images go
/var/lib/kimchi/iso's


<H2> Setup Info </H2>
This is where the XML templates are kept
Disable SELinux
/etc/libvirt/qemu
Grab kimchi via packages


<h2>Importing from OVA </h2>


<h3> Administrator Notes </h3>
OVA files are a common way to pass around VM's, but you cannot import them directly into a template.
When creating a new Guest requiring internet access you'll have to add the "phybridge" device (located in kimchi under the admin account) you MUST do this after creating the guest. Create the guest, power it off, edit it, add the bridged adapter, restart. Then you can modify the device to assign a static ip. In the centOS minimal boxes this can be done via the respective /etc/sysconfig/network-scripts/ifcfg-eth file


Don't give Guests names which contain spaces. You'll get insane errors.
#OVA files are actually archives, so the first step is to extract them (tar -xzf example.ova)
# Convert the virtual disk (.vmdk) into a qcow2 format using an invocation like: qemu-img convert -O qcow2 example.vmdk example.qcow2




Line 55: Line 52:
# Create vmlab architecture diagram
# Create vmlab architecture diagram
# Set agenda for individual boxes & services plan
# Set agenda for individual boxes & services plan
# Set up/demo Ovirt


<h2>VMLABS physical Specs</h2>
<br>
MODEL:Dell Poweredge R710
OS:Ubuntu CentOS 7 LTS: 3.10.0-327.el7.x86_64
<br>RAM: 190GB
<br>CPU: 2 x Intel Xeon x5560 (2.8GHZ) [https://ark.intel.com/products/37109/Intel-Xeon-Processor-X5560-8M-Cache-2_80-GHz-6_40-GTs-Intel-QPI]
<br>HDD: 1.4TB
RAID: 6


<h3>Links</h3>
<h3>Links</h3>
Line 63: Line 67:
<br>[https://www.linux.com/news/kvm-or-xen-choosing-virtualization-platform : kvm or xen]
<br>[https://www.linux.com/news/kvm-or-xen-choosing-virtualization-platform : kvm or xen]
<br>[[Ovirt]]
<br>[[Ovirt]]
<h2> VM Networking </h2>
For networking it's important to set up a route.
On Ubuntu hosts you must run
```ip route add default via 10.0.1.1 dev #interface_name```
<h2> Packages available on base vm </h2>
===Centos7===
net-tools
tmux
vim
<h2> Steps to recreate this lab </h2>
[[Recreate]]
[[Category:Project]]

Latest revision as of 14:09, 21 June 2023

VMLAB Overview

The rationale for this implementation was to reduce the barrier for project creation and facilitate ad hoc experimentation. It was my goal to make this minimally intimidating for inexperienced users.

A secondary goal was to make sure this would be as useful as possible for instructors and members who wanted to run in-house services. I thought it easiest if those who were less confident had a familiar interface and I didn't suspect anyone regardless of experience will be offended by a GUI, so I opted for a browser based system.

I did this through a management interface called Kimchi, which is a plugin for the wok webserver (Interacts with nginx). ginger is used as a plugin mgmt system. the whole thing is backed by KVM acting as a hypervisor. Here's a link of just the interface: https://raw.githubusercontent.com/kimchi-project/kimchi/master/docs/kimchi-templates.png

How does it work?

From the web interface, users can create VM's (guests) from template (Pre-made / provisioned VM's), monitor usage, and access the console. That means that any device that can run a web browser can in essence be used as a powerful server or specialized lab environment. This is good for classes, or designing your own services to run in the space.

Anyone on the UAS network can access the VM-lab.

Login Info

Kimchi

You can use your LDAP credentials.


If you want a specialized machine/template to clone later, ask flay

Requesting a VM

Ask flay on slack and tell him exactly what you need. If you're not sure, explain your goal and he'll try to set it up. If you need something more complex feel free to ask for administrative access to make your own. Every student Guest (VM) will be set up via administrator-created template.

Administrator Notes

When creating a new Guest requiring internet access you'll have to add the "phybridge" device (located in kimchi under the admin account) you MUST do this after creating the guest. Create the guest, power it off, edit it, add the bridged adapter, restart. Then you can modify the device to assign a static ip. In the centOS minimal boxes this can be done via the respective /etc/sysconfig/network-scripts/ifcfg-eth file

Don't give Guests names which contain spaces. You'll get insane errors.

Important Paths

This is where all iso images go /var/lib/kimchi/iso's

This is where the XML templates are kept /etc/libvirt/qemu

Importing from OVA

OVA files are a common way to pass around VM's, but you cannot import them directly into a template.

  1. OVA files are actually archives, so the first step is to extract them (tar -xzf example.ova)
  2. Convert the virtual disk (.vmdk) into a qcow2 format using an invocation like: qemu-img convert -O qcow2 example.vmdk example.qcow2


TODO

  1. Document KVM architecture
  2. Configure Firewalld
  3. Document Kimchi startup procedure
  4. Create vmlab architecture diagram
  5. Set agenda for individual boxes & services plan

VMLABS physical Specs


MODEL:Dell Poweredge R710 OS:Ubuntu CentOS 7 LTS: 3.10.0-327.el7.x86_64
RAM: 190GB
CPU: 2 x Intel Xeon x5560 (2.8GHZ) [1]
HDD: 1.4TB RAID: 6

Links

: Kimchi
: Wok
: kvm or xen
Ovirt

VM Networking

For networking it's important to set up a route.

On Ubuntu hosts you must run ```ip route add default via 10.0.1.1 dev #interface_name```

Packages available on base vm

Centos7

net-tools tmux vim

Steps to recreate this lab

Recreate