Master is fail
- Thread starter docent
- Start date
all VM´s running on the master are down.
you have two possibilities:
- repair the master and bring it up again (e.g. replace the faulty hardware piece)
- the master is gone forever: promote one of the remaining nodes to the new master and restore the VM´s from backup
Hello Tom,
Now that proxmox 1.4 is released, I have setup a master-slave cluster system with DRBD for storage - http://pve.proxmox.com/wiki/DRBD
The live migration is fantastic ! dumping ram and starting VM on slave node works perfectly.
Now the question:
On my master I have one VM. (Shared DRBD / LVM)
On my slave I have no VM.
My master is burning and hardware is dead (simulated by unplugged power).
My slave is alone, he can be promoted to master with "pveca -m", he have the VM disk data to DRBD, but he doesn't seem to have the VM conf file under /etc/qemu-server.
If there any way to start again my VM on my slave ?
Now that proxmox 1.4 is released, I have setup a master-slave cluster system with DRBD for storage - http://pve.proxmox.com/wiki/DRBD
The live migration is fantastic ! dumping ram and starting VM on slave node works perfectly.
Now the question:
On my master I have one VM. (Shared DRBD / LVM)
On my slave I have no VM.
My master is burning and hardware is dead (simulated by unplugged power).
My slave is alone, he can be promoted to master with "pveca -m", he have the VM disk data to DRBD, but he doesn't seem to have the VM conf file under /etc/qemu-server.
If there any way to start again my VM on my slave ?
It can also migrate VM between any nodes, including live migration (by copying RAM) if you are using shared disk (nfs, etc.) or DRBD live replication.
I think, the best way to do this is having config files of VMs on all nodes of cluster and to mark in each config file (or an other methods) the host on which the VM is running. If node on which was run the VM becomes down, any other randomly selected node can run that VM.
I have realised this method on my pve 1.3 and this work fine.
And yet, I think it would be better if the virtual machines would not be tied to a particular cluster node, but would be virtual in a cloud of cluster.
I have realised this method on my pve 1.3 and this work fine.
And yet, I think it would be better if the virtual machines would not be tied to a particular cluster node, but would be virtual in a cloud of cluster.
Last edited:
i'm using for testing a 2 node cluster with drbd for shared storage, some questions:
when a vm is started on a node, its conf file is created in: /etc/qemu-server/
and if the vm is migrated on the other node, the conf file is created on the other node, DISAPPEARING from the first NODE!
so, let's say a node running some VMs fails and is put away for repair, even if i've the vm disks on drbd, HOW could i start the vm on the other node if i've NO conf file???
i think, beside HA on future versions, that on a cluster, conf file MUST reside on EACH node, else there's no way to restart the vm!
or i'm missing something, please let me know...
when a vm is started on a node, its conf file is created in: /etc/qemu-server/
and if the vm is migrated on the other node, the conf file is created on the other node, DISAPPEARING from the first NODE!
so, let's say a node running some VMs fails and is put away for repair, even if i've the vm disks on drbd, HOW could i start the vm on the other node if i've NO conf file???
i think, beside HA on future versions, that on a cluster, conf file MUST reside on EACH node, else there's no way to restart the vm!
or i'm missing something, please let me know...
i'm using for testing a 2 node cluster with drbd for shared storage, some questions:
when a vm is started on a node, its conf file is created in: /etc/qemu-server/
and if the vm is migrated on the other node, the conf file is created on the other node, DISAPPEARING from the first NODE!
so, let's say a node running some VMs fails and is put away for repair, even if i've the vm disks on drbd, HOW could i start the vm on the other node if i've NO conf file???
i think, beside HA on future versions, that on a cluster, conf file MUST reside on EACH node, else there's no way to restart the vm!
or i'm missing something, please let me know...
you should have a backup of your VM´s.
but anyway, we are working on HA for 2.0. if you want it now, you need to do some manual work (e.g. copying the config files somewhere if the vzdump backups are not enough for you).