Moving VMs to a new virtual center.

[slidek9]

Hi,
We are in the process to changing our virtual center. I have been looking at how well Veeam handles this kind of change; the sort answer is it does not support this and we need to re-populate all of the backups and off-site replications.
The issue is I cannot use the backups that were taken from the old virtual center, as seeds to re-populate the new replicas at the DR site. So the uuIDs are the same and the VMDKs are the same, is just that in the new virtual center all of the host-ids, storage-ids and VMids have changed; this metadata is recorded in the .vbm files for each backup.

I was wondering if anyone has ever had any joy in editing the .vbm files so they can import a backup from the old virtual center but Veeam thinks it is from the new virtual center. The .vbm file is just XML and I am sure if certain sections are updated to reflect the new VC-ids then the import and seeding would work. Not 100% sure though if change block tracking gets reset though when you import a host into a new virtual center.

- L

[vmbackupuser]

Changing the vCenter server configured in Veeam:

1. The simplest option perhaps is to have a local Hosts file (or DNS) entry for the original servername.


2. Alternatively, there is a 2-line script: http://forums.veeam.com/viewtopic.php?f ... sts#p43206


3. Ideally, this should be GUI option in the next release. Simplicity & minimalism

[tsightler]

Hi,
We are in the process to changing our virtual center. I have been looking at how well Veeam handles this kind of change; the sort answer is it does not support this and we need to re-populate all of the backups and off-site replications.
The issue is I cannot use the backups that were taken from the old virtual center, as seeds to re-populate the new replicas at the DR site. So the uuIDs are the same and the VMDKs are the same, is just that in the new virtual center all of the host-ids, storage-ids and VMids have changed; this metadata is recorded in the .vbm files for each backup.

So if you're referring to replication, why not just use replica mapping? Sure the first pass will require a scan to build new hashes, but only changes will be copied across the wire.

For backups it's the same, just use backup mapping. The first pass will have to read the entire VMDK, but any blocks that are already in the backup will not actually be copied.

[Vitaliy S.]

So if you're referring to replication, why not just use replica mapping? Sure the first pass will require a scan to build new hashes, but only changes will be copied across the wire.

For backups it's the same, just use backup mapping. The first pass will have to read the entire VMDK, but any blocks that are already in the backup will not actually be copied.

I'm afraid it will not work, as I've tried to reproduce this scenario in my lab and during the backup job a new image was created due to different moref ID in backup metadata files.

As to the replication job, if you do this, it will wipe out all previous incremental points (as far as I correctly recall it).

[tsightler]

I'm afraid it will not work, as I've tried to reproduce this scenario in my lab and during the backup job a new image was created due to different moref ID in backup metadata files.

What do you mean an new image was created? A new VBK? I've certainly seen the behavior you describe when mapping backups across Veeam servers, which isn't supported, but not when simply the moref ID changes. Yes the VM must be scanned as a full backup, since it's technically a new VM, but dedupe keeps the blocks from being written. I've not tested with when moving across vCenters, but I've run across this quite a few times with standalone ESX when the moRef ID's change due to external causes. It's interesting that you've seen different behavior.

As to the replication job, if you do this, it will wipe out all previous incremental points (as far as I correctly recall it).

Agreed, but the OP indicated he wanted to use them as "seeds". Seeds typically don't have incremental points so I didn't see this as an issue.

[Vitaliy S.]

What do you mean an new image was created? A new VBK?

I had two VMs listed under the same backup job when I navigated to the backup node. I will double-check that once again tomorrow.

[foggy]

In my case it is also two VMs under the job and the full size VIB file is created after backup mapping:
VBK: 3,028,878KB
VIB: 3,028,878KB
(the VM was turned off)

[tsightler]

I would expect two copies of the VM to show in the backup as technically it is correct that it is a new VM. The "old" VM would be subject to the deleted VM retention period and then would fall out of the job.

Right, I would expect the large VIB with incremental mode since you can only deduplicate within a single file (there's no deduplication between the VBK and VIB files, only within each VBK and VIB). I guess I was assuming reverse incremental as, with this mode, all of the blocks from the "second" VM would already be in the VBK and thus would be "deduped" . Performing a full backing of up a nearly identical VM would not appreciably increase the size of the VBK in this case. With incrementals the next full, whether created with a synthetic or a active full backup should create a file that returns to the original size, so the cost is simply that of one singe full backup of each VM. If your not using reverse incremental, then you expect to have to run a full every now and then anyway, so you should already be sized for that possibility.

[stevil]

I did a search of this topic but couldn't find anything particularly up-to-date.

My question is, we need to move several smaller vCenters to a consolidated central site vCenter. Is there an easy way of having Veeam pick up these changes?
The first one we did took a couple of hours of reconfiguration, we basically had to start again with new replication jobs, I'm assuming the backup (due to run tonight) will see all the regular VM's as 'new' VM's since they are say on a new vCenter. We don't want to go through this again if we can help it

Cheers

[chrisknight]

Hello,
I have one ESXi 4.1 server where I have 2 iSCSI boxes tied in. There are 10 VM's running and I have 2 NAS boxes on the network too where I send backups. I backup all 10 VM's every other week night to every other NAS box. There are 2 backup jobs to backup all 10 VM's running every other night. On Sunday, I have a 3rd job, a replication job that replicates all 10 VM's to the 2nd iSCSI box. There are never any VM's running on the 2nd iSCSI. Just sent the replications there just in case.

We are now adding vCenter and another ESXi 4.1 host to take advantage of HA and to split the load of each ESXi 4.1 server in half. So I will have 5 VM's running on ESXi-1 and 5 VM's running on ESXi-2. I know I need to disconnect the ESXi-1 from Veeam and then add vCenter but how can I tie in the existing backup and replication data to the new jobs? I kinda want to lay out a step by step before I do this in 2 weeks.
I'm thinking:
1. Delete both backup jobs and the 1 replication job.
2. Disconnect ESXi-1 from Veeam.
3. Tie in vCenter to Veeam.
This is where I need some direction. I don't really want to start all over with new backup data if I already have good data. Can someone help out with some best practices? I still want to have the same 2 backup jobs every other night and the replication job to the 2nd iSCSI on Sunday.

Thank you,
Chris Knight

[chrisknight]

Not sure why I was merged here. I'm not moving vCenter servers. I'm coming off of a single ESXi host moving into a vCenter.

[Gostev]

Same thing. This will cause VM refID to change, technically making your VM a new VM, just like when moving vCenter. Read the discussion above, specifically comments from Vitaly and Tom.

[chrisknight]

So the answer is that this can not be done. When I disconnect the single ESXi host, that makes the jobs invalid. When I add the new vCenter to Veeam, I have to create new new jobs which will cause all new backup files to be created. Correct?

[Gostev]

Correct.

[deduplicat3d]

Is there no way to have the DB changed in Veeam to make the VM's show up under one name instead of two. i.e. consolidate it so instead of seeing a list
vm01
vm01
vm02
vm02

you just see
vm01
vm02

[Vitaliy S.]

Since technically these are two different VMs, there is no way to merge their db records.

[Agent Fred]

Hi all,

so far I created my backup jobs using single hosts as servers. Now I've got a vCenter and added the vCenter as a new server. To keep backup my VM's in case of being moved with vmotion, I modified one of my jobs in Veeam B&R V 5.0. I removed the VM and added it again but now not across the host but across the vCenter Server. Now when I start the job it fails with "Child ... (Datastore) for object ... was not found.

Will I have to create a complete new job or is there a possibility to modify the exisiting jobs working with vmotion?

Thanks

[Gostev]

Hi Alfred, you need to re-create the job, since unique VM IDs have changed for all your VMs after you have introduced vCenter, which technically makes them new VMs from perspective of our product. Thanks!

[fcambot]

You won't be able to "link" previous backups to the new job, just keep them until you have enough "new" backups. I had the issue when moving VM to another vcenter.

[Lunddahl]

Hi everyone!

Most of my customers are running rather small vSphere installations, most of the on the Essentials Plus Kit with 3 physical hosts and a small SAN.

Normally they have a physical Veeam Server running all the roles of Veeam, Proxy, Repository and so on, usually all jobs run one time every day in reverse incremental mode, and the resulting files are then offloaded to another physical location, NAS, TAPE or/and Internet.

This must be the most classic and simple Veeam Setup ever, but i works very well, and is cheap to implement, and easy to understand.

However, with vSphere 5.1 VMware seems to be serious about vCenter Server Appliance, and my small customers is not happy about integrating the Infrastructure management servers (vCenter and Veeam) into Active Directory, they look very strange at me when i start talking about certificates, and a second Windows server for running vCenter Web Client (the server part of it).

So i'm asked to upgrade/move/switch the vCenter Server to vCenter Server Appliance.

The most cost effective way of doing that is a switch, Install Vcenter Server Applicance, move the hosts from the old vCenter Server and kill it.

But in that process all the VM's get's a new ID, and to my knowledge that ID is used by Veeam to identify the VM backed up, witch in turn means all the VM's in the jobs are no longer there, and you have to create new jobs, or edit the old ones.

This itself is not a very big issue, but as Veeam sees the VM's as new VM's storage space on the Veeam server doubles, and that will for some customers be and issue.

- Is there a way to avoid recreating/changing the jobs ?

- Is there a way to minimize the extra space required ?

- Does anyone have any knowledge from the field they would like to share ?

Kind Regards
- Ulrik Lunddahl

[dellock6]

Hi Veeam is simply reading the moref value of every vm, and compare it to those already saved on previous backup jobs. This is the same behaviour as you unregister and reregister a VM in vCenter, for example you can see on performance monitor all the graphs will have no history, like it is a new VM.
You can think about moref as the unique id of every vm, so it's used many many VMware component to identify with no error each VM. You can go on using the same job if the restored/reregistered VM was not listed in the job itself (job using resource pool, folder or datastore as the starting point), otherwise you would have to remove and re-add that VM in the backup list.
About retention, if you configure "remove deleted VM after" let's say 14 days, even if it has a new moref the VM backup will remain in the job for 14 days, allowing you enough days to create a new chain of backups.

Luca.

[Lunddahl]

Hi everyone!
- Does anyone have any knowledge from the field they would like to share ?

Well, now i do have some knowledge to share, unfortunately this turned out to be a nightmare...

On this installation i have one vCenter Server and 3 ESX hosts, the job was to take down the old vCenter 5.0 (x.x.x.30) and replace it with a new vCenter Server Appliance (0.0.0.31), the hosts are 0.0.0.32-34

The hosts was removed from the HA/DRS Cluster, by putting them in maintenance mode, when they were all out of the cluster, they were removed from the old vCenter Server, and added to the new one, a HS/DRS cluster was created, and as everything worked super, the old vCenter was powered off.

Now for backups, first i tried to remove the old vCenter from Veeam, but that was not possible because it was a dependency of my jobs, well then then new one was added, and in every job, i deleted the old VM's and added the same VM's again this time by browsing trough then new vCenter in the backup job edit dialog.

The old vCenter server could now be removed without problems, and started the first job, it failed, this job is pointing to a inventory folders, so i thought this could confuse veeam, the rest of the jobs is one job one VM type, so i tried to run the next job.

Success, and as expected this was a full backup, the VM from Veeam's perspective is another one, but has the same name, i use dedupe, and the extra data requirements was next to nothing, the VBK file has almost the same size, so dedupe is working. Well not so bad after all, no need to put that newly purchased DAS array into place anyway, pretty nice.

But unfortunately this was a lucky strike, because only VM's running on one host is able to be backed up, as soon as the were moved to other hosts in the cluster backup fails, the forums seems to tell me something about duplicate entry's in veeams database of hosts, and by looking further in, i seem to get standalone hosts in my setup randomly, as soon as they are deleted and veeam console is restarted they are there again, except for one, the one were backups is working.

Veeam has always been connected to a vcenter server, never to hosts directly.

The "funny" thing here is that i would like veeam to be able to map the same VM's togeather no matter what vCenter holds them, no such luck, but the other way around i would like veeam to differentiate the same host when it's switched from one vCenter to another, seeing it a a new infrastructure, but veeam mixes those things together, even from a license perspective, the licenses needed not to be revoked as i was expecting.

My question is now, is there a procedure for switching from one vCenter Server to another that works AND lets me keep my hosts, or do i have to tear down my whole infrastructure, just because of veeam...

- Ulrik

[TommyTheKid]

I recently moved all my VMs from an old ESX4.1 host to ESXi 5.1. I added the new host to Veeam, but it still can't seem to find the VMs. I used the "migrate" feature in VCenter to move them, so they should have the same GUID I would think?

I also intend to move my Veeam backup itself off of the "shared" host its on (since it seems to need to be rebooted frequently).

I *will* file a support case when I am more awake, but was mostly wondering whether I should bother trying to make the existing server "see" the VMs on the new host, or if I should build the new server and try to "import" the backups from the NAS?

Thanks in advance,
Tommy

[dellock6]

Are you using single ESXi server, or they are both (old and new) connected to the same vCenter? Second case MorefID will remain the same, in first case they will change and that's why you cannot map VMs to the existing ones.
IMHO, best chance is to remap backup, and add those "new" VMs to the same job. After retention period will be passed, into the same backup you will have the new VMs...

Luca.

[TommyTheKid]

Previously, it was a standalone server, but I added the old server to the VCenter for the new servers to do the transfer.

[dellock6]

I think in your situation, the moref id has changed:
http://www.virtuallyghetto.com/2011/11/ ... hange.html

"Here are some additional scenarios in which MoRef ID's will change: Hosts that have been removed from inventory and re-registered with the same vCenter server."

I think your best choice is to open a support ticket, I tried several times to dig into the Veeam DB, but is not supported at all...

Luca.

[jcmachadouga]

Correct.

I am confused now. I opened a ticket with your support and I got these 2 lines of powershell that in theory should do the trick...

$server = Get-VBRServer | ?{$_.name -eq "NameOfVC"}
$server.SetName("NewName")

The move is between 2 vcenters at the same version, not an upgrade.

Veeam Support - Case # 00153498

[Vitaliy S.]

These two lines just change the vCenter Server name added to the backup console, and this trick does NOT preserve old, assigned by the previous vCenter Server, VM IDs. I guess your jobs will most likely fail with "Disconnected VMs" message (or any similar) after applying this change.

[tyno81]

Rescan on our Managed Server (vCenter) results in the following error message:

18-2-2013 15:58:57 Fail Disks and volumes discovery for VMware vCenter 'Vcenter001' failed Error: The object has already been deleted or has not been completely created
18-2-2013 15:58:57 Fail Session failed Error: The object has already been deleted or has not been completely created

When i add a new Managed Server (same server at IP address ) i am able to do a successfull scan:

18-2-2013 15:56:57 Disks and volumes discovery for VMware vCenter 'X.X.X.X' completed

I need to reconfigure the jobs so they are using the "new" server.
How can i arrange this without reconfigure the jobs?

I have tried to re-enter the credentials for the current managed server and do a rescan, but this doesnt solve the issue.

[stuartmacgreen]

Its more than a year after the last update on this post (v7 has been released) and am in middle of creating new production vcenter server 5.5 - not performing an upgrade as our 5.1 vcenter server has loads of issues and won't upgrade.
So am looking to move lock stock and barrel ESX host clusters and VM's to new deployed vcenter server.

Is there a method to moving my VM's backed up by Veeam to a new vcenter server without their being a new moref ID.?

What about this method discussed here. http://vninja.net/virtualization/preser ... g-vcenter/
- using a CNAME alias