I actually have a VM on a proxmox. But its hardware is old and I need to migrate to more powerful hardware. I installed a new PVE on this new hardware, and now I need to copy the machine that is on the old proxmox to this new one. And then turn off the old proxmox. But the virtual machine is a server that cannot be turned off (if possible)Are you trying to end up with a 2nd copy of the VM, or just have it running on a different host?
If it's production-critical, you should look into clustering and/or schedule a maintenance window on a Sunday night or similar
Differents clusterAre two PVEs in a cluster? If yes - live migration is an option. If not, look into "qm remote-migrate" (man qm).
Good luck
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Differents cluster
Good lucklook into "qm remote-migrate" (man qm).
qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> --target-bridge <string> --target-storage <string> [OPTIONS]
Migrate virtual machine to a remote cluster. Creates a new migration task. EXPERIMENTAL feature!
<vmid>: <integer> (100 - 999999999)
The (unique) ID of the VM.
<target-vmid>: <integer> (100 - 999999999)
The (unique) ID of the VM.
<target-endpoint>: apitoken=<A full Proxmox API token including the secret value.> ,host=<Remote Proxmox hostname or IP> [,fingerprint=<Remote host's certificate fingerprint, if not trusted by system store.>]
[,port=<integer>]
Remote target endpoint
--bwlimit <integer> (0 - N) (default = migrate limit from datacenter or storage config)
Override I/O bandwidth limit (in KiB/s).
--delete <boolean> (default = 0)
Delete the original VM and related data after successful migration. By default the original VM is kept on the source cluster in a stopped state.
--online <boolean>
Use online/live migration if VM is running. Ignored if VM is stopped.
--target-bridge <string>
Mapping from source to target bridges. Providing only a single bridge ID maps all source bridges to that bridge. Providing the special value 1 will map each source bridge to itself.
--target-storage <string>
Mapping from source to target storages. Providing only a single storage ID maps all source storages to that storage. Providing the special value 1 will map each source storage to itself.
Sure, good point. Testing should be fairly easy - create a similar/clone VM and perform the move. Even if it was not experimental, I would still test it prior to using on important data.If it says "EXPERIMENTAL feature!" I do not think I want to try that on an important environment unless he/she is confident that it is reliable and had tested it many times
Thanks, i will do with cluster. Sorry for the question, as I'm begginer in proxmox. The cluster I need to create in the new PVE? And then do the migration, and then turn off the old oneIf no downtime is possible then your only option is cluster the two servers and then live migrate the vm. If you have local storage then the migration takes time as it repicates the data first before migration. After that you can break the cluster. The process if very simple if you know what you are doing. Another alternative that is very secure and with very little downtime, like less than a minute if you preprare everything, is pve-zsync.
okPlease see "--online" option for the command I mentioned in post #2 and #6
Code:qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> --target-bridge <string> --target-storage <string> [OPTIONS] Migrate virtual machine to a remote cluster. Creates a new migration task. EXPERIMENTAL feature! <vmid>: <integer> (100 - 999999999) The (unique) ID of the VM. <target-vmid>: <integer> (100 - 999999999) The (unique) ID of the VM. <target-endpoint>: apitoken=<A full Proxmox API token including the secret value.> ,host=<Remote Proxmox hostname or IP> [,fingerprint=<Remote host's certificate fingerprint, if not trusted by system store.>] [,port=<integer>] Remote target endpoint --bwlimit <integer> (0 - N) (default = migrate limit from datacenter or storage config) Override I/O bandwidth limit (in KiB/s). --delete <boolean> (default = 0) Delete the original VM and related data after successful migration. By default the original VM is kept on the source cluster in a stopped state. --online <boolean> Use online/live migration if VM is running. Ignored if VM is stopped. --target-bridge <string> Mapping from source to target bridges. Providing only a single bridge ID maps all source bridges to that bridge. Providing the special value 1 will map each source bridge to itself. --target-storage <string> Mapping from source to target storages. Providing only a single storage ID maps all source storages to that storage. Providing the special value 1 will map each source storage to itself.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
If you do not have a cluster yet, then you have to create a cluster on your old proxmox server where you have all your vms running. Then add the new server to that cluster. There are plenty of guides out there (if you have a 2 node cluster then you may considering adding another vote via for example qdevice or incresing vote of your new server since it would be your primany afterwards). Important is the new server you are adding is empty and the network configuration is set up right so when you migrate your VMs they are connectivity. After migration check if everything works as expected then you can follow my guid here on how you remove the old server:Thanks, i will do with cluster. Sorry for the question, as I'm begginer in proxmox. The cluster I need to create in the new PVE? And then do the migration, and then turn off the old one
This could be a language barrier, but earlier on OP said:If you do not have a cluster yet, then you have to create a cluster on your old proxmox server where you have all your vms running.
Which would imply the nodes may not be standalone. I feel like only general advice is possible, as there is a lot of information missing for specific advice.Differents cluster