Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My company runs a handful of OpenVZ servers (HN) and hosts all the server as containers on these HNs.

We have done some pentest and found out we have to do update the kernel on the HNs to resolve a potential security issue. The servers have huge amounts of storage and are geographically scattered so having a redundant server for every single server is out of the question. But the HN themselves aren't so big. So here's the scenario I have come up with.

  1. Back up the HN operating system which is CentOS (different versions from 5.4 to 5.6)
  2. Perfrom the yum update
  3. Reboot the HN but skip fsck on any partition other than the HN OS partition
  4. Unmount the containers one by one and fsck them one by one

Can you think of a better scenario? Another thing I thought of was somehow replicating the host machine and trying the update on that replica before actually running it on the real machine.

Any idea how I can do that? This is my machine. I only need the / for doing the host upgrade.

[root@host ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             1.8T   13G  1.7T   1% /
/dev/sda1              99M   46M   48M  50% /boot
tmpfs                  16G     0   16G   0% /dev/shm
/dev/sdb1             1.8T  350G  1.4T  21% /mnt/disk0
/dev/sdb2             1.8T  208G  1.5T  13% /mnt/disk1
share|improve this question
So basically you want to skip the fsck for your containers after reboot? How can the replication of the host machine help you there? – Nils Mar 7 '12 at 20:40
No HA and no redundancy? – Nils Mar 7 '12 at 20:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.