Lâmôlabs » virtualization http://www.lamolabs.org/blog Lame Oh Labs .... Linux & Tech! Is there anything else? Thu, 29 Jul 2010 16:00:07 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Keeping CentOS 5 OpenVZ images up to Date with Yum http://www.lamolabs.org/blog/1114/keeping-centos-5-openvz-images-up-to-date-with-yum/ http://www.lamolabs.org/blog/1114/keeping-centos-5-openvz-images-up-to-date-with-yum/#comments Sun, 27 Sep 2009 07:17:14 +0000 slmingol http://www.lamolabs.org/blog/?p=1114 Now that I’ve been using OpenVZ for several months I’d gotten to the point where I wanted/needed to “yum update” all my VEs. I currently have 11 images running on my OpenVZ Server. I thought I could just vzctl exec … yum -y update all the VEs, but quickly ran into some issues with this [...]]]> Now that I’ve been using OpenVZ for several months I’d gotten to the point where I wanted/needed to “yum update” all my VEs. I currently have 11 images running on my OpenVZ Server. I thought I could just vzctl exec … yum -y update all the VEs, but quickly ran into some issues with this brute force approach. Doing the yum -y update broke several of my VEs so I opted to restore the unrecoverable ones from backups.

For my second attempt, I opted to do each VE independently, to get a better understanding of what the best approach would be for doing mass upgrades like this now, and in the future. The first hurdle to overcome had to do with some of the VEs running out of memory (RAM) during the upgrade process.

NOTE: A VE = Virtual Environment (aka. a virtual host), while HN = Host Node

Issue #1, not enough RAM for yum to run

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# RAM budgets for VEs
 
# NOTE: values are in # of pages (1 pg. = 4K)
 
% (printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources)|column -t
vm                       feature      held    maxheld  barrier  limit   failcnt
/proc/bc/101/resources:  privvmpages  31904   82215    65536    69632   2
/proc/bc/102/resources:  privvmpages  119803  196620   166400   179200  9517
/proc/bc/103/resources:  privvmpages  27125   35974    65536    69632   0
/proc/bc/104/resources:  privvmpages  56251   107250   104960   115200  0
/proc/bc/105/resources:  privvmpages  73559   82926    98304    103304  0
/proc/bc/106/resources:  privvmpages  30219   68097    65536    69632   0
/proc/bc/108/resources:  privvmpages  30081   84291    65536    69632   1
/proc/bc/109/resources:  privvmpages  32790   74199    98304    103304  0
/proc/bc/110/resources:  privvmpages  40497   69408    65536    69632   1
/proc/bc/111/resources:  privvmpages  26990   35371    65536    67840   0
 
# NOTE: converted the columns to megabytes (MB), it's just easier to read
 
(printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources|awk '{sub($3,$3*4096/2^20) sub($4,$4*4096/2^20) sub($5,$5*4096/2^20) sub($6,$6*4096/2^20)}1')|column -t
vm                       feature      held     maxheld  barrier  limit    failcnt
/proc/bc/101/resources:  privvmpages  124.625  321.152  256      272      2
/proc/bc/102/resources:  privvmpages  467.98   768.047  650      700      9517
/proc/bc/103/resources:  privvmpages  105.957  140.523  256      272      0
/proc/bc/104/resources:  privvmpages  219.73   418.945  410      450      0
/proc/bc/105/resources:  privvmpages  287.34   323.93   384      403.531  0
/proc/bc/106/resources:  privvmpages  118.043  266.004  256      272      0
/proc/bc/108/resources:  privvmpages  117.504  329.262  256      272      1
/proc/bc/109/resources:  privvmpages  128.086  289.84   384      403.531  0
/proc/bc/110/resources:  privvmpages  158.191  271.125  256      272      1
/proc/bc/111/resources:  privvmpages  105.43   138.168  256      265      0

According to this data 4 of the 11 images had gone over their allocation of RAM. So I tried restarting these and re-running yum update within the problem VEs. Again the update failed and so I needed to increase their allocation of memory. I didn’t want to devote more memory permanently, just a enough temporarily to do the upgrade. So I used this trick to temporarily bump up a VEs allocated memory.

1
2
3
4
5
6
7
8
9

# increase the RAM by 100MB
vzctl set 101 --privvmpages $((256+100))m:$((272+100))m --save
 
# ...
# do the upgrade (yum update)
# ...
 
# decrease the RAM back to the original value
vzctl set 101 --privvmpages 256m:272m --save

For the remaining 3 VEs that needed additional memory I used these commands to increase their allocations of RAM

1
2
3
4
5
6
7
8
9

# cmds. to increase RAM by 100MB
vzctl set 102 --privvmpages $((650+100))m:$((700+100))m --save
vzctl set 108 --privvmpages $((256+100))m:$((272+100))m --save
vzctl set 110 --privvmpages $((256+100))m:$((272+100))m --save
 
# cmds. to decrease
vzctl set 102 --privvmpages 650m:700m --save
vzctl set 108 --privvmpages 256m:272m --save
vzctl set 110 --privvmpages 256m:272m --save

Issue #2, not enough diskspace for yum to run

The next snag I ran into had to do with a couple of the VEs running out of diskspace. And here’s the commands I used to reconfigure more diskspace.

1
2
3
4

# reconfigure with 2GB of diskspace
vzctl set 101 --diskspace 2048M:2252M --save
vzctl set 102 --diskspace 2048M:2252M --save
vzctl set 103 --diskspace 2048M:2252M --save

At this point I was able to yum update all my images, and work through any packages that had been updated.

Issue #3, unfinished yum transactions

One final snag that I didn’t really pick up on until probably the 2nd or 3rd time I went through this “process” was that some of the VEs would report during yum update that there were incomplete transactions, and that I really should run the yum-complete-transaction command. I’d never heard of this command, so I went looking and apparently if yum fails to complete a transaction, it remains queued up, causing you to get warnings during subsequent yum updates. So to get yum-complete-transaction command you need to install a package called yum-utils.

1

yum install yum-utils

Then you’ll want to run yum-complete-transaction. Pay special attention to how many unfinished transactions this command finds. Multiple yum transactions can get queued up so you may need to run yum-complete-transaction multiple times. If you do need to run it more than once, it runs the last unfinished transaction first, and then the 2nd to last, and so on until they’re all completed. Don’t be alarmed if it says it’s removing what appear to be critical packages such as bash. This occured on several of my systems and it turned out that there was multiple bashes installed (at least according to the RPM database) and the unfinished transaction was merely trying to uninstall the previous version, leaving the latest version intact.

A bonus to running yum-complete-transaction, is that it helps reduce the memory footprint that yum needs when it has unfinished transactions vs. when it doesn’t. I was seeing yum using 50-100MB in some cases due to all the unfinished transactions, so fixing this issue helped with minimizing future problems that I may see related to issue #1, not enough RAM.

Final Thoughts

My original plan was that I would create a single OpenVZ image that included everything that I needed as far as packages go, and then selectively turn on and off apps that I didn’t need, like apache, for example. Going forward I’m going to try a completely different approach, and thin out each image to only include the bare minimum, to perform it’s job, i.e. mail server, samba server, etc. This should help out with a lot of redundant updating to all the VEs with packages that only 1 or 2 will actually need. The downside with this approach, and reason I avoided it to begin with, was that it seemed to be more work in maintaining many different images, but in practice this may not be as bad as having a single monolithic image multiplied many times across many VEs.

OpenVZ is still a tremendous tool here. Many times when I ran into a problem, I simply restored an image from backup and then resumed, so this isn’t a slam on it, and more a workflow issue and what’s the best way to manage many instances of machines. Really what I want is a way to manage roles of machines. Perhaps it’s time to revisit using something like puppet?

]]> http://www.lamolabs.org/blog/1114/keeping-centos-5-openvz-images-up-to-date-with-yum/feed/ 0 Managing OpenVZ Instance Descriptions http://www.lamolabs.org/blog/2094/managing-openvz-instance-descriptions/ http://www.lamolabs.org/blog/2094/managing-openvz-instance-descriptions/#comments Mon, 27 Jul 2009 03:31:01 +0000 slmingol http://www.lamolabs.org/blog/?p=2094 I recently discovered that you can assign descriptions to your OpenVZ instances. This isn’t really that surprising but I never really took the the time until now to scan through the vzctl and vzlist man pages. Prior to discovering these more esoteric features of vzctl and vzlist, I’d normally just run this command to see [...]]]> I recently discovered that you can assign descriptions to your OpenVZ instances. This isn’t really that surprising but I never really took the the time until now to scan through the vzctl and vzlist man pages. Prior to discovering these more esoteric features of vzctl and vzlist, I’d normally just run this command to see what’s what with my OpenVZ instances:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# list of all VE instances
% vzlist -a
      CTID      NPROC STATUS  IP_ADDR         HOSTNAME                        
       101         32 running 10.1.1.101      flanders.mydom.net              
       102         49 running 10.1.1.102      lisa.mydom.net                  
       103         36 running -               bart.mydom.net                  
       104         38 running 10.1.1.104      marge.mydom.net                 
       105         34 running 10.1.1.105      homer.mydom.net                 
       106         31 running 10.1.1.106      kang.mydom.net                  
       107         27 running 10.1.1.107      kodos.mydom.net                 
       108         32 running 10.1.1.108      maude.mydom.net                 
       109         30 running 10.1.1.109      nelson.mydom.net                
       110         32 running 10.1.1.110      ralphie.mydom.net               
       111         30 running 10.1.1.111      martin.mydom.net

This had worked fine, but sometimes I’d draw a blank about what’s running in each instance, hence my need for the description column. You can use the following command to see the description of each instance.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# initial description columns for VEs
% vzlist -o ctid,numproc,status,ip,hostname,description
      CTID      NPROC STATUS  IP_ADDR         HOSTNAME                         DESCRIPTION                     
       101         34 running 10.1.1.101      flanders.mydom.net               -                               
       102         49 running 10.1.1.102      lisa.mydom.net                   -                               
       103         35 running -               bart.mydom.net                   -                               
       104         38 running 10.1.1.104      marge.mydom.net                  -                               
       105         34 running 10.1.1.105      homer.mydom.net                  -                               
       106         31 running 10.1.1.106      kang.mydom.net                   -                               
       107         27 running 10.1.1.107      kodos.mydom.net                  -                               
       108         32 running 10.1.1.108      maude.mydom.net                  -                               
       109         30 running 10.1.1.109      nelson.mydom.net                 -                               
       110         32 running 10.1.1.110      ralphie.mydom.net                -                               
       111         30 running 10.1.1.111      martin.mydom.net                 -

I used the following commands to set the description for each VE.

1
2
3
4
5
6
7
8
9
10
11

vzctl set 101 --description "nis server" --save
vzctl set 102 --description "mail,imap,smtp server" --save
vzctl set 103 --description "samba server" --save
vzctl set 104 --description "mysql server" --save
vzctl set 105 --description "www,blog,webmail server" --save
vzctl set 106 --description "trac,git,svn server" --save
vzctl set 107 --description "trac,git,svn server (dev)" --save
vzctl set 108 --description "ldap server (dev)" --save
vzctl set 109 --description "cacti server" --save
vzctl set 110 --description "tracks server" --save
vzctl set 111 --description "wiki server" --save

Re-running the vzlist command from before now shows the newly added descriptions.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# filled out description columns for VEs
% vzlist -o ctid,numproc,status,ip,hostname,description
      CTID      NPROC STATUS  IP_ADDR         HOSTNAME                         DESCRIPTION                     
       101         32 running 10.1.1.101      flanders.mydom.net               nis server                      
       102         49 running 10.1.1.102      lisa.mydom.net                   mail,imap,smtp server           
       103         36 running -               bart.mydom.net                   samba server                    
       104         38 running 10.1.1.104      marge.mydom.net                  mysql server                    
       105         34 running 10.1.1.105      homer.mydom.net                  www,blog,webmail server         
       106         31 running 10.1.1.106      kang.mydom.net                   trac,git,svn server             
       107         27 running 10.1.1.107      kodos.mydom.net                  trac,git,svn server (dev)       
       108         32 running 10.1.1.108      maude.mydom.net                  ldap server (dev)               
       109         30 running 10.1.1.109      nelson.mydom.net                 cacti server                    
       110         32 running 10.1.1.110      ralphie.mydom.net                tracks server                   
       111         30 running 10.1.1.111      martin.mydom.net                 wiki server
]]> http://www.lamolabs.org/blog/2094/managing-openvz-instance-descriptions/feed/ 1 Troubleshooting a Restore of an OpenVZ Image from one Host Node to Another http://www.lamolabs.org/blog/1777/troubleshooting-restore-an-openvz-image-from-one-host-node-to-another/ http://www.lamolabs.org/blog/1777/troubleshooting-restore-an-openvz-image-from-one-host-node-to-another/#comments Tue, 14 Jul 2009 04:30:14 +0000 slmingol http://www.lamolabs.org/blog/?p=1777 I hadn’t tried this before but I figured I could use vzdump to save a Virtual Environment aka. (VE) from one Host Node aka. (HN) and restore it to another Host Node. It turns out that you can do this but there is one gotcha that I [...]]]> .center { margin-left: 5em; margin-right: 5em; }

I hadn’t tried this before but I figured I could use vzdump to save a Virtual Environment aka. (VE) from one Host Node aka. (HN) and restore it to another Host Node. It turns out that you can do this but there is one gotcha that I wasted couple of hours on, so this post is my attempt to hopefully save someone else a couple of hours and also as a beacon for myself the next time I run into this and forget how to work around it.

Firstly I have 2 OpenVZ servers. One has 4 GB of RAM and the 2nd has 1 GB. I started off using vzdump to create a backup of one of my VEs running on the 4 GB HN. I then restored the backed up VE using vzdump on the 1 GB HN. Everything went smoothly up to this point, until I ran the vzlist -a command on the 1 GB HN and was presented with this message:

1
2
3
4
5
6

% vzlist -a
Warning: too large value for PHYSPAGES=0:9223372036854775807 was truncated
Warning: too large value for VMGUARPAGES=33792:9223372036854775807 was truncated
Warning: too large value for OOMGUARPAGES=26112:9223372036854775807 was truncated
      CTID      NPROC STATUS  IP_ADDR         HOSTNAME                        
       201          - stopped 192.168.1.201   flanders.bubba.net

I had never seen this message before and it appeared to be benign in terms of the VE being able to start/stop, but messages like this really get under my skin, so of course I had to burn a few hours to figure out why. There wasn’t really much in the way of blog posts or forum posts either, which kind of surprised me.

To start I researched what these 3 parameters actually controlled.

PARAMETERTypeDefinition
oomguarpages(system)The guaranteed amount of memory for the case the memory is “over-booked” (out-of-memory kill guarantee).
vmguarpages(system)Memory allocation guarantee.
physpages(system)Total number of RAM pages used by processes.

I then poked around and noticed that the /etc/vz/conf/0.conf file on the 1 GB HN looked like this:

1
2
3
4
5
6
7
8
9
10

% more /etc/vz/conf/0.conf 
# This is configuration file for VE0.
# Only UB parameters are processed
#
# Copyright (C) 2006-2008, Parallels, Inc. All rights reserved.
 
ONBOOT="no"
 
# UBC parameters (in form of barrier:limit)
OOMGUARPAGES="2147483647:2147483647"

While on the 4 GB HN system it looked like this:

1
2
3
4
5
6
7
8
9
10

% more /etc/vz/conf/0.conf 
# This is configuration file for VE0.
# Only UB parameters are processed
#
# Copyright (C) 2006-2008, Parallels, Inc. All rights reserved.
 
ONBOOT="no"
 
# UBC parameters (in form of barrier:limit)
OOMGUARPAGES="9223372036854775807:9223372036854775807"

It then dawned on me that the barrier portion of these parameters was the problem. The barrier is the number that comes after the colon in these lines:

1
2
3

Warning: too large value for PHYSPAGES=0:9223372036854775807 was truncated
Warning: too large value for VMGUARPAGES=33792:9223372036854775807 was truncated
Warning: too large value for OOMGUARPAGES=26112:9223372036854775807 was truncated

So a quick change of all the values from 9223372036854775807 to 2147483647 fixed the problem.

This post doesn’t even scratch the surface of all the nuts and bolts of memory management ins and outs within OpenVZ. For more info about OpenVZ memory management you might want to check out these useful links:

]]> http://www.lamolabs.org/blog/1777/troubleshooting-restore-an-openvz-image-from-one-host-node-to-another/feed/ 0 Howto Stop Clock Drift Issues on a CentOS 5 OpenVZ Host Node http://www.lamolabs.org/blog/1739/howto-stop-clock-drift-issuescentos5-openvz-host-node/ http://www.lamolabs.org/blog/1739/howto-stop-clock-drift-issuescentos5-openvz-host-node/#comments Sat, 11 Jul 2009 06:45:58 +0000 slmingol http://www.lamolabs.org/blog/?p=1739 I’ve been dealing with a nagging problem for several months. The problem? I can’t get my OpenVZ Host Node, aka. HN, to keep consistent time. I’ve even been running ntpd, and the time would still invariably drift so that the HN and the Virtual Environments, aka. VEs, running on the HN were all several hours [...]]]> I’ve been dealing with a nagging problem for several months. The problem? I can’t get my OpenVZ Host Node, aka. HN, to keep consistent time. I’ve even been running ntpd, and the time would still invariably drift so that the HN and the Virtual Environments, aka. VEs, running on the HN were all several hours behind. Simply restarting ntpd would temporarily fix the situation, but I shouldn’t have to do that.

So I finally hunkered down and figured out how to solve this problem. These 2 threads proved extremely helpful in determining the fix.

These threads offered 2 fixes to try. The first, was to modify the ntp.conf file so that any server definitions now included the burst & iburst switches like this:

1
2
3
4

# /etc/ntp.conf
...
server 192.168.1.6 burst iburst
...

Adding these switches seemed to help, but then my /var/log/messages log started getting filled with synch attempts by ntpd like these:

1
2
3
4
5
6
7
8
9
10
11
12

Jul 10 03:50:18 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 03:51:24 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 03:59:59 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 04:01:21 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 04:11:52 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 04:15:05 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 04:27:56 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 04:30:06 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 04:41:53 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 04:47:17 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3
Jul 10 05:03:28 mulder ntpd[15032]: synchronized to LOCAL(0), stratum 10
Jul 10 05:12:05 mulder ntpd[15032]: synchronized to 192.168.1.6, stratum 3

The second suggestion was the key tip. It recommended that you add a kernel switch called clock=pmtmr to the grub.conf file. Once I tried this I received a warning message in the dmesg log stating that this switch had been deprecated, and the new switch was now clocksource=acpi_pm.

1
2
3
4
5

% dmesg | grep -i clock
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet clock=pmtmr
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet clock=pmtmr
Warning: clock=pmtmr is deprecated. Use clocksource=acpi_pm.
Real Time Clock Driver v1.12ac

So I modified the grub.conf to incorporate the clocksource switch, rebooted the system, and was rewarded with a cleaner dmesg.

1
2
3
4

% dmesg | grep -i clock
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet clocksource=acpi_pm
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet clocksource=acpi_pm
Real Time Clock Driver v1.12ac

A quick check of /var/log/messages looked good, no more ntpd synch messages:

1
2
3
4
5
6
7
8
9
10
11

Jul 11 00:30:49 mulder ntpd[24578]: ntpd 4.2.2p1@1.1570-o Thu Apr  9 12:53:31 UTC 2009 (1)
Jul 11 00:30:49 mulder ntpd[24579]: precision = 1.000 usec
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface wildcard, ::#123 Disabled
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface lo, ::1#123 Enabled
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface veth103.0, fe80::218:51ff:fe43:8487#123 Enabled
Jul 11 00:30:49 mulder ntpd[24579]: Listening on interface vmbr0, fe80::222:15ff:fe91:c12d#123 Enabled
Jul 11 00:30:55 mulder ntpd[24579]: kernel time sync status 0040
Jul 11 00:30:56 mulder ntpd[24579]: frequency initialized 25.118 PPM from /var/lib/ntp/drift
Jul 11 00:42:51 mulder ntpd[24579]: synchronized to LOCAL(0), stratum 10
Jul 11 00:43:54 mulder ntpd[24579]: synchronized to 192.168.1.6, stratum 3

Just to be on the safe side, I opted to leave the burst & iburst switches on the server line in the /etc/ntp.conf file. For completeness, I researched what the burst/iburst switches do. Here are those descriptions right out of the ntp.conf man page:

burst – When the server is reachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete. This option is valid with only the server command and is a recommended option with this command when the maxpoll option is 11 or greater.

iburst – When the server is unreachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete. This option is valid with only the server command and is a recommended option with this command.

After waiting for ~2 hours, I still did not see anymore of the ntp synch messages in /var/log/messages. Since the burst/iburst switches don’t seem to be causing any additional problems I’m going to leave them on going forward, and I may remove them completely at a later date. For now, I’m going to wait and make sure that the time remains stable before I do that.

]]> http://www.lamolabs.org/blog/1739/howto-stop-clock-drift-issuescentos5-openvz-host-node/feed/ 0 More Info About OpenVZ and Memory http://www.lamolabs.org/blog/1218/more-info-about-openvz-and-memory/ http://www.lamolabs.org/blog/1218/more-info-about-openvz-and-memory/#comments Sat, 06 Jun 2009 00:08:14 +0000 slmingol http://www.lamolabs.org/blog/?p=1218 Found this extremely useful post over on maxgarrick.com about how OpenVZ resource limits work. I’m re-posting a very handy diagram that was part of the blog post so that I have a local copy for my own references here:

I highly recommend that you check out the post if you want a great description of the [...]]]> Found this extremely useful post over on maxgarrick.com about how OpenVZ resource limits work. I’m re-posting a very handy diagram that was part of the blog post so that I have a local copy for my own references here:

vz

I highly recommend that you check out the post if you want a great description of the resource limits with respect to memory work with OpenVZ.

]]> http://www.lamolabs.org/blog/1218/more-info-about-openvz-and-memory/feed/ 0 Backing Up OpenVZ http://www.lamolabs.org/blog/1136/backing-up-openvz/ http://www.lamolabs.org/blog/1136/backing-up-openvz/#comments Wed, 20 May 2009 01:54:02 +0000 slmingol http://www.lamolabs.org/blog/1136/backing-up-openvz/ Now that I’ve been using OpenVZ for several months I thought it would be a good time to devote a few cycles to putting together a backup routine for the 10+ OpenVZ VEs that I’ve setup. Here is the procedure I put together to backup one of my VEs. I should mention that all my [...]]]> Now that I’ve been using OpenVZ for several months I thought it would be a good time to devote a few cycles to putting together a backup routine for the 10+ OpenVZ VEs that I’ve setup. Here is the procedure I put together to backup one of my VEs. I should mention that all my VEs make use of automounts, and through experimentation I figured out that I need to stop the automounter while I’m performing a backup of a VE. From my HN I determined that this was the minimal number of commands I could accomplish a backup of a single VE.

1
2
3
4

vzctl exec 101 /etc/init.d/autofs stop			# stop automounter
vzdump --compress --suspend 101				# backup VE(Virtual Environment) 101
vzctl exec 101 /etc/init.d/autofs start			# start automounter
mv vzdump-101.log vzdump-101.tgz /mnt/vz_backups/	# move backed up file to on-line storage area

Here is the full transcript from a backup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

% vzctl exec 101 /etc/init.d/autofs stop
Stopping automount: [  OK  ]
 
% vzdump --compress --suspend 101
INFO: Starting new backup job - vzdump --compress --suspend 101
INFO: Starting Backup of VM 101 (openvz)
INFO: status = CTID 101 exist mounted running
INFO: starting first sync /vz/private/101 to /var/tmp/vzdumptmp22651
INFO: Number of files: 35178
INFO: Number of files transferred: 25940
INFO: Total file size: 800591555 bytes
INFO: Total transferred file size: 616512883 bytes
INFO: Literal data: 616512883 bytes
INFO: Matched data: 0 bytes
INFO: File list size: 712364
INFO: File list generation time: 0.001 seconds
INFO: File list transfer time: 0.000 seconds
INFO: Total bytes sent: 618585522
INFO: Total bytes received: 679718
INFO: sent 618585522 bytes  received 679718 bytes  10069353.50 bytes/sec
INFO: total size is 800591555  speedup is 1.29
INFO: first sync finished (61 seconds)
INFO: suspend vps
INFO: Setting up checkpoint...
INFO:   suspend...
INFO:   get context...
INFO: Checkpointing completed succesfully
INFO: final sync /vz/private/101 to /var/tmp/vzdumptmp22651
INFO: Number of files: 35178
INFO: Number of files transferred: 0
INFO: Total file size: 800591555 bytes
INFO: Total transferred file size: 0 bytes
INFO: Literal data: 0 bytes
INFO: Matched data: 0 bytes
INFO: File list size: 712364
INFO: File list generation time: 0.001 seconds
INFO: File list transfer time: 0.000 seconds
INFO: Total bytes sent: 716728
INFO: Total bytes received: 4363
INFO: sent 716728 bytes  received 4363 bytes  480727.33 bytes/sec
INFO: total size is 800591555  speedup is 1110.25
INFO: final sync finished (1 seconds)
INFO: resume vps
INFO: Resuming...
INFO: vps is online again after 3 seconds
INFO: creating archive '/vz/dump/vzdump-101.dat' (/var/tmp/vzdumptmp22651/101)
INFO: Total bytes written: 641587200 (612MiB, 11MiB/s)
INFO: file size 201MB
INFO: Finished Backup of VM 101 (00:02:02)
 
% vzctl exec 101 /etc/init.d/autofs start
Starting automount: [  OK  ]
 
% mv vzdump-101.log vzdump-101.tgz /mnt/vz_backups/.

I put together this one-liner which will handle the backing up of all 11 of my VEs.

1
2

for i in `seq 101 111`;do vzctl exec $i /etc/init.d/autofs stop; vzdump --compress --suspend $i; vzctl exec $i /etc/init.d/autofs start;done
mv vzdump-*.tgz /mnt/vz_backups/.
]]> http://www.lamolabs.org/blog/1136/backing-up-openvz/feed/ 0 Interesting Videocasts http://www.lamolabs.org/blog/1053/interesting-videocasts/ http://www.lamolabs.org/blog/1053/interesting-videocasts/#comments Wed, 06 May 2009 00:06:57 +0000 slmingol http://www.lamolabs.org/blog/?p=1053 Here is a list of interesting videocasts/webcasts that i would recommend from the O’Reilly, InfoQ, & Google Tech Talks websites.

O’Reilly MySQL Replication: Audit, Test, & Verify

10 Things Every Software Architect Should Know

Getting Started with Amazon Web Services

Showing Off Your Models: Presentations in Google SketchUp

Video is TBD and should be available after May 14th, 2009

InfoQ Startups, Business, & [...]]]> Here is a list of interesting videocasts/webcasts that i would recommend from the O’Reilly, InfoQ, & Google Tech Talks websites.

O’Reilly

Video is TBD and should be available after May 14th, 2009

InfoQ

Startups, Business, & Development Processes
Rails
Virtualization & Cloud
Architectures & Performance

Google Tech Talks

Architectures

]]> http://www.lamolabs.org/blog/1053/interesting-videocasts/feed/ 0 Increasing RAM in a OpenVZ Virtual Environment http://www.lamolabs.org/blog/657/increasing-ram-in-a-openvz-virtual-environment/ http://www.lamolabs.org/blog/657/increasing-ram-in-a-openvz-virtual-environment/#comments Wed, 25 Mar 2009 04:31:07 +0000 slmingol http://www.lamolabs.org/blog/657/increasing-ram-in-a-openvz-virtual-environment/ Recently I started to get a strange error with one of my OpenVZ VE nodes. This VE is the one that maintains my MySQL database for my Wordpress blog. Here’s the error I was getting.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 # inside the OpenVZ VE   % yum update Loading "fastestmirror" plugin Loading mirror speeds from cached hostfile * atrpms: dl.atrpms.net * extras: mirror.anl.gov * [...]]]> Recently I started to get a strange error with one of my OpenVZ VE nodes. This VE is the one that maintains my MySQL database for my Wordpress blog. Here’s the error I was getting.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# inside the OpenVZ VE
 
% yum update
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
 * atrpms: dl.atrpms.net
 * extras: mirror.anl.gov
 * rpmforge: ftp-stud.fht-esslingen.de
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 105, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 289, in doCommands
    self._getTs()
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 85, in _getTs
    self._getTsInfo()
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 91, in _getTsInfo
    self._tsInfo.setDatabases(self.rpmdb, self.pkgSack)
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 537, in <lambda>
    pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 392, in _getSacks
    self.repos.populateSack(which=repos)
  File "/usr/lib/python2.4/site-packages/yum/repos.py", line 214, in populateSack
    self.doSetup()
  File "/usr/lib/python2.4/site-packages/yum/repos.py", line 66, in doSetup
    self.ayum.plugins.run('postreposetup')
  File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 169, in run
    func(conduitcls(self, self.base, conf, **kwargs))
  File "/usr/lib/yum-plugins/fastestmirror.py", line 90, in postreposetup_hook
    repomirrors[str(repo)] = FastestMirror(repo.urls).get_mirrorlist()
  File "/usr/lib/yum-plugins/fastestmirror.py", line 142, in get_mirrorlist
    self._poll_mirrors()
  File "/usr/lib/yum-plugins/fastestmirror.py", line 155, in _poll_mirrors
    pollThread.start()
  File "/usr/lib/python2.4/threading.py", line 416, in start
    _start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread

Yup, it made a lot of sense to me as well. Seemed to be something with yum’s fastermirror plugin, or so I thought, so I just disabled it and was able to get a little further like this:

1
2
3

# inside the OpenVZ VE
 
yum --disableplugin=fastermirror update

However now the update would go through the motions of downloading packages etc. but would just die when trying to install them. So after googling for a bit I found a bug submitted against yum reporting a similar problem. Turns out this is yum and/or python’s way of saying it ran out of memory. So obvious, right?

So I checked my VE’s beancounters and low and behold it was running out of memory. You can tell when you start seeing a count in the failcnt column below on the privvmpages row. BTW, this VE instance is using the default value of 256MB of RAM, aka. 65536 pages * 4096KB = 268,435,456 bytes.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# inside the OpenVZ VE
 
% cat /proc/user_beancounters 
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
      104:  kmemsize                  2406222              2873722             14372700             14790164                    0
            lockedpages                     0                    0                  256                  256                    0
            privvmpages                 45641                65547                65536                69632                   53
            shmpages                        1                  673                21504                21504                    0
            dummy                           0                    0                    0                    0                    0
            numproc                        39                   46                  240                  240                    0
            physpages                    6694                20451                    0  9223372036854775807                    0
            vmguarpages                     0                    0                33792  9223372036854775807                    0
            oomguarpages                 6694                20451                26112  9223372036854775807                    0
            numtcpsock                      7                   23                  360                  360                    0
            numflock                        9                   13                  188                  206                    0
            numpty                          1                    1                   16                   16                    0
            numsiginfo                      1                    4                  256                  256                    0
            tcpsndbuf                  122304               838656              1720320              2703360                    0
            tcprcvbuf                  114688               860544              1720320              2703360                    0
            othersockbuf                18560                84768              1126080              2097152                    0
            dgramrcvbuf                     0                13376               262144               262144                    0
            numothersock                   17                   24                  120                  120                    0
            dcachesize                      0                    0              3409920              3624960                    0
            numfile                       865                 1179                 9312                 9312                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      10                   10                  128                  128                    0

Using the command below increased the VE’s memory from the default 256MB to 410MB. As an aside, I’ve never seen it mentioned on any blog/wiki/forum whatever, but you can specify the value to the –privvmpages arguement as either # pages, Gigabytes, Megabytes, or Kilobytes. I find this easier to use these than trying to calculate out the number of pages. In fact the only mention I’ve seen of these easier ways to specify them RAM is in vzctl’s man page. Guess it pays to read the man pages?

1
2
3

# outside the OpenVZ VE, aka. on the OpenVZ Host Node
 
vzctl set 104 --privvmpages 410m:450m --save

Here is a snippet from the vzctl man page.

...

You  can  also  specify  different  suffixes  for  set  parameters (except for the parameters which names start with num).  For example, vzctl set CTID
--privvmpages 5M:6M should set privvmpages' barrier to 5 megabytes and its limit to 6 megabytes.

Available suffixes are:
g, G -- gigabytes.
m, M -- megabytes.
k, K -- kilobytes.
p, P -- pages (page is 4096 bytes on x86 architecture, other architectures may differ).

You can also specify the literal word unlimited in place of a number.  In that case the corresponding value will be set to LONG_MAX, i. e.  the maximum
possible value.

...

So now the VE instance has 104960 pages available aka. ~410MB, with a barrier limit of ~450MB, aka. 115200 pages, and yum is happy.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# inside the OpenVZ VE
 
% cat /proc/user_beancounters 
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
      104:  kmemsize                  2431123              2891301             14372700             14790164                    0
            lockedpages                     0                    0                  256                  256                    0
            privvmpages                 46320                74647               104960               115200                   54
            shmpages                        1                  673                21504                21504                    0
            dummy                           0                    0                    0                    0                    0
            numproc                        39                   49                  240                  240                    0
            physpages                    7107                20451                    0  9223372036854775807                    0
            vmguarpages                     0                    0                33792  9223372036854775807                    0
            oomguarpages                 7107                20451                26112  9223372036854775807                    0
            numtcpsock                      7                   23                  360                  360                    0
            numflock                        9                   13                  188                  206                    0
            numpty                          1                    1                   16                   16                    0
            numsiginfo                      1                    4                  256                  256                    0
            tcpsndbuf                  122304               838656              1720320              2703360                    0
            tcprcvbuf                  114688               860544              1720320              2703360                    0
            othersockbuf                20880                84768              1126080              2097152                    0
            dgramrcvbuf                     0                13376               262144               262144                    0
            numothersock                   17                   24                  120                  120                    0
            dcachesize                      0                    0              3409920              3624960                    0
            numfile                       873                 1179                 9312                 9312                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      10                   10                  128                  128                    0
]]> http://www.lamolabs.org/blog/657/increasing-ram-in-a-openvz-virtual-environment/feed/ 0 Getting VMware 1.x Server Running on Fedora 10 http://www.lamolabs.org/blog/605/getting-vmware-1x-server-running-on-fedora-10/ http://www.lamolabs.org/blog/605/getting-vmware-1x-server-running-on-fedora-10/#comments Sat, 21 Mar 2009 05:40:24 +0000 slmingol http://www.lamolabs.org/blog/605/getting-vmware-108-server-running-on-fedora-10/ As part of the aftermath of my Fedora Core 6 laptop getting dropped, I needed to do several re-installs of key apps. One of the more critical ones was VMware Server 1.08. I’m not a big fan of the 2.x version of this product so I’d rather just continue using the 1.x version.

In what [...]]]> As part of the aftermath of my Fedora Core 6 laptop getting dropped, I needed to do several re-installs of key apps. One of the more critical ones was VMware Server 1.08. I’m not a big fan of the 2.x version of this product so I’d rather just continue using the 1.x version.

In what has pretty much become the norm with VMware, every kernel upgrade, invariably breaks VMware. Since I had previously been using Fedora Core 6, a deprecated release, I hadn’t had a kernel update in a while, so I didn’t really have to deal with kernel churn. Now back on the bleeding edge with Fedora 10 I’m once again having to keep VMware Server working everytime a new kernel comes out.

So to start, I made sure I had the latest and greatest version of the 1.x VMware Server branch. I prefer to work with RPMs, so I grabbed the RPM version of the package. Upon installing it I ran into the following.

1st install attempt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

## install vmware rpm
% rpm -ivh VMware-server-1.0.8-126538.i386.rpm 
Preparing...                ########################################### [100%]
   1:VMware-server          ########################################### [100%]
 
# configure vmware
% vmware-config.pl
...
...
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config10/vmmon-only'
make -C /lib/modules/2.6.27.19-170.2.35.fc10.i686/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/kernels/2.6.27.19-170.2.35.fc10.i686'
  CC [M]  /tmp/vmware-config10/vmmon-only/linux/driver.o
In file included from /tmp/vmware-config10/vmmon-only/./include/machine.h:24,
                 from /tmp/vmware-config10/vmmon-only/linux/driver.h:15,
                 from /tmp/vmware-config10/vmmon-only/linux/driver.c:49:
/tmp/vmware-config10/vmmon-only/./include/x86.h:830:1: warning: "PTE_PFN_MASK" redefined
In file included from include/asm/paravirt.h:7,
                 from include/asm/irqflags.h:55,
                 from include/linux/irqflags.h:57,
                 from include/asm/system.h:11,
                 from include/asm/processor.h:17,
                 from include/linux/prefetch.h:14,
                 from include/linux/list.h:6,
                 from include/linux/module.h:9,
                 from /tmp/vmware-config10/vmmon-only/linux/driver.c:12:
include/asm/page.h:22:1: warning: this is the location of the previous definition
In file included from /tmp/vmware-config10/vmmon-only/linux/vmhost.h:13,
                 from /tmp/vmware-config10/vmmon-only/linux/driver.c:71:
/tmp/vmware-config10/vmmon-only/./include/compat_semaphore.h:5:27: error: asm/semaphore.h: No such file or directory
/tmp/vmware-config10/vmmon-only/linux/driver.c:146: error: unknown field ‘nopage’ specified in initializer
/tmp/vmware-config10/vmmon-only/linux/driver.c:147: warning: initialization from incompatible pointer type
/tmp/vmware-config10/vmmon-only/linux/driver.c:150: error: unknown field ‘nopage’ specified in initializer
/tmp/vmware-config10/vmmon-only/linux/driver.c:151: warning: initialization from incompatible pointer type
/tmp/vmware-config10/vmmon-only/linux/driver.c: In function ‘LinuxDriver_Ioctl’:
/tmp/vmware-config10/vmmon-only/linux/driver.c:1670: error: too many arguments to function ‘smp_call_function’
make[2]: *** [/tmp/vmware-config10/vmmon-only/linux/driver.o] Error 1
make[1]: *** [_module_/tmp/vmware-config10/vmmon-only] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.27.19-170.2.35.fc10.i686'
make: *** [vmmon.ko] Error 2
make: Leaving directory `/tmp/vmware-config10/vmmon-only'
Unable to build the vmmon module.
 
For more information on how to troubleshoot module-related problems, please 
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".
 
Execution aborted.

Googling a bit produced this blog post and this wiki post. According to the blog post you need to apply the following patch set to VMware 1.08 to get it to work with the newer 2.6.27 kernels. Here’s a link to the original tarball of the patchset, as well as a link to a local copy I have cached on my site.

Steps to download and unpack the patches
1
2
3
4
5
6
7
8
9
10
11
12
13

## download patches
% wget http://www.insecure.ws/warehouse/vmware-update-2.6.27-5.5.7-2.tar.gz
 
## unpack patches
% tar zxvf vmware-update-2.6.27-5.5.7-2.tar.gz 
vmware-update-2.6.27-5.5.7-2/
vmware-update-2.6.27-5.5.7-2/services.sh
vmware-update-2.6.27-5.5.7-2/runme.pl
vmware-update-2.6.27-5.5.7-2/update.c
vmware-update-2.6.27-5.5.7-2/vmblock.tar
vmware-update-2.6.27-5.5.7-2/update
vmware-update-2.6.27-5.5.7-2/vmmon.tar
vmware-update-2.6.27-5.5.7-2/vmnet.tar
Patch vmware

Now we need to apply the patches to VMware and compile.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233

## apply patches & run vmware-config.pl
% cd vmware-update-2.6.27-5.5.7-2
% perl runme.pl
Updating /usr/bin/vmware-config.pl ... now patched
The file /usr/lib/vmware/modules/source/vmmon.tar that this script was about to 
install already exists. Overwrite? [yes] 
 
The file /usr/lib/vmware/modules/source/vmnet.tar that this script was about to 
install already exists. Overwrite? [yes] 
 
Updating /usr/bin/vmware ... No patch needed/available
Updating /usr/bin/vmnet-bridge ... No patch needed/available
Updating /usr/lib/vmware/bin/vmware-vmx ... No patch needed/available
Updating /usr/lib/vmware/bin-debug/vmware-vmx ... No patch needed/available
VMware modules in "/usr/lib/vmware/modules/source" has been updated.
 
Before running VMware for the first time after update, you need to configure it 
for your running kernel by invoking the following command: 
"/usr/bin/vmware-config.pl". Do you want this script to invoke the command for 
you now? [yes] 
 
Making sure services for VMware Server are stopped.
 
Stopping VMware services:
   Virtual machine monitor                                 [  OK  ]
 
You must read and accept the End User License Agreement to continue.
Press enter to display it. 
...
...
### Skipping the EULA!
...
...
Configuring fallback GTK+ 2.4 libraries.
 
In which directory do you want to install the mime type icons? 
[/usr/share/icons] 
 
What directory contains your desktop menu entry files? These files have a 
.desktop file extension. [/usr/share/applications] 
 
In which directory do you want to install the application's icon? 
[/usr/share/pixmaps] 
 
/usr/share/applications/vmware-server.desktop: warning: value "vmware-server.png" for key "Icon" in group "Desktop Entry" is an icon name with an extension, but there should be no extension as described in the Icon Theme Specification if the value is not an absolute path
/usr/share/applications/vmware-console-uri-handler.desktop: warning: value "vmware-server.png" for key "Icon" in group "Desktop Entry" is an icon name with an extension, but there should be no extension as described in the Icon Theme Specification if the value is not an absolute path
Trying to find a suitable vmmon module for your running kernel.
 
None of the pre-built vmmon modules for VMware Server is suitable for your 
running kernel.  Do you want this program to try to build the vmmon module for 
your system (you need to have a C compiler installed on your system)? [yes] 
 
Using compiler "/usr/bin/gcc". Use environment variable CC to override.
 
What is the location of the directory of C header files that match your running
kernel? 
[/lib/modules/2.6.27.19-170.2.35.fc10.i686/build/include] 
 
Extracting the sources of the vmmon module.
 
Building the vmmon module.
 
Building for VMware Server 1.0.0.
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config10/vmmon-only'
make -C /lib/modules/2.6.27.19-170.2.35.fc10.i686/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/kernels/2.6.27.19-170.2.35.fc10.i686'
  CC [M]  /tmp/vmware-config10/vmmon-only/linux/driver.o
  CC [M]  /tmp/vmware-config10/vmmon-only/linux/driverLog.o
  CC [M]  /tmp/vmware-config10/vmmon-only/linux/hostif.o
/tmp/vmware-config10/vmmon-only/linux/hostif.c: In function ‘HostIF_SetFastClockRate’:
/tmp/vmware-config10/vmmon-only/linux/hostif.c:3441: warning: passing argument 2 of ‘send_sig’ discards qualifiers from pointer target type
  CC [M]  /tmp/vmware-config10/vmmon-only/common/comport.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/cpuid.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/hash.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/memtrack.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/phystrack.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/task.o
cc1plus: warning: command line option "-Werror-implicit-function-declaration" is valid for C/ObjC but not for C++
cc1plus: warning: command line option "-Wdeclaration-after-statement" is valid for C/ObjC but not for C++
cc1plus: warning: command line option "-Wno-pointer-sign" is valid for C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
In file included from /tmp/vmware-config10/vmmon-only/common/task.c:1195:
/tmp/vmware-config10/vmmon-only/common/task_compat.h: In function ‘void Task_Switch_V45(VMDriver*, Vcpuid)’:
/tmp/vmware-config10/vmmon-only/common/task_compat.h:2667: warning: ‘sysenterState.SysenterStateV45::validEIP’ may be used uninitialized in this
function
/tmp/vmware-config10/vmmon-only/common/task_compat.h:2667: warning: ‘sysenterState.SysenterStateV45::cs’ may be used uninitialized in this function
/tmp/vmware-config10/vmmon-only/common/task_compat.h:2667: warning: ‘sysenterState.SysenterStateV45::rsp’ may be used uninitialized in this function
/tmp/vmware-config10/vmmon-only/common/task_compat.h:2667: warning: ‘sysenterState.SysenterStateV45::rip’ may be used uninitialized in this function
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmciContext.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmciDatagram.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmciDriver.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmciDs.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmciGroup.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmciHashtable.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmciProcess.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmciResource.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmciSharedMem.o
  CC [M]  /tmp/vmware-config10/vmmon-only/common/vmx86.o
  CC [M]  /tmp/vmware-config10/vmmon-only/vmcore/compat.o
  CC [M]  /tmp/vmware-config10/vmmon-only/vmcore/moduleloop.o
  LD [M]  /tmp/vmware-config10/vmmon-only/vmmon.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: modpost: module vmmon.ko uses symbol 'init_mm' marked UNUSED
  CC      /tmp/vmware-config10/vmmon-only/vmmon.mod.o
  LD [M]  /tmp/vmware-config10/vmmon-only/vmmon.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.27.19-170.2.35.fc10.i686'
cp -f vmmon.ko ./../vmmon.o
make: Leaving directory `/tmp/vmware-config10/vmmon-only'
The module loads perfectly in the running kernel.
 
Do you want networking for your virtual machines? (yes/no/help) [yes] 
Configuring a bridged network for vmnet0.
 
Your computer has multiple ethernet network interfaces available: eth0, pan0, 
wlan0. Which one do you want to bridge to vmnet0? [eth0] 
 
The following bridged networks have been defined:
 
. vmnet0 is bridged to eth0
 
Do you wish to configure another bridged network? (yes/no) [no] 
 
Do you want to be able to use NAT networking in your virtual machines? (yes/no)
[yes] 
 
Configuring a NAT network for vmnet8.
 
Do you want this program to probe for an unused private subnet? (yes/no/help) 
[yes] 
 
Probing for an unused private subnet (this can take some time)...
 
The subnet 172.16.244.0/255.255.255.0 appears to be unused.
 
The following NAT networks have been defined:
 
. vmnet8 is a NAT network on private subnet 172.16.244.0.
 
Do you wish to configure another NAT network? (yes/no) [no] 
 
Do you want to be able to use host-only networking in your virtual machines? 
[yes] 
 
Configuring a host-only network for vmnet1.
 
Do you want this program to probe for an unused private subnet? (yes/no/help) 
[yes] 
 
Probing for an unused private subnet (this can take some time)...
 
The subnet 172.16.124.0/255.255.255.0 appears to be unused.
 
The following host-only networks have been defined:
 
. vmnet1 is a host-only network on private subnet 172.16.124.0.
 
Do you wish to configure another host-only network? (yes/no) [no] 
 
Extracting the sources of the vmnet module.
 
Building the vmnet module.
 
Building for VMware Server 1.0.0.
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config10/vmnet-only'
make -C /lib/modules/2.6.27.19-170.2.35.fc10.i686/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/kernels/2.6.27.19-170.2.35.fc10.i686'
  CC [M]  /tmp/vmware-config10/vmnet-only/driver.o
  CC [M]  /tmp/vmware-config10/vmnet-only/hub.o
  CC [M]  /tmp/vmware-config10/vmnet-only/userif.o
  CC [M]  /tmp/vmware-config10/vmnet-only/netif.o
  CC [M]  /tmp/vmware-config10/vmnet-only/bridge.o
  CC [M]  /tmp/vmware-config10/vmnet-only/filter.o
  CC [M]  /tmp/vmware-config10/vmnet-only/procfs.o
  CC [M]  /tmp/vmware-config10/vmnet-only/smac_compat.o
  CC [M]  /tmp/vmware-config10/vmnet-only/smac_linux.x386.o
  LD [M]  /tmp/vmware-config10/vmnet-only/vmnet.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: modpost: missing MODULE_LICENSE() in /tmp/vmware-config10/vmnet-only/vmnet.o
see include/linux/module.h for more information
  CC      /tmp/vmware-config10/vmnet-only/vmnet.mod.o
  LD [M]  /tmp/vmware-config10/vmnet-only/vmnet.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.27.19-170.2.35.fc10.i686'
cp -f vmnet.ko ./../vmnet.o
make: Leaving directory `/tmp/vmware-config10/vmnet-only'
The module loads perfectly in the running kernel.
 
Please specify a port for remote console connections to use [904] 
 
WARNING: VMware Server has been configured to run on a port different from the 
default port. Remember to use this port when connecting to this server.
Stopping xinetd:                                           [FAILED]
Starting xinetd:                                           [  OK  ]
Configuring the VMware VmPerl Scripting API.
 
Building the VMware VmPerl Scripting API.
 
Using compiler "/usr/bin/gcc". Use environment variable CC to override.
 
Installing the VMware VmPerl Scripting API.
 
The installation of the VMware VmPerl Scripting API succeeded.
 
Generating SSL Server Certificate
 
In which directory do you want to keep your virtual machine files? 
[/var/lib/vmware/Virtual Machines] 
 
The path "/var/lib/vmware/Virtual Machines" does not exist currently. This 
program is going to create it, including needed parent directories. Is this 
what you want? [yes] 
 
Please enter your 20-character serial number.
 
Type XXXXX-XXXXX-XXXXX-XXXXX or 'Enter' to cancel:  
 
You cannot power on any virtual machines until you enter a valid serial number.
To enter the serial number, run this configuration program again, or choose 
'Help > Enter Serial Number' in the virtual machine console.
 
Starting VMware services:
   Virtual machine monitor                                 [  OK  ]
   Virtual ethernet                                        [  OK  ]
   Bridged networking on /dev/vmnet0                       [  OK  ]
   Host-only networking on /dev/vmnet1 (background)        [  OK  ]
   Host-only networking on /dev/vmnet8 (background)        [  OK  ]
   NAT service on /dev/vmnet8                              [  OK  ]
 
The configuration of VMware Server 1.0.8 build-126538 for Linux for this 
running kernel completed successfully.

And with that VMware server should be installed on Fedora 10!

]]> http://www.lamolabs.org/blog/605/getting-vmware-1x-server-running-on-fedora-10/feed/ 0 Getting CUPS and OpenVZ to Play Nice on CentOS 5 http://www.lamolabs.org/blog/473/getting-cups-openvz-play-nice-centos5/ http://www.lamolabs.org/blog/473/getting-cups-openvz-play-nice-centos5/#comments Sun, 15 Mar 2009 04:08:09 +0000 slmingol http://www.lamolabs.org/blog/?p=473 Recently I was trying to get one of my OpenVZ instances to host a CUPS service for my entire domain. In order to do this the VE instance needs to know about the device files under /dev that relate to the printers I wanted to share. The device files I needed to share were for [...]]]> Recently I was trying to get one of my OpenVZ instances to host a CUPS service for my entire domain. In order to do this the VE instance needs to know about the device files under /dev that relate to the printers I wanted to share. The device files I needed to share were for 2 USB printers. So I put the script below together to figure out what the current files are for the 2 USB printers on the HN and then create the necessary files within the VE and update the VE instance through the vzctl –details switch to reflect the devices for the printers.

NOTE: Some of the info on the OpenVZ wiki here offered some helpful guidance.

lsusb output
1
2

Bus 004 Device 008: ID 04f9:000d Brother Industries, Ltd HL-1440 Laser Printer
Bus 004 Device 004: ID 04a9:1069 Canon, Inc. S820

I was interested in adding these 2 devices so I used their ID …. strings to uniquely identify them from reboot to reboot. They’re identified in the $filterDevices variable in the add_usb_devices_to_ve.sh script below.

Adding the USB device files to the VE

Here is the script I wrote to accomplish this, add_usb_devices_to_ve.sh.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

#!/bin/sh
 
# Sample output from lsusb command
#
#Bus 004 Device 008: ID 04f9:000d Brother Industries, Ltd HL-1440 Laser Printer
#Bus 004 Device 004: ID 04a9:1069 Canon, Inc. S820
#Bus 004 Device 001: ID 0000:0000  
 
# Sample output from /dev/bus/usb/<Bus 004> directory
#
#crw-r--r-- 1 root root 189, 384 Mar 14 01:08 001
#crw-r--r-- 1 root root 189, 387 Mar 14 02:53 004
#crw-r--r-- 1 root root 189, 391 Mar 14 13:01 008
#
 
### /dev directories
usbDevDir="/dev/usb"
usbBusDir="/dev/bus/usb"
### device ID's to add to our VE
filterDevices="04f9:000d|04a9:1069"
lsusbOutput="`lsusb | egrep \"$filterDevices\"`"
### VE
if [ $# -ne 1 ]; then
  echo -e "\n\nUSAGE: $0 <VE #>\n\n"
  exit 1;
fi
ve="$1"
 
### change field separator to end-of-line
ORIGIFS=$IFS
IFS=`echo -en "\n\b"`
 
### mknod's under /dev/usb
#
idx=0
echo -e "\n\n### Setup usb devices under $usbDevDir\n"
for line in $lsusbOutput; do
  #sample $line: Bus 004 Device 004: ID 04a9:1069 Canon, Inc. S820
  echo -e "\nFound device ===> $line\n"
 
  usbBus="`echo $line | awk '{print $2}'`"                  # 004
  usbDev="`echo $line | awk '{print $4}' | sed 's/:$//'`"   # 004
  lpDev="${usbDevDir}/lp${idx}"                             # /dev/usb/lp<#>
 
  echo " * Populating VE $ve /dev directory with device files"
  vzctl exec $ve "mkdir -p $usbDevDir"
  vzctl exec $ve "[ -f $lpDev ] || mknod $lpDev c 180 $idx"
  vzctl exec $ve "chown root:lp $lpDev"
  vzctl exec $ve "chmod 660 $lpDev"
  vzctl exec $ve "[ -f /dev/usblp${idx} ] || ln -s $lpDev /dev/usblp${idx}"
  echo " * Configuring VE $ve using vzctl's --devices switch"
  vzctl set $ve --devices c:180:${idx}:rw
  let idx=idx+1
done;
 
### mknod's under /dev/bus/usb/<Bus #>
#
usbBusNumDir="${usbBusDir}/${usbBus}"             # /dev/bus/usb/004
lsOutput="`ls -l $usbBusNumDir | grep -v total`"  # contents of /dev/bus/usb/004
 
echo -e "\n\n### Setup usb devices under $usbBusNumDir\n"
for line in $lsOutput; do
  #sample $line: crw-r--r-- 1 root root 189, 384 Mar 14 01:08 001
  echo -e "\nFound device ==> $line\n"
 
  majorNum="`echo $line | awk '{print $5}' | sed 's/,//'`"  # 189
  minorNum="`echo $line | awk '{print $6}'`"                # 384
  usbDev="`echo $line | awk '{print $NF}'`"                 # 001
  usbNumDir="${usbBusNumDir}/${usbDev}"                     # /dev/bus/usb/004/001
 
  echo " * Populating VE $ve /dev directory with device files"
  vzctl exec $ve "mkdir -p $usbBusNumDir"
  vzctl exec $ve "[ -f $usbNumDir ] || mknod $usbNumDir c $majorNum $minorNum"
  vzctl exec $ve "chown root:root $usbNumDir"
  vzctl exec $ve "chmod 664 $usbNumDir"
  echo " * Configuring VE $ve using vzctl's --devices switch"
  vzctl set $ve --devices c:${majorNum}:${minorNum}:rw
done;
 
# change field separator back to it's default (i.e. single space)
IFS=$ORIGIFS
Changes to /etc/rc.local on the HN
1
2
3

# add device files for usb printers to print.bubba.net instance (#103) & restart cups 
/etc/vz/add_usb_devices_to_ve.sh 103 
vzctl exec 103 "/etc/init.d/cups restart"

Now every time the HN is rebooted the VE instance will get started up with CUPS sharing the printers.

]]> http://www.lamolabs.org/blog/473/getting-cups-openvz-play-nice-centos5/feed/ 0