VM moved to new vCenter

[veremin]

I got the infamous host with uuid not found message

Have you tried to revoke license as mentioned here?

It works well for vCenter upgrading process, when a new UUID is assigned to vCenter instance, so, it might be worth trying to take similar steps.

Furthermore, procedure described by Alexander regarding recreating/mapping jobs shouldn’t produce any errors, as it’s a time-proved solution for the situation like yours. Thus, I’d recommend to keep working with our support team on addressing your issues.

Hope this helps.
Thanks.

[Tobias_Elfstrom]

Have you tried to revoke license as mentioned here?

Yes, that did not solve the issue.

It works well for vCenter upgrading process, when a new UUID is assigned to vCenter instance, so, it might be worth trying to take similar steps.

Furthermore, procedure described by Alexander regarding recreating/mapping jobs shouldn’t produce any errors, as it’s a time-proved solution for the situation like yours. Thus, I’d recommend to keep working with our support team on addressing your issues.

Hope this helps.
Thanks.

What you are saying seems perfecly logical and I agree, it should work. I have remapped jobs Before with no problem howerver in this case it did not work. Recreating the jobs and not remapping worked well as a workaround though so I'm sticking with that. (Everything is scripted so it was not a big issue.)

BR Tobias

[msolovey]

Hello, Veeam community!
My firm uses Veeam 6.5.0.109 with two vCenter Servers in it. Each vCenret consists of 3 nodes. Recently we migrated 1 VM to different vCenter. After that, backup of this VM fails. I've re added VM to backup specification and Veem see it in specification, but when I run backup I see this error:

Failed to execute SOAP command "CRetrievePropertiesOperation". Details: "<ManagedObjectNotFoundFault xmlns="urn:vim25" xsi:type="ManagedObjectNotFound" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><obj type="HostSystem">host-4453</obj></ManagedObjectNotFoundFault>"
The object has already been deleted or has not been completely created

How can I make my backup work again? Full recreation of backup job with deleting of all existing backups is acceptable for me, but I've not done it yet. Maybe there are other things that I can try?

Thank you!

[veremin]

Hi, Mikhail.

Your post has been to existing discussion regarding similar issue; so, kindly take a look at the answers provided above. If you still have any additional questions, don’t hesitate to ask for further clarification. Thanks.

[msolovey]

I fully deleted this Job and all backups for my VM. Than I recreated Job again. Got the same error. I don't know what to do now and I can't find any helpfull in linked topic. Are there other things I can do to make my backup work properly?

[veremin]

Then, you’d better contact our support team and they will be able to assist you in the process of deleting obsolete entries from VB&R SQL database. Thanks.

[msolovey]

Thank you, but I've not contacted your support yet. How can I do it and what information should I provide to your support?
Thank you again.

[veremin]

You can open a support case and provide required logs by going to:

http://cp.veeam.com/

Thanks.

[GabesVirtualWorld]

Hi
We're migrating to a new vCenter Server and version very soon. Currently using Veeam B&R 6.5. I've read the thread "VM moved to new vCenter" http://forums.veeam.com/viewtopic.php?f=24&t=12038 but I see mixed results of success. With 800+ VMs, I'm not really looking forward to remapping all those VMs.

Is this migration path improved in V7? If so, I would first upgrade to V7 and then perform the migration.

Also found this blogpost by Christian Mohn, is it supported?
Preserve your Veeam B&R Backups Jobs when Moving vCenter http://vninja.net/virtualization/preser ... g-vcenter/

[foggy]

Gabrie, nothing has changed regarding that in v7, so I'm merging your post into existing discussion. Since VMs are still tracked by their moref ID's, which will be changed on registration in new vCenter, you do still need either to re-map all the VMs or perform full job run instead. Keep in mind though, that you do not need to map each single VM to its backup, you map the backup job to the existing backup file. Considering you do not have a separate job for each of your 800+ VMs, this task should be much easier.

Regarding the mentioned blog post, this trick will allow you to avoid job/deletion/creation in case you want to remove old VC from environment, existing jobs will continue to run. However, the full run will be performed as VMs' ID's will still change.

[GabesVirtualWorld]

Hmmm that full backup is going to be a challenge. We now have about 30 jobs, all folder based. I don't have the capacity to have two full backups on my storage.

Do you store the Moref ID in the Veeam Database? What if I write a SQL Query that would replace the old Moref in the database with the new Moref after I moved the VMs to the new vCenter?

[foggy]

That was what I was thinking of before answering you, however I decided that that would be even a greater challenge, at least from my perspective. Though still a viable workaround.

[veremin]

Hmmm that full backup is going to be a challenge. We now have about 30 jobs, all folder based. I don't have the capacity to have two full backups on my storage.

As mentioned above, after upgrade takes place you can just re-map backup jobs to existing backup data. This should guarantee that no new full backup will be performed.

What if I write a SQL Query that would replace the old Moref in the database with the new Moref after I moved the VMs to the new vCenter?

You can do it, though, please be aware that it’s certainly unsupported to change Veeam SQL database and if it leads to undesired consequences you will be by your own. Thanks.

[GabesVirtualWorld]

Remapping the VMs would be my most desired solution, but the backup administrator is about twice as big as I am and I don't have the guts to tell hem he needs to remap 800+ VMs

[foggy]

Remapping the VMs would be my most desired solution, but the backup administrator is about twice as big as I am and I don't have the guts to tell hem he needs to remap 800+ VMs

Just in case you missed that:

Keep in mind though, that you do not need to map each single VM to its backup, you map the backup job to the existing backup file. Considering you do not have a separate job for each of your 800+ VMs, this task should be much easier.

[GabesVirtualWorld]

I indeed missed that. Thank you !!! Will work with this in a test environment.

[cainef]

Hi All,
I am in a situation where I have had to rebuild our vCenter 5.1 update 1c installation from scratch.
The name, IP address and credentials for the vCenter server are the same, however I have had to add the ESXi hosts back manually and configure.

I logged into Veeam 6.5 and done a rescan, and can connect to storage and see all of the servers without issue.

I have looked through the forums and have seen posts where the fix for people who have upgraded or rebuilt is to remove the VMs from the jobs and add them back mapping to the backup file.

If I do this when the next backup is run, will it do a full or an incremental?

We have several large backup jobs some of which can take up to 24 hours for a full backup to complete - fine for a Friday, but it is Monday here and I dread the thought of a snaphot rolling up during business hours - particularly the mail server. This has happened before and ground the server to a halt for several hours.

I have seen this http://www.interworks.com/blogs/ijahans ... ror-vmware and was wondering whether it was an option?

I have logged a support case 00478634, but thought I'd check here as well.

Thanks

[foggy]

If I do this when the next backup is run, will it do a full or an incremental?

Only incremental changes will be copied over in this case.

[VladV]

Sorry if I'm wrong but doesn't the MorefID of the VMs change when you re-add the host with the running VMs back into vCenter.

In my case, when I reinstalled our vCenter, even if I kept the jobs, Veeam processed the VMs as "new" and added the VMs along the "old" ones (even if they are the same) with the same name. After the retention period for removed VMs expired, it deleted the "old" ones and the "new" ones remained.

Please correct me if I'm mistaken.

Regards

[foggy]

Vlad, have you mapped the jobs to the previously existed backup files?

[VladV]

Yes. But this was about 2 months ago.

This I think is normal because it is practically a different VM once it has a different id. So once you map it you just tell the job that you are adding a new vm alongside the existing one thus it creates an incremental file vib eith the dimension of the full backup.

I am now in the same situation of reinstalling our vcenter to have a clean state for 5.5 so once I remove an esxi and add it to the new vcenter with it's running vms I will have the chance to test my previous statement.

[VladV]

http://forums.veeam.com/viewtopic.php?t=10540#p45847

It seems that Vitaliy encountered the same issue.

[foggy]

Correct, with forward incremental backup mode, first increment after the ID change will have size comparable to the full.

[resruss]

Hi all,

We've got a setup running Veeam B&R 6.5, vSphere 5.0 U1 and vCenter Server Appliance 5

We're about to do a host upgrade to 5.1 U1c, which means upgrading vCSA prior to doing so
These are done by firing up a new appliance and putting them both in upgrade mode, the new vCSA assumes the identity of the old one

From 5.0.x to 5.1 is supposedly a challenging upgrade, so I've got a couple of options, one of which being just setup 5.1.x as a new vCSA and moving the vSphere hosts to it

Just wanting to confirm a couple of things from the Veeam side of things:

If I were to create a new vCenter and move the hosts to it, I'm assuming the VMIDs would change for each guest that's being backed up
Is there any way to retain the existing backups, via map backups or similar?
If the vCenter was created as new and had a different hostname, is there a way to change the targeted vCenter within Veeam to allow the existing backup jobs to be retained?

Does Veeam v7 have any more capabilities that may assist me here, if it does, it may be worth an upgrade

Has anybody else done the vCSA upgrade form 5.0.x to 5.1.x and had any issues / got any tips that may help things run smoothly if I choose the upgrade route?

[resruss]

One question I forgot to ask too, if I actually had to delete the backups from disk and backup jobs from Veeam, and recreate with the same job names, how would I ensure Veeam uses the existing directories for new backups?

It's important for copying to tape

[foggy]

Russel, please look through the discussion above. You existing jobs and backups will be retained, you will however need to re-add VMs into jobs and map them to the existing backup files. The first run after that will require reading of full VM data.

[VladV]

When you re-import the VMs into the new VCSA, Veeam considers them as being different VMs with the same name. So then you have to remove the old VMs from the job and add the new one in, then map to the old backup file. When doing this you will have two VMs in the same backup file with the same name. The old one will be considered deleted and will have the retention policy of deleted VMs.

Also take into consideration that besides Veeam having to read the full VM data it will also create an incremental file (or vbk file if the day of the backup coincides with the day of fulls) as large as the full backup of the respective new VM.

To keep it simple it's like adding a new VM into an existing job and removing the existing VM, thus on the next backup run you will have a full backup sized VIB. I believe that you don't even have to map the backup but I don't remember exactly how I've done in the past.

[VladV]

One question I forgot to ask too, if I actually had to delete the backups from disk and backup jobs from Veeam, and recreate with the same job names, how would I ensure Veeam uses the existing directories for new backups?

It's important for copying to tape

Test on a small job or, better yet, delete the old backup JOB folders (they should be empty once you remove the backups from the disk). It should recreate them as you run the job.

[resruss]

Correct, with forward incremental backup mode, first increment after the ID change will have size comparable to the full.

I assume the same goes for VRB?

Just to be 100% clear, there's no way we can map the old VM ID to the new one?
The full backups take up quite a large amount of space and as another user posted above, it's Monday, I'd rather be doing this on a Friday so snapshot commit happens over the weekend.

[Vitaliy S.]

I don't think that with reversed incremental you will have a space issue, as all blocks from the old VM will be deduped with a new one. See this topic for further info > http://forums.veeam.com/viewtopic.php?t=10540#p45927