Linux
OpenVZ
Ram sizes
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.
Grub Notes
To re-install grub manually (mostly for raid systems, if you want more than one drive to be bootable)
grub grub> device (hd0) /dev/sda grub> root (hd0,0) grub> setup (hd0) grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded Done. grub> quit
Repeat above for each drive. Note the (hd0,0) refers to the boot partion.
mdadm
Example: To replace a drive
Fail the drive you want to replace in the array, i.e.
mdadm --manage /dev/mdx --fail /dev/hdxy
shutdown the system, replace the drive.
If the drive is not already blank, you may need to remove any previous raid usage:
boot from cd, rescue mode.
For most commands to work you need an /etc/mdadm.conf.
This can be setup using "mdadm -E --scan >/etc/mdadm.conf"
To get the /etc/mdadm.conf file from the drives in the system.
madam --zero-superblock /dev/hdxy for each partionion.
remove the partitions, recreate from an existing drive
sfdisk -d /dev/hdx | sfdiisk /dev/hdy
start the array used by the root filesystem
madam -A /dev/md1 --force --run
add the new drive/partion to the root md device
madam --manage /dev/md1 --add /dev/hdxy
wait for rebuild
do the same for the /boot patron
finally any data partions you have, these can be done either from a rescue setup or after a reboot.
Growing encrypted disks
This example show a domU client, since the disk is allocated in the Dom0 using lvm, you need to grow that first!
[root@skype ~]# mkdir /data
[root@skype ~]# mount /dev/mapper/data /data
[root@skype ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda 2064208 1499312 460040 77% /
tmpfs 98396 0 98396 0% /dev/shm
/dev/mapper/data 77403712 184220 73287612 1% /data
fdisk -l (to find the correct partion layout/names etc)
Disk /dev/xvdb: 268 MB, 268435456 bytes
255 heads, 63 sectors/track, 32 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/xvdb1 1 32 257008+ 82 Linux swap / Solaris
Disk /dev/xvdc: 107.3 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/xvdc1 1 9790 78638143+ 83 Linux
Use fdisk to remove and re add a partition to grow the disk into
[root@skype ~]# fdisk /dev/xvdc
The number of cylinders for this disk is set to 13054.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/xvdc: 107.3 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/xvdc1 1 9790 78638143+ 83 Linux
Delete and re add partition
Command (m for help): d Selected partition 1 Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-13054, default 1): Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-13054, default 13054): Using default value 13054 Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks.
Re Open the Luks Device
[root@skype ~]# cryptsetup luksOpen /dev/xvdc1 data Enter LUKS passphrase for /dev/xvdc1: padlock: VIA PadLock not detected. key slot 0 unlocked. Command successful.
Make sure crypto is aware of the new size
[root@skype ~]# cryptsetup resize data
Then resize it
[root@skype ~]# fsck.ext3 -f /dev/mapper/data e2fsck 1.39 (29-May-2006) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /data: 30743/9830400 files (0.1% non-contiguous), 546498/19659406 blocks [root@skype ~]# resize2fs /dev/mapper/data resize2fs 1.39 (29-May-2006) Resizing the filesystem on /dev/mapper/data to 26213926 (4k) blocks. The filesystem on /dev/mapper/data is now 26213926 blocks long.
And re-mount it ready for use
[root@skype ~]# mount /dev/mapper/data /data [root@skype ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/xvda 2064208 1499392 459960 77% / tmpfs 98396 0 98396 0% /dev/shm /dev/mapper/data 103210424 960112 97007532 1% /data