Virt
Virtual box tip for running netbsd
$ VBoxSDL --norawr0 --startvm netbsd
Not tested yet.
XEN
fix vnc port
For HVM’s: vnc=1 # Enable VNC vncconsole=0 # Don’t start vncviewer after “create” the domain vncunused=0 # Don’t automatically assign unused port based on domain id vncdisplay=2 # VNC Port Number to be added to “59”. e.g.: vncdisplay=2 : port=5902 , vncdisplay=30 : port 5930 For PV’s vfb=["type=vnc,vncunused=0,vncdisplay=44"]
Full example HVM for boot from CD
name = "test-w7" maxmem = 1024 memory = 1024 vcpus = 2 cpu_weight = 128 builder = "hvm" kernel = "/usr/lib/xen-4.1/boot/hvmloader-slic" boot = "dc" pae = 1 acpi = 1 apic = 1 localtime = 0 on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" device_model = "/usr/lib/xen-4.1/bin/qemu-dm" sdl = 0 vnc=1 # Enable VNC vncconsole=0 # do not start vncviewer after create the domain vncunused=0 # do not automatically assign unused port based on domain id vncdisplay=12 # VNC Port Number to be added to 5900 vncpasswd='2' vnclisten="0.0.0.0" usbdevice='tablet' keymap = "en-gb" disk = [ "file:windows7.iso,hda:cdrom,r", "phy:/dev/disk1/w7,hdc,w" ] vif = [ "mac=00:50:56:03:A5:fe,bridge=xenbr0" ] parallel = "none" serial = "pty"
Full example HVM boot from drive C
name = "w2008" maxmem = 512 memory = 512 vcpus = 1 cpu_weight = 128 builder = "hvm" kernel = "/usr/lib/xen-4.1/boot/hvmloader-slic" boot = "cd" pae = 1 acpi = 1 apic = 1 localtime = 0 on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" device_model = "/usr/lib/xen-4.1/bin/qemu-dm" sdl = 0 vnc=1 # Enable VNC vncconsole=0 # do not start vncviewer after create the domain vncunused=0 # do not automatically assign unused port based on domain id vncdisplay=11 # VNC Port Number to be added to 5900 vncpasswd='2' vnclisten="0.0.0.0" usbdevice='tablet' keymap = "en-gb" disk = [ "phy:/dev/disk1/w2008,hdc,w" ] vif = [ "mac=00:50:56:1C:21:85,bridge=xenbr0" ] parallel = "none" serial = "pty"
Slic Support
NOTICE: For educational purposes only.
For Debian Wheezy and Xen 4.14 ( should work with plenty of other versions.
1. I suggest you install the version of Debian you intend to use as Dom0 on Virtual Box / Vmware player etc and build the hvmloader on that. This way you don't need to install the sources and build tools on your Dom0, which is usually better kept small.
2. Login in to your build machine, I normally enable ssh and use that because the Virtual Box console does not have good support for cut / paste.
3. You grab the xen sources, like
apt-get source en whichever version you use.
4. Then get all the dependencies:
apt-get build-dep xen so you can actually build the thing.
Note: I am sure on previous releases of debian Xen was in two parts, Xen the kernel and Xen-tools. You may need the Xen-Tools package instead of the Xen. It's the same process once you find the "Tools" build area. (xen-4.1.4/tools)
Next, get the build stuff if you don't have it. Theese are always good to have:
apt-get install kernel-package build-essential
Once installed cd into the Source tree to the folder: /root/xen-4.1.4/tools/firmware/hvmloader/acpi
5. Start by copying all the files you are about to change to a safe copy, ie cp build.c build.c.orig, that way you can revert quickly if you need to.
6. Next we need a Binary version of the Slic 2.1 bios table to convert to a hex file in the form of a C header file.
So get a BIN dump of the SLIC bios (from google search) stick it in the slic.h header file, as below.
The slic.h is a file, consisting of a simple c data file, with the slic bin inside it. The BIN is a regular BIOS modding bin, as it just contains the SLIC.
xxd -i HPQOEM.SLIC-CPC.bin | grep -v len | sed 's/unsigned char.*/unsigned char SLIC[] = {/' > slic.h
copy the slic.h file to the source tree /root/xen-4.1.4/tools/firmware/hvmloader/acpi
7. Next, you need to set the marker etc in the acpi2 file, in the OEM fields
Assuming you are in the acpi folder:
sed -i -e 's/#define ACPI_OEM_ID.*"Xen"/#define ACPI_OEM_ID "HPQOEM"/' acpi2_0.h sed -i -e 's/#define ACPI_OEM_TABLE_ID.*"HVM"/#define ACPI_OEM_TABLE_ID "SLIC-CPC"/' acpi2_0.h
8. Edit build.c, you need to add an include line near the top of the file just bellow the line that reads:
#include "acpi2_0.h"
So it becomes:
#include "acpi2_0.h" #include "slic.h"
9. In the same file. Add the code for SLIC header. The code is supposed to be inside the function "construct_secondary_tables" at the end, just before:
table_ptrs[nr_tables] = 0; return align16(offset); /pre> The Code: <pre> /* SLIC */ memcpy(&buf[offset], SLIC, sizeof(SLIC)); table_ptrs[nr_tables++] = (unsigned long)&buf[offset]; offset += align16(sizeof(SLIC));
So it becomes:
offsetof(struct acpi_header, checksum),
tcpa->header.length);
}
}
/* SLIC */
memcpy(&buf[offset], SLIC, sizeof(SLIC));
table_ptrs[nr_tables++] = (unsigned long)&buf[offset];
offset += align16(sizeof(SLIC));
table_ptrs[nr_tables] = 0;
return align16(offset);
}
Now, this is simple bit, just go to the xen source root of your distro, and do a 'make tools'.
That will result in a new hvmloader file. It's in /root/xen-4.1.4/tools/firmware/hvmloader/ folder. Copy it somewhere, and load your HVM guests up with it, and you have a BIOS with a SLIC 2.1. On Debian I suggest you call in something like hvmloader-slic and put it along side the original file in /usr/lib/xen-4.1/boot/hvmloader-slic
In your Xen config file you need to point to this file like this:
kernel = "/usr/lib/xen-4.1/boot/hvmloader-slic"
OpenVZ
Ram sizes
On the new kernel version (Centos 6 ; debian 6 etc) you can now use:
vzctl set xxx --ram xxxM --swap xxxM --save
It's still worth remembering these:
cid=1000
vzctl set ${cid} --vmguarpages 64M --save
vzctl set ${cid} --oomguarpages 64M --save
vzctl set ${cid} --privvmpages 64M:128M --save
256MB Guaranteed, 512MB Burstable
cid=1000
vzctl set ${cid} --vmguarpages 256M --save
vzctl set ${cid} --oomguarpages 256M --save
vzctl set ${cid} --privvmpages 256M:512M --save
512MB Guaranteed, 1024MB Burstable
cid=1000
vzctl set ${cid} --vmguarpages 512M --save
vzctl set ${cid} --oomguarpages 512M --save
vzctl set ${cid} --privvmpages 512M:1024M --save
1024MB Guaranteed, 2048MB Burstable
cid=1000
vzctl set ${cid} --vmguarpages 1024M --save
vzctl set ${cid} --oomguarpages 1024M --save
vzctl set ${cid} --privvmpages 1024M:2048M --save
More on Memory
vmguarpages: memory allocation guarantee.
This parameter controls how much memory is available to the Virtual Private Server (i.e. how much memory its applications can allocate by malloc(3) or other standard Linux memory allocation mechanisms). The more clients are served or the more "heavy" the application is, the more memory it needs.
The amount of memory that Virtual Private Server's applications are guaranteed to be able to allocate is specified as the barrier of vmguarpages parameter. The current amount of allocated memory space is accounted into privvmpages parameter, and vmguarpages parameter does not have its own accounting. The barrier and the limit of privvmpages parameter impose an upper limit on the memory allocations. The meaning of the limit for the vmguarpages parameter is unspecified in the current version and should be set to the maximal allowed value (2147483647).
If the current amount of allocated memory space does not exceed the guaranteed amount (the barrier of vmguarpages), memory allocations of Virtual Private Server's applications always succeed. If the current amount of allocated memory space exceeds the guarantee but below the barrier of privvmpages, allocations may or may not succeed, depending on the total amount of available memory in the system.
Starting from the barrier of privvmpages, normal priority allocations and, starting from the limit of privvmpages, all memory allocations made by the applications fail.
The memory allocation guarantee (vmguarpages) is a primary tool for controlling the memory available to Virtual Private Servers, because it allows administrators to provide Service Level Agreements -- agreements guaranteeing certain quality of service, certain amount of resources and general availability of the service. The unit of measurement of vmguarpages values is memory pages (4KB on 32-bit Intel-family processes). The total memory allocation guarantees given to Virtual Private Servers are limited by the physical resources of the computer -- the size of RAM and the swap space.
privvmpages: memory allocation limit.
Privvmpages parameter allows controlling the amount of memory allocated by applications.
The barrier and the limit of privvmpages parameter control the upper boundary of the total size of allocated memory. Note that this upper boundary doesn't guarantee that the Virtual Private Server will be able to allocate that much memory, neither does it guarantee that other Virtual Private Servers will be able to allocate their fair share of memory. The primary mechanism to control memory allocation is the vmguarpages guarantee.
Privvmpages parameter accounts allocated (but, possibly, not used yet) memory. The accounted value is an estimation how much memory will be really consumed when the Virtual Private Server's applications start to use the allocated memory. Consumed memory is accounted into oomguarpages parameter.
Since the memory accounted into privvmpages may not be actually used, the sum of current privvmpages values for all Virtual Private Servers may exceed the RAM and swap size of the computer.
There should be a safety gap between the barrier and the limit for privvmpages parameter to reduce the number of memory allocation failures that the application is unable to handle. This gap will be used for "high-priority" memory allocations, such as process stack expansion. Normal priority allocations will fail when the barrier if privvmpages is reached.
Total privvmpages should match the physical resources of the computer. Also, it is important not to allow any Virtual Private Server to allocate a significant portion of all system RAM to avoid serious service level degradation for other VPSs.
physpages: total number of RAM pages used by processes in this Virtual Private Server.
For memory pages used by several different Virtual Private Servers (mappings of shared libraries, for example), only a fraction of a page is charged to each Virtual Private Server. The sum of the physpages usage for all Virtual Private Servers corresponds to the total number of pages used in the system by all Virtual Private Servers.
Physpages is an accounting-only parameter currently. In future OpenVZ releases, this parameter will allow to provide guaranteed amount of application memory, residing in RAM and not swappable. For compatibility with future versions, the barrier of this parameter should be set to 0 and the limit to the maximal allowed value (2147483647).
oomguarpages: the guaranteed amount of memory for the case the memory is "over-booked" (out-of-memory kill guarantee).
Oomguarpages parameter is related to vmguarpages. If applications start to consume more memory than the computer has, the system faces an out-of-memory condition. In this case the operating system will start to kill Virtual Private Server's processes to free some memory and prevent the total death of the system. Although it happens very rarely in typical system loads, killing processes in out-of-memory situations is a normal reaction of the system, and it is built into every Linux kernel.
Oomguarpages parameter accounts the total amount of memory and swap space used by the processes of a particular Virtual Private Server. The barrier of the oomguarpages parameter is the out-of-memory guarantee.
If the current usage of memory and swap space (the value of oomguarpages) plus the amount of used kernel memory (kmemsize) and socket buffers is below the barrier, processes in this Virtual Private Server are guaranteed not to be killed in out-of-memory situations. If the system is in out-of-memory situation and there are several Virtual Private Servers with oomguarpages excess, applications in the Virtual Private Server with the biggest excess will be killed first. The failcnt counter of oomguarpages parameter increases when a process in this Virtual Private Server is killed because of out-of-memory situation.
If the administrator needs to make sure that some application won't be forcedly killed regardless of the application's behavior, setting the privvmpages limit to a value not greater than the oomguarpages guarantee significantly reduce the likelihood of the application being killed, and setting it to a half of the oomguarpages guarantee completely pre vents it. Such configurations are not popular because they significantly reduce the utilization of the hardware.
The meaning of the limit for the oomguarpages parameter is unspecified in the current version.
The total out-of-memory guarantees given to the Virtual Private Servers should not exceed the physical capacity of the computer. If guarantees are given for more than the system has, in out-of-memory situations applications in Virtual Private Servers with guaranteed level of service and system daemons may be killed.
Network Notes
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]
Reset Disk Quota
- stop the ct:
% vzctl stop <_CTID_>
- check space on hardwarenode
% du -sh /vz/private/<_CTID_>
- check qouta file
% vzquota show <_CTID_>
- drop qouta entries from file
% vzquota drop <_CTID_>
- (re-)start ct / reinit quota
% vzctl start <_CTID_>
Backup and restore
To backup using vzdump:
vzdump --compress --suspend 100
To restore a container:
vzrestore /vz/dump/vzdump-openvz-110-2012_03_29-12_47_49.tgz 600
Edit the recovered config file:
vi /etc/vz/conf/600.conf change hostname, remove network setup
decide on --ipadd or --netif Add an ip address
vzctl set 600 --ipadd 192.168.3.xxx --save
or
./easymac.sh -r (twice to get two mac address's) vzctl set 600 --netif_add vnet0,00:0c:29:24:b5:f3,vnet1.2,00:0c:29:df:4c:59 --save
The vnet1.2 is of the form vnetx.y x=interface number (must not be in already in use) y is the bridge group ie br0 or br2 you can use:
ifconfig brctl show
To get suitable values.
cd to the container and change / disable the vent device until booted so you don't have duplicate ip address.
cd /vz/private/600/etc/sysconfig/network-scripts/
create add the pts dev entriies:
mkdir /vz/private/600/dev/pts /sbin/MAKEDEV -d /vz/private/600/dev ttyp ptyp
ok to start and enter to change the final setup.
vzctl start 600 vzctl enter 600
Virtual Box
Virtual Box clone a machine
1) Shut down the virtual machine you would like to copy
2) In File > Virtualdiskmanager, select the virtual machine disk image you would like to copy, and press the Release button
3) In a terminal window, issue following command (see virtualbox user manual):
vboxmanage clonevdi /directory/image1.vdi /directory/image2.vdi
4) In File > Virtualdiskmanager, add the new disk image you've created in step 3.
5) In the main virtualbox window, press the New button to create a new virtual machine, and link it to the new disk image you've created.
Change UUID on an image file
OSX example, same for linux but VBoxManage is in the path.
/Applications/VirtualBox.app/Contents/MacOS/VBoxManage internalcommands sethduuid VirtualBox\ VMs/w7-wk/w7.vdi