Compared to the newly installed one? I deleted mine yesterday. Kernel Version?
[SOLVED] Slow Debian 4.0 guest after migration from physical hardware (CPU usage 100% in the dashboard)
- Thread starter Primoz Cankar
- Start date
Compared to the newly installed one? I deleted mine yesterday. Kernel Version?
Sorry, I overlook #3...
I don't know if this is an option for you, but you can try it with a backports-Kernel:
https://www.mail-archive.com/kvm@vger.kernel.org/msg41665.html
http://archive.debian.org/backports.org/dists/etch-backports/
I don't know if this is an option for you, but you can try it with a backports-Kernel:
https://www.mail-archive.com/kvm@vger.kernel.org/msg41665.html
http://archive.debian.org/backports.org/dists/etch-backports/
OK I got some more info now and I think this is solved and is not a problem with etch itself. When I tried to install new packages I got come weird errors that perl is missing. When I went to the folders to see what is going on I saw that some folders don't have the permissions set just "?" So I took a fresh etch install and copied everything needed with rsync from the live server to the virtual one like this:
note that /mnt is where I mounted the root of the virtual fresh install of debian etch whilst runing it with a live CD
Then I rebooted and fixed the grub boot entry to use the now one disk /dev/hda1 as root and it booted nicely and the mysql server came up as expected. Now all I have to do is to test if the connection is working from the programs that are using it and I'll be golden.
Thanks for all your help.
Code:
rsync -avxHWP --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/etc/fstab"} root@X.X.X.X:/ /mnt/note that /mnt is where I mounted the root of the virtual fresh install of debian etch whilst runing it with a live CD
Then I rebooted and fixed the grub boot entry to use the now one disk /dev/hda1 as root and it booted nicely and the mysql server came up as expected. Now all I have to do is to test if the connection is working from the programs that are using it and I'll be golden.
Thanks for all your help.
I guess I spoke to soon - the computer booted normaly then it just halted back to a crawl so it's not fixed. Something weird is happneing here. I've also uninstalled mdadm so that it would not interfere while booting but it still the same very slow and unresponsive.
I' will now try to find the manually built mysql server and the scripts that start it and try to move just that to a freshly installed server. I'll se if that helps and if that is enough to get this going.
I' will now try to find the manually built mysql server and the scripts that start it and try to move just that to a freshly installed server. I'll se if that helps and if that is enough to get this going.
OK. I think this is finaly it. I've managed to uninstall mdamd completly and had to do some reconfiguring so that update-grub correctly set up menu.lst - at first it just kept using /dev/md0 instead of the new /dev/hda1. After the removal of mdadm the VM stopped using the CPU and is now runing at 1-2% when idling. So I had 2 problems:
1. the files on the file system appeared to be corupted (a rsync of the entire server to a fresh VM fixed this)
2. mdadm in the VM was the culprit for the CPU usage at 100%
So finaly I can close this and start on the live server migration to the VM for real
Thank you all again.
1. the files on the file system appeared to be corupted (a rsync of the entire server to a fresh VM fixed this)
2. mdadm in the VM was the culprit for the CPU usage at 100%
So finaly I can close this and start on the live server migration to the VM for real
Thank you all again.
The MySQL may be old and custom compiled. The data can be dumped out and imported into your new VM. All you might then need are the my.cnf and .my.cnf and my.ini files
The problem here is that this version of MySQL had a bug which the developers handled internally via the code so I could brake something and not now it. The program is old and we are not maintaining it and the devs that programmed it are not available to us any more.
do a search for files in etch's mysql-server-5.0 package:
in both the new and old containers and see if you can stop mysql-server in both and copy over the files from the old to the new container and then start the mysql-server. If necessary do the same for the mysql-client. Do not forget to synch the cnf / ini files for mysql.
Code:
dpkg -S mysql-serverIt doesn't matter if I can run the mysql server. It matters if the workaround they made would not work any more because mysql would work differently then what the program expects. Any way the problem is for now solved as I've managed to get the old Debain 4.0 server running after I removed the mdadm from the equation. This server is intended only as a backup in case the physical machine breaks down.