1345075209 Q * fisted Quit: leaving
1345075462 J * fisted ~fisted@xdsl-78-35-87-29.netcologne.de
1345077916 J * FireEgl ~FireEgl@173-25-83-57.client.mchsi.com
1345078829 Q * nlm Ping timeout: 480 seconds
1345079494 J * nlm ~nlm@host34.190-228-238.telecom.net.ar
1345085431 Q * FireEgl Ping timeout: 480 seconds
1345086692 Q * nkukard_ Ping timeout: 480 seconds
1345086879 J * nkukard ~nkukard@41-133-164-200.dsl.mweb.co.za
1345087169 Q * nlm Ping timeout: 480 seconds
1345087374 Q * nkukard Ping timeout: 480 seconds
1345087529 J * nkukard ~nkukard@41-133-164-200.dsl.mweb.co.za
1345087744 M * Bertl off to bed now ... have a good one everyone!
1345087749 N * Bertl Bertl_zZ
1345089423 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1345089611 J * FireEgl ~FireEgl@173-25-83-57.client.mchsi.com
1345094464 Q * clopez Ping timeout: 480 seconds
1345095268 J * kir ~kir@swsoft-msk-nat.sw.ru
1345095306 P * kir 
1345097035 J * ghislain ~AQUEOS@adsl2.aqueos.com
1345097537 N * jrayhawk_ jrayhawk
1345099471 Q * nkukard Quit: Leaving
1345103160 Q * imcsk8 Read error: Operation timed out
1345103171 Q * ichavero__ Read error: Operation timed out
1345103326 J * fisted_ ~fisted@xdsl-87-78-187-99.netcologne.de
1345103349 J * imcsk8 ~ichavero@148.229.1.11
1345103358 J * ichavero__ ~ichavero@148.229.1.11
1345103508 Q * fisted Ping timeout: 480 seconds
1345106067 N * ensc Guest3135
1345106076 J * ensc ~irc-ensc@p54ADE18D.dip.t-dialin.net
1345106486 Q * Guest3135 Ping timeout: 480 seconds
1345107771 N * Bertl_zZ Bertl
1345107776 M * Bertl morning folks!
1345108401 M * fback hello Bertl
1345111240 J * nkukard ~nkukard@41-133-164-200.dsl.mweb.co.za
1345115573 N * ncopa_ ncopa
1345116970 Q * nkukard Read error: Operation timed out
1345117036 J * nkukard ~nkukard@41-133-164-200.dsl.mweb.co.za
1345121778 Q * Aiken Remote host closed the connection
1345122170 Q * nkukard Ping timeout: 480 seconds
1345122223 J * nkukard ~nkukard@dsl-246-172-145.telkomadsl.co.za
1345123792 Q * nkukard Read error: Operation timed out
1345123927 J * nkukard ~nkukard@197.87.42.133
1345124726 J * BenG ~bengreen@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com
1345125043 J * Goulp ~Muxy@smtp.opsio.fr
1345125068 P * Goulp Quitte
1345126484 J * clopez ~clopez@65.27.165.83.dynamic.mundo-r.com
1345128233 J * vampirnata ~vampirnat@178.113.243.137.wireless.dyn.drei.com
1345128240 M * vampirnata afternoon
1345128274 M * Bertl a good one to you
1345128349 M * vampirnata I'm hoping someone can lend a hand. I'm trying to move a guest vserver to a new host. I stopped the guest on the old host and followed the wiki how to build a new guest on the new host using rsync. But when I start the guest on the new host, everything looks fine untill I access the web server that is running no the guest. There are then many sql errors.
1345128375 M * vampirnata Any ideas how to make sure the guest behaves exactly the same on the new host?
1345128440 M * Bertl did you copy the config as well as the actual guest data?
1345128469 M * Bertl (i.e. the files in /etc/vservers/<name>)
1345128510 M * vampirnata I didn't but they are the same, except for the location of the vdir which I then update the symbolic link
1345128555 M * Bertl okay, double check that the network config is the same, also check the kernel defaults for e.g. single IP special casing
1345128581 M * vampirnata network is the same.
1345128674 M * vampirnata The website runs, but when I log into the admin portal of the website and access some sections, it will spit out some sql errors.
1345128723 M * Bertl well, if the guest is configured identical and the host provides the very same IPs etc as the other host, then there is no difference
1345128729 M * vampirnata since it's a production site, I can't really go messing around while it's supposed to be online
1345128749 M * Bertl but I suspect that you changed a few things which somehow affect the mysql inside the guest
1345128768 M * Bertl first, it would be interesting to know what errors you are seeing
1345128786 M * Bertl (upload them somewhere, e.g. pastebin)
1345128808 M * vampirnata One thing that is different is that on the old server I have the home folder being mounted when the guest starts, and the new server I rsynced the home folder into the guest itself
1345128842 M * vampirnata My predecessor had it set up like that, i don't know why...
1345128874 M * vampirnata and the home folder has the website data, but not the sql database
1345128904 M * vampirnata I used rync -av to get the home folder across so it should get all the correct permissions and such.
1345129064 M * vampirnata okay i'm going to build the guest again with a different hostname and ip and see if i can get a test working so I can dump the errors for you
1345129135 M * vampirnata i'm using "vserver guestname build -m rsync --context 127 --hostname guestname --interface eth0:192.168.100.127 -- --source root@192.168.100.10:/vroot/guestname"
1345129139 M * vampirnata sound about right?
1345129457 M * Bertl rsync -av is most likely insufficient
1345129567 M * Bertl also note that the IP change might affect the guest's programs
1345129587 M * Bertl i.e. mysql tends to have strange security checks based on IP 
1345129619 M * Bertl (so I wouldn't be surprised if the mysql installation inside the guest only allows the 'original' guest IP)
1345129639 M * vampirnata Yah that's what I thought.
1345129752 M * vampirnata Well I'm stumped, don't know how to move this guest then...
1345129835 M * vampirnata I've tried shutting down the guest, building it with exactly the same name and ip, same settings in /etc/vservers/guestname and still it doesn't work
1345129858 M * Bertl and getting back to the original question: what is the error?
1345129859 M * vampirnata I imagine that the host system/kernel version doesn't really matter does it?
1345130062 M * vampirnata ok i found a screenshot
1345130073 M * vampirnata i will upload it to tinypic, one sec
1345130110 M * Bertl depends on the error, as I already said, there might be differences in the kernel configuration which affect how the guests are handled
1345130120 M * vampirnata http://i47.tinypic.com/208ilft.png
1345130202 M * Bertl that doesn't look config related to me
1345130231 M * Bertl but it looks like mysql is using /tmp for key files
1345130240 M * Bertl (which in general is a bad idea)
1345130270 M * Bertl this, OTOH, can very well be a difference if you do _not_ have the same config for both guests
1345130292 M * Bertl specifically if your 'new' guest uses the default, it will get a 16MB tmpfs as /tmp
1345130298 M * vampirnata Aye, the company that wrote the webpage are a bunch of idiots. I tried asking them for help regarding this and they say it's my problem because it works as it is now and when I move it and it doesn't work then I must have broken something
1345130327 M * Bertl while your old guest might have that one removed and/or a larger /tmp specified in /etc/vservers/<name>/fstab or the guest .defaults
1345130343 M * vampirnata ok I will check now.
1345130413 M * vampirnata ahh
1345130418 M * vampirnata god ... :/
1345130445 M * vampirnata none /tmp tmpfs size=16m,mode=1777 0 0 is commented out in the old guest
1345130458 M * Bertl there you go
1345130484 M * vampirnata sigh, well thank you for your sanity and time :)
1345130492 M * Bertl you're welcome!
1345130512 M * vampirnata I will try and rebuild and resync again tomorrow doing downtime
1345130539 M * vampirnata when rsyncing the home folder do you suggest using more than rsync -av?
1345130553 M * Bertl rsync -axHPSD --numeric-ids
1345130567 M * vampirnata  rsync -axHPSD --numeric-ids
1345130575 M * vampirnata okay :)
1345130581 M * vampirnata thank you very much
1345130600 M * Bertl np, have fun! feel free to hang around
1345130620 M * vampirnata Will do. 
1345130657 M * vampirnata Is it true that Vserver development is stopping?
1345130669 M * vampirnata or at least support for it is shrinking?
1345130698 M * vampirnata I read somewhere that debian 6.05 is the last one to get a build included, after that it will need to be built seperatly
1345130783 M * Bertl no, support is not shrinking and development has not stopped
1345130816 M * Bertl but after more than 10 years of development, it's fairly feature complete and in a maintainance state
1345130850 M * Bertl also, recently mainline discovered that isolation is something worth having, so upstream is reinventing Linux-VServer in LXC
1345130891 M * vampirnata Ahh
1345130894 M * Bertl and whenever mainline got something working in a useful way, Linux-VServer switches to that subsystem as soon as possible
1345130905 M * vampirnata Well that's good to hear
1345130915 M * vampirnata I think that vserver is a fantastic piece of software
1345130962 M * Bertl debian dropping Linux-VServer support is IMHO a gain for the debian user base, because the quality of the debian packages was really bad over the years
1345130996 M * Bertl i.e. we had a lot of extra work and many debian folks complaining about non-working stuff (which was a pure debian problem)
1345131047 J * yang_ yang@jazz.linuxshell.org
1345131054 M * vampirnata Ahh right. What would you recommend using as a host system for Vserver then?
1345131108 M * Bertl you can still use debian, no problem there, just grab the inofficial packages or build the tools/kernel from scratch
1345131111 N * vampirnata PeteG
1345131147 M * PeteG need to stop using that stupid nick ;P
1345131186 Q * yang Ping timeout: 480 seconds
1345131202 M * PeteG I will try and have a look at the unofficial packages. I only started this position 2 weeks ago. Never heard of Vserver before then
1345131253 M * Bertl yeah, we do not waste resources on advertising
1345131326 M * PeteG :) 
1345131351 M * Bertl but Linux-VServer can be used for many things, not just hosting
1345131371 M * PeteG For example?
1345131396 M * Bertl for example testing and development
1345131420 M * Jb_boin PeteG, yep, repo.psand.net + debian is the best so far for vserver imo
1345131425 M * Bertl as you can quickly create many guests from a template, you can use them to test stuff
1345131459 M * Bertl also Linux-VServer works on all platforms Linux runs on, so you can put it on your smart phone, router, etc
1345131484 M * PeteG That's rather practical
1345131529 M * Jb_boin using lxc on embeded devices for advanced chrooting might be more logical but still its a possibility :)
1345131550 M * Bertl and it scales to a huge number of guests (several 10000) but even if you run just a single guest, you can benefit from the isolation and increased security
1345131566 M * PeteG I'm starting to see the benefits
1345131600 M * PeteG We've actually got 4 Vserver Hosts running as Guests in a VMware Vsphere host :p
1345131626 M * Jb_boin well, wont even bother to tell you what i think about that :)
1345131636 M * PeteG :) I know I know
1345131651 M * Jb_boin but at least, you can easily move vservers guest with a minimal downtime
1345131657 M * PeteG Can't help it though, they have some Windows Servers here as well.
1345131665 M * Jb_boin still better than having directly vmware guests :)
1345131678 M * PeteG Oh yes
1345131699 M * Jb_boin fortunately we only got vservers, vz and lxc here :)
1345131714 M * PeteG When I get some time I will write some nice python web interface/statistic pages for vserver
1345131772 M * PeteG Jb_boin: what is this repo.psand.net?
1345131824 M * Bertl it's the inofficial package repository
1345131832 M * PeteG for VServer?
1345131835 N * yang_ yang
1345131884 M * PeteG or VServer + others...
1345132019 M * Bertl inofficial is misleading and incorrect here, BenG is doing a good job in packaging up Linux-VServer stuff for debian there
1345132042 M * Bertl so from the Linux-VServer PoV it is as official as it can get
1345132054 M * PeteG Gotcha
1345132058 M * Bertl but from the debian PoV it is the 'inofficial' source for Linux-VServer packages
1345132063 M * BenG cheers Bertl 
1345132076 M * BenG unofficial is the word
1345132092 M * Bertl thanks for all the work, btw!
1345132098 M * BenG no problem
1345132117 M * PeteG So how disruptive would it be to move to the unofficial sources on a vserver running the official vserver sources
1345132151 M * PeteG I have a vserver running some very important guests that need to be up all the time pretty much.
1345132151 M * Bertl depending on the kernel you need to fix a few things (debian kernels were rather broken at some poing)
1345132155 M * Bertl *point
1345132186 M * Bertl but besides that, there should be no problems ... note that it is good practice to test any upgrade on a test system first
1345132203 M * Bertl (especially with vmware based host systems that should be rather simple)
1345132884 M * Jb_boin PeteG, as your hosts are already vmware guests...
1345132902 M * Jb_boin i would definitely mount a new machine, without vmware and more guest one by one on it
1345132917 M * Jb_boin there will be less downtime for the guest than having to reboot the vserver host system
1345132929 M * Jb_boin (depending on how much data there is on them)
1345132971 J * bonbons ~bonbons@2001:960:7ab:0:84e2:5dc8:ed68:ecef
1345133037 M * Jb_boin you just have to copy /etc/vservers/guestname to the new host, rsync -av --numeric-ids --del /vservers/guestname newserver:/vservers/ then stop the guest on the old server, do a new rsync then start the vserver on the new server
1345133220 M * Jb_boin BenG, how much bandwidth does the repository use, i might make a mirror?
1345133286 M * BenG I have no idea :)
1345133298 M * BenG a mirror would be good though
1345133389 M * BenG did you get my private message just then?
1345133912 J * nlm ~nlm@host34.190-228-238.telecom.net.ar
1345134175 M * Jb_boin yep
1345134186 M * Jb_boin thinking about which server would hold it :)
1345134379 Q * clopez Ping timeout: 480 seconds
1345136207 M * nlm hi there, I have a question: top inside one instance is showing a process consuming 8% CPU and the same process using vtop on the host says 70%, am I hitting some bug or wut?
1345136247 M * nlm kernel 3.0.9 + vs2.3.2.1
1345136904 Q * ghislain Quit: Leaving.
1345137996 Q * BenG Remote host closed the connection
1345138233 M * Jb_boin does ps/vps says the same?
1345138328 M * Bertl nlm: sounds interesting, I would expect it the other way round
1345138351 M * nlm Jb_boin: let me check!
1345138456 M * nlm Jb_boin: yes, they agree on the high number
1345138463 M * nlm inside the instance is 8/9%
1345138617 M * Bertl what kind of process is it?
1345138634 M * nlm it's a vncserver
1345138654 M * Bertl an it uses 70% cpu as shown by vtop?
1345138673 M * nlm on a regular host it uses max 15%
1345138685 M * nlm so I kind of believe on the instance top
1345138733 M * nlm not sure if accurate, but mpstat -P ALL shows also low CPU usage on all cores
1345138738 M * Bertl okay, well, 3.0.9 is quite old, you should try with a recent kernel/patch and see if the issue persists
1345138755 M * nlm not sure if I can believe on mpstat that's what I meant
1345138763 M * nlm okay, I'll a newer one
1345138770 M * nlm not that simple but I'll try
1345138773 M * nlm :)
1345138850 M * Bertl folks always tell me that newer kernels are a problem on their hardware/systems, but my experience tells me that only older kernels cause problems on newer hardware
1345138887 M * Jb_boin well, newer kernel are usually a problem in term of stability not compatibility :)
1345138928 M * Bertl that is an interesting philosophical topic
1345138954 M * Bertl for example, would you say that an 'older' kernel is more stable than a 'newer' one?
1345138983 M * Bertl that would assume that mainline destabilizes the kernel from version to version
1345139007 M * Bertl OTOH, the 'old' kernel was a 'new' kernel a few months (years?) ago
1345139012 M * Jb_boin it depends on what but you surely are less prone to hit an undocumented bug on a 2.6.32
1345139021 M * Jb_boin than you would on a 3.2
1345139060 M * daniel_hozac_ i doubt it.
1345139061 M * Bertl okay, so documented bugs are preferable to undocumented
1345139069 M * Jb_boin yes but when you put a kernel that is just days or weeks old, you are never sure that a nasty bug hasnt been found yet
1345139105 M * daniel_hozac_ if it's a development kernel, sure.
1345139112 M * Jb_boin and as 95% os the servers doesnt run on latest kernels you dont have as much chances to have another person who might have hit the bug
1345139131 M * Jb_boin Bertl, at least you know what could happen and how to avoid it :)
1345139168 M * Bertl assuming that is true, isn't it bad in that sense that many folks already know about the bugs your 'old' kernel has?
1345139188 M * Jb_boin well, its rare that bugs stays unsolved :)
1345139200 M * Bertl so you are running 2.6.32.59 then?
1345139201 M * Jb_boin or they are not critical
1345139221 M * daniel_hozac_ or they are just too much effort to fix on that old code base.
1345139230 M * daniel_hozac_ that no one cares about enough
1345139244 M * Bertl (which is quite often the case in mainline kernels btw)
1345139259 M * Jb_boin Bertl, i mainly use distributions packages kernels
1345139269 M * Jb_boin but when i can i put backported kernels
1345139289 M * Jb_boin and i run 3.2 line from beng for the vserver hosts
1345139303 M * Bertl this leads to the distro vs. mainline/selfbuilt topic
1345139306 M * Jb_boin well, on server that i had to reboot or that i installed lately at least :)
1345139328 M * Jb_boin as most of the servers are not rebooted for years
1345139341 M * Bertl which is quite interesting as well, for example, as distros tend to include many many drivers which are not required for your hardware
1345139368 M * Bertl which in turn, includes quite dubious and fragile code in your kernel
1345139369 M * Jb_boin its better to have a little bit older kernel but a bit more "tested" if you dont want to risk to have to update kernel
1345139395 M * Bertl for example, have you ever tried loading all the modules your distro kernel provides?
1345139409 M * Bertl I wouldn't be surprised if that renders your system unuseable
1345139416 M * Jb_boin well, it looks like you are talking about the openvz kernel situation (yes its some kind of troll)
1345139449 M * Bertl nah, I'm not talking about the OVZ kernels, for them we know that they are broken :)
1345139522 M * Jb_boin well, i hadnt hit critical bugs in debian/ubuntu kernel for a long time but i had many issues with 3.0.x beng last year
1345139559 M * Jb_boin there also been the /proc/mem privilege escalation bug for the > 2.6.38 kernels that required to upgrade all the "not too old kernels"
1345139588 M * Bertl fair enough, but if you look at the debian related Linux-VServer wiki page, you will find that the kernels were quite broken, and nobody cared
1345139627 M * Jb_boin Bertl, i know but its an example and we dont have only vserver kernels :)
1345139674 M * Jb_boin and yes, the squeeze kernel is horrible for vserver with the cached memory incorrectly indicated on guests
1345139681 M * Jb_boin and the lack of cgroup support
1345140234 Q * ensc|w Remote host closed the connection
1345140243 J * ensc|w ~ensc@www.sigma-chemnitz.de
1345147732 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1345148154 M * Bertl off to bed now ... have a good one everyone!
1345148162 N * Bertl Bertl_zZ
1345148313 Q * fisted_ Read error: Operation timed out
1345148467 J * fisted ~fisted@xdsl-84-44-236-61.netcologne.de
1345148759 M * PeteG back again :)
1345148776 M * PeteG sorry I left but I had a network emergency :/
1345148808 M * PeteG Thanks for the tips Jb_boin. I will try and do the sync next week to see how it goes
1345148910 Q * bonbons Quit: Leaving
1345150653 M * PeteG Well goodnight, be back tomorrow
1345150887 J * clopez ~clopez@65.27.165.83.dynamic.mundo-r.com
1345152509 Q * DLange Ping timeout: 480 seconds
1345154360 Q * nkukard Ping timeout: 480 seconds
1345155154 J * nkukard ~nkukard@197.87.42.133
1345155247 Q * ser Remote host closed the connection
1345155249 J * ser ~ser@host1.tldp.ibiblio.org
1345156028 Q * ser Quit: No Ping reply in 180 seconds.
1345156040 J * ser ~ser@host1.tldp.ibiblio.org
1345157310 Q * clopez Ping timeout: 480 seconds