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 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...
On a Ubuntu 9 server, whenever I restart the VM, directory /var/run/network is deleted. To get networking to work I need to run the following commands manually:
mkdir /var/run/network
/etc/init.d/networking start
/etc/init.d/apache2
Very strange having directories getting deleted
Any ideas?
I have run into a problem with one of my VMs and would like to recover it from the backup. I have a snapshot backup.
Is there a howto on how to do this?
I tried upgrading the Ubuntu 8 VM to 9.1. All seemed to go OK except something is not working with IP addressing. I can no longer reach the VM at its IP address. I tried changing it from the control panel. It appears to take but I still cannot ssh it. Most of the processes appear to be running...
Thanks. I get the following error when I restart networking (/etc/init.d/networking restart) :
SIOCSIFFLAGS: Cannot assign requested address
But....the IP addresses appear to work fine. :confused:
Can you give me a sample configuration. I tired:
iface eth0 inet static
address 192.168.1.17
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
which is the configuration I would use for a physical machine.
Is there a way to change after you have created the VM?
I have done many modifications to the VM and if I have to create it again, I will have to redo those changes.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.