Search results

Tom, As you've asked, I've done some quick tests. I've done an vzdump (proxmox 1.8) and vzrestore on proxmox 2.0 of some VMs (with and without JVM). The host have 8 cores (2x Intel Xeon) and 16Gb of memory. There is only one VM running on the host at the same time. Proxmox 2.0 has been...

To c0mputerking: I've done an instalation from a clean squeeze instalation like you (with dhcp and modifying /etc/network/interface after) and I got the same trouble. The trouble was with pve-cluster that couldn't start. I've commented in /var/lib/dpkg/info/pve-cluster.postinst those line...

Just give 2 or more CPUs to the containers. Not really an ideal solution, but until the problem is solved, it works.

Hello, I've tried the Pezi's workaround, and I confirm, its works for us as well. To answer to Tom, in ours cases, we've always got 0 failcount. 1. we start the container with only 1 CPU, the JVM dies. # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error...

We've got exactly the same problem: after upgrading from 1.8 to 1.9 all ours virtual machines with applications using JVM (jboss, tomcat, nuxeo) stop to work. We did those upgrade (proxmox 1.8 to 1.9): Kernel 2.6.18 -> kernel 2.6.32-6 Kernel 2.6.24 -> kernel 2.6.32-6 Kernel 2.6.32-4 -> kernel...

Wow, thanks Dietmar. I had forgotten to report this, but this was a real pain when cloning VEs. Thanks for the fix!

I did, with some version before the Proxmox 1.6 release, and it's slow as a tortoise too. Does it make sense to you that some driver (SATA controller?) needs some quirk for my hardware controller version, and that is available in 2.6.32 but not in 2.6.24 or 2.6.18? One test I have not done is...

Here's pveversion -v: pve-manager: 1.6-5 (pve-manager/1.6/5261) running kernel: 2.6.24-12-pve proxmox-ve-2.6.32: 1.6-24 pve-kernel-2.6.32-4-pve: 2.6.32-24 pve-kernel-2.6.24-11-pve: 2.6.24-23 pve-kernel-2.6.24-12-pve: 2.6.24-25 qemu-server: 1.1-22 pve-firmware: 1.0-9 libpve-storage-perl: 1.0-14...

Oops, sorry. I mean OpenVZ. There is a KVM on that box too, but it's not set to autoboot, the stability problems are with OpenVZ. I'll try the new kernel ASAP, which I assume it updates to the very last OpenVZ patch?

Hi, I'm in a difficult situation with our Proxmox deployment. Kernel 2.6.24 is stable, but shows horrible disk I/O performance. When I say horrible, I mean a chmod -R of a a few GB in a VE will make the rest of the system grind to a halt, to the point the DNS server (in a different container)...

Oops. You are right. For now, either we stick with a non-working vzreboot, or do a bit of hackery in vzctl: instead of writing that broken init script, a "correct" header can be written and a symlink installed for compatibility with non-insserv installs. This way, it'd work for both worlds. My...

Dietmar, browsing the Debian changelog for squeeze's vzctl, I see Ola seems to have fixed this in the official Debian package: * Backported solution from upstream to solve the problem with vz container reboot and insserv. Closes: #576227. This solution is provided by a series of...

Works like a charm. Thanks Dietmar!

I assume that when dab adds sources to the template, it does not refresh the package list (apt-get update), so only the keyring available in the base system is available at that point?

I'm not sure if I fully understand what's going on with MySQL. Here's a patch for the script, but not for DAB.pm. --- mysql_randompw.orig 2010-09-08 13:24:56.000000000 +0200 +++ mysql_randompw 2010-09-08 13:41:44.000000000 +0200 @@ -1,4 +1,14 @@ #!/bin/sh +### BEGIN INIT INFO +#...

In my case, it works. Thanks a lot.

Wow, that was really silly! Thanks for the pointer, I was pretty sure it was something simple. ;) I hope you can integrate this in a new dab version soon!

I guess you're not aware of this: http://www.debian.org/News/2010/20100905 This means that the backports keyring is not necessary anymore, and all doc that refers to it should be updated.

I've just upgraded a server from proxmox 1.5 to 1.6 and I'm having the same error. device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com Volume groupe "pve" not found done.From your comments, at the initramfs prompt, I did: (initramfs) lvm lvm> vgscan Reading all...

It does not run (or shouldn't) the script during build, but update-rc.d to install the appropriate symlink in /etc/rc2.d. That command works flawlessly if I vzctl enter 90000 and do it by hand. For some reason it fails at that point of the setup. Maybe one of the tools update-rc.d uses is...