apt-get -y install ntpdate
locale-gen en_US en_US.UTF-8
dpkg-reconfigure locales
dpkg-reconfigure tzdata
/usr/sbin/vzctl stop <ctid>
/usr/sbin/vzctl set <ctid> --capability sys_time:on --save
/usr/sbin/vzctl start <ctid>
Sunday, June 28, 2015
Rejoin hardware node to Proxmox cluster
service pvestatd stop
service pvedaemon stop
service cman stop
killall -9 corosync cman dlm_controld fenced
service pve-cluster stop
rm /etc/cluster/cluster.conf
rm -rf /var/lib/pve-cluster/* /var/lib/pve-cluster/.*
rm /var/lib/cluster/*
rm -rf /var/lib/pve-cluster/* /var/lib/pve-cluster/.*
rm /var/lib/cluster/*
// check versions - make sure it is running same version (kernel) as other nodes
uname -a
uname -a
pveversion -v (look for Running kernel: ... )
reboot (you have to reboot!)
After rebooting, you can add the node as usual:
pvecm add <IP address of one of the nodes already in the cluster>
After rebooting, you can add the node as usual:
pvecm add <IP address of one of the nodes already in the cluster>
Backup OpenVZ container CT to another hardware node for automatic scheduled remote backup
Proxmox does have a nice user interface which allows you to backup any OpenVZ container (even when it is live - using snapshot). Did you know you can also do the same from command line?
You can use vzdump!
For example:
vzdump 104 --mode snapshot --compress lzo --stdout | ssh 10.0.1.1 "cat > /mnt/backup/vz/104/vzdump-openvz-104-2013_05_18-11_00_00.tar.lzo"
The above command will backup
CT 104
using 'snapshot' mode (live - without needing to shut it down)
with compression LZO mode
stores it to another server (in this example 10.0.1.1) using SSH
to a remote directory and filename:
/mnt/backup/vz/104/vzdump-openvz-104-2013_05_18-11_00_00.tar.lzo
Why is this useful? well... for daily / routine backup of course! Imagine never having to worry about backing up your VM ever again once you set this command nicely in your crontab. :-)
You can use vzdump!
For example:
vzdump 104 --mode snapshot --compress lzo --stdout | ssh 10.0.1.1 "cat > /mnt/backup/vz/104/vzdump-openvz-104-2013_05_18-11_00_00.tar.lzo"
The above command will backup
CT 104
using 'snapshot' mode (live - without needing to shut it down)
with compression LZO mode
stores it to another server (in this example 10.0.1.1) using SSH
to a remote directory and filename:
/mnt/backup/vz/104/vzdump-openvz-104-2013_05_18-11_00_00.tar.lzo
Why is this useful? well... for daily / routine backup of course! Imagine never having to worry about backing up your VM ever again once you set this command nicely in your crontab. :-)
Removing openvz container CT manually from Proxmox
/etc/vz/conf/<ctid>.*
there may be .mount files here, just back them up to /root/ but don't worry, vzdump back up these configuration files too.
vzrestore will restore .mount files also.
/var/lib/vz/root/<ctid> may contain fastboot file. just move this also to /root/ just in case
this could be the directory used if local storage is used for container
where the actual CT was:
/mnt/md0/private/
notes:
vzdump also backs up <ctid> configuration find and <ctid>.mount files and vzrestore restores conf and .mount files just fine.
Increase open file limit number of open file limit on HN host node and vm / ct
DO THIS IN HN (hardware nodes):
nano /etc/security/limits.conf
# wildcard does not work for root, but for all other users
* soft nofile 65536
* hard nofile 65536
# settings should also apply to root
root soft nofile 65536
root hard nofile 65536
ulimit -n 65536
do not need to modify pam limits
-----------------------------------------------
for each CTs we also need to do this:
Fix repair replace broken failed RAID mirrored hard drive from proxmox hardware node HN MD0
** REBOOT NOT REQUIRED FOR HOT-SWAP DRIVE BAY **
cat /proc/mdstat
FROM SDB TO SDC:
dd if=/dev/zero of=/dev/sdc bs=512 count=1
sfdisk -d /dev/sdb | sfdisk --force /dev/sdc
mdadm --manage /dev/md0 --add /dev/sdc1
FROM SDC TO SDB:
dd if=/dev/zero of=/dev/sdb bs=512 count=1
sfdisk -d /dev/sdc | sfdisk --force /dev/sdb
mdadm --manage /dev/md0 --add /dev/sdb1
cat /proc/mdstat
Proxmox repair fix md127 issue raid1 software raid broke from md0 to md 127 after some time
first try to examine the array:
cat /proc/mdstat
examine each of the array:
mdadm --detail /dev/md0
mdadm --detail /dev/md127
Take note of the UUID of each array, they should be the SAME
example: 02068dc1:63b677bb:e3f0cfcc:8ccc0d3b
next, examine the current mdadm scan result:
mdadm --detail --scan
to fix this problem basically we need to do the following:
add the ARRAY line to /etc/mdadm/mdadm.conf then update initrd image to read and include new setting in mdadm.conf, then reboot
nano /etc/mdadm/mdadm.conf
add this line under the # definitions of existing MD arrays:
ARRAY /dev/md0 UUID=02068dc1:63b677bb:e3f0cfcc:8ccc0d3b
update the initrd image:
update-initramfs -u
reboot
after reboot comes back... examine the array again... you may need to add non-included drives like this:
mdadm --manage /dev/md0 --add /dev/sdb1
monitor rebuilding progress:
cat /proc/mdstat
That is all!
Proxmox hardware node and openvz container increase shared memory SHMMAX SHMMNI limits
Example uses CT 118 (OpenVZ container ID 118) for example.
Login to your hardware node
vzctl stop 118
vzctl set 118 --kmemsize unlimited --save
vzctl set 118 --lockedpages unlimited --save
vzctl set 118 --privvmpages unlimited --save
vzctl set 118 --shmpages unlimited --save
vzctl set 118 --numproc unlimited --save
vzctl set 118 --numtcpsock unlimited --save
vzctl set 118 --numflock unlimited --save
vzctl set 118 --numpty unlimited --save
vzctl set 118 --numsiginfo unlimited --save
vzctl set 118 --tcpsndbuf unlimited --save
vzctl set 118 --tcprcvbuf unlimited --save
vzctl set 118 --othersockbuf unlimited --save
vzctl set 118 --dgramrcvbuf unlimited --save
vzctl set 118 --numothersock unlimited --save
vzctl set 118 --dcachesize unlimited --save
vzctl set 118 --numfile unlimited --save
vzctl set 118 --numiptent unlimited --save
(for elasticsearch... set memlock to unlimited by: vzctl set <CT_NUM> --memlock unlimited --save )
nano /etc/sysctl.conf
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144
/sbin/sysctl -p
vzctl start 118
vzctl enter 118
nano /etc/sysctl.conf
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
/sbin/sysctl -p
exit
vzctl stop 118
vzctl start 118
Add second mirrored raid 1 hard drive to software raid 1 /dev/md0 md0 on hardware node
# SDB is the first hard drive
# SDC is the second hard drive
# only one partition for each drive
# sfdisk -d /dev/sdb | sfdisk --force /dev/sdc (copies partition table from sdb to sdc)
-----------------------
cat /proc/mdstat
dd if=/dev/zero of=/dev/sdc bs=512 count=1
sfdisk -d /dev/sdb | sfdisk --force /dev/sdc
mdadm --manage /dev/md0 --add /dev/sdc1
cat /proc/mdstat
-----------------------
example how it should look like after partitioned:
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
81 heads, 63 sectors/track, 191411 cylinders
Units = cylinders of 5103 * 512 = 2612736 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x31961bff
Device Boot Start End Blocks Id System
/dev/sdb1 1 191412 488385560 fd Linux raid autodetect
-------------
Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdc1 1 60802 488385560 fd Linux raid autodetect
///////////////////////////////////////
if SDC is source and SDB is the target:
dd if=/dev/zero of=/dev/sdb bs=512 count=1
sfdisk -d /dev/sdc | sfdisk --force /dev/sdb
mdadm --manage /dev/md0 --add /dev/sdb1
How to manually backup an OpenVZ container from command line for Promox
first try to examine the array:
cat /proc/mdstat
examine each of the array:
mdadm --detail /dev/md0
mdadm --detail /dev/md127
Take note of the UUID of each array, they should be the SAME
example: 02068dc1:63b677bb:e3f0cfcc:8ccc0d3b
next, examine the current mdadm scan result:
mdadm --detail --scan
to fix this problem basically we need to do the following:
add the ARRAY line to /etc/mdadm/mdadm.conf then update initrd image to read and include new setting in mdadm.conf, then reboot
nano /etc/mdadm/mdadm.conf
add this line under the # definitions of existing MD arrays:
ARRAY /dev/md0 UUID=02068dc1:63b677bb:e3f0cfcc:8ccc0d3b
update the initrd image:
update-initramfs -u
reboot
after reboot comes back... examine the array again... you may need to add non-included drives like this:
mdadm --manage /dev/md0 --add /dev/sdb1
monitor rebuilding progress:
cat /proc/mdstat
That is all!
Subscribe to:
Posts (Atom)