Recent content by crewze

promox:~# pveversion -v pve-manager: 1.4-10 (pve-manager/1.4/4403) qemu-server: 1.1-8 pve-kernel: 2.6.24-16 pve-qemu-kvm: 0.11.0-2 pve-firmware: 1 vncterm: 0.9-2 vzctl: 3.0.23-1pve3 vzdump: 1.2-5 vzprocps: 2.0.11-1dso2 vzquota: 3.0.11-1

OK. I ran it on the second node: proxmox1:~# vzdump --snapshot --storage Tuesday --mailto george@shafer.ca 1008mkdir /mnt/pve/Tuesday: File exists at /usr/share/perl5/PVE/Storage.pm line 2104 If I run it on the main node I get: promox:/var/log# vzdump --snapshot --storage Tuesday...

No --- I ran it on node 1. I was under the impression that all management for the cluster was done on the master node. Do you not configure all of the backups on the master?

When I run this command from the command line: vzdump --quiet --node 2 --snapshot --storage Tuesday --mailto george@shafer.ca 1008 It goes away for a few seconds and then returns to the command prompt. It does not back anything up or send me an email.

I created the command from the Proxmox admin panel so it is all selected by drop down boxes. I have not moved any of the VMs.

I have a cluster of 2 nodes that is working fine (proxmox and proxmox1). I have setup backups for the master node (proxmox) to an external NFS and that is working fine. I setup the backup for VMs on the other node (proxmox1) to the same NFS and they worked for a while and then stopped working...

Yes and no --- I migrated back to the original node today and exactly the same problem occurred. The VM appears to migrate fine but when you browse to the VM you get the following: Database Error: Unable to connect to the database:Could not connect to MySQL When you ssh to the VM and try to...

Yes -- I tired both online and offline. I did mange to migrate the Joomla VM --- it had a mysql issue but did migrate. I opened up another thread on that issue. Joomla is Debian based and the one that would not migrate is Ubuntu based. Not sure that has anything to do with it but I see some...

I tried migrating the Joomla VM on 1.4 today and it seemed to go over OK but then would not work as it could not connect to the mysql database. After poking around it looks like the root password did not get copied across. I started up mysql in safe mode and set the root password and then...

I have a cluster with 1 master and 1 node. Everything looks fine on the dashboard. There are no VMs on the backup node. When I try to migrate a VM I get the following error: Syncing 2nd level quota Error: Failed to undump container vzquota: (error) Quota is not running for id 1014 VM1014...

Hmmmm....Not sure what happened here. The second time I restarted the VM it came up fine. Must have done something wrong the first time. Thanks for your help.

I tried the fix in the thread which sets RAMRUN=no and RAMLOCK=no in the /etc/default/rcS file. This is now the contents of the file: # # /etc/default/rcS # # Default settings for the scripts in /etc/rcS.d/ # # For information about these variables see the rcS(5) manual page. # # This file...