Copy VM to another pve

esilva

New Member
Oct 25, 2023
19
0
1
Hey guys, i want know how can i copy a virtual machine from a pve (172.16.0.221) to another pve (172.16.0.250). This VM can't stop running (if possible) because is a server.
 
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
 
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
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)
 
If 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.
 
Last edited:
Please 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 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
 
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
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.

Many people in the forum have used this. One is free to search the forum for feedback.
Personally, I would try to use this option over manually mocking around with ZFS, cluster breaking and rebuilding or any other backend migration attempts.


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: homelabenthusiast
If 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.
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
 
Please 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
ok
 
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
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:
Removing Node Steps

Please use translation so you understand.
 
  • Like
Reactions: Kingneutron
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.
This could be a language barrier, but earlier on OP said:
Differents cluster
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.


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!