Standalone ESXi 5 hosts and backup jobs

[GrZeCh]

Hello,

can someone tell me how to handle situation when Veeam B&R 6.1 is managing multiple standalone ESXi 5.0 (licensed) hosts where VMs are being moved to different host or chanding VM vmdk datastores?

I'm testing scenario where I had created backup job which fails after VM moving to different datastore. I've tried to rescan managed server datastores inside Veeam B&R but it didn't helped. How I should handle backup process in my environment when making this kind of changes?

Veeam backup job ends for this Vm with error "Object VMNAME not found" and when I'm editing backup job and hitting recalculate VM disk sizes I'm getting Size "Not available".

Thank you

[Gostev]

Hi, you should create jobs by adding host as a container, instead of adding individual VMs. Thanks!

[dellock6]

Every time you de-register a VM on a host and register it on another standalone host, the VM gets a new moref ID, and in this way Veeam will not be able to find again the moved VM. The scope of a MoRef ID on an ESX(i) host is only within the host itself, this is another reason why it is a best practice to use vCenter to not only manage your inventory but also keeping track of a single consistent global MoRef ID.

[GrZeCh]

Hi, you should create jobs by adding host as a container, instead of adding individual VMs. Thanks!

Thank you for responding. By saying hosts as a container you mean adding vCenters instead of standalone hosts?

I'm planning to use Veeam B&R with two sets of ESXi Essential licenses so I was thinking about adding all of them as standalone hosts instead of adding two vCenters. I was hoping if I move VM between first and second vCenter I will be able to track this VM using Veeam B&R but it looks like it will be not possible?

Is there any chance for a feature (we can call it feature request) where I will be able to reattach backuped VM with new ID to previousle made backup?

[dellock6]

No, Anton means using the whole ESXi host as the source of your backup, instead of selecting single VMs in the job: in this way Veeam will scan the host at every backup run, will see the new VM an will backup it.
One drawback of this solution is that your VM will be saved inside different jobs depending on its position, so it will really be hard to find it...

About the request, Veeam uses moref to identify the VM, just like vCenter does. If you change the moref, how can Veeam know that one is the same VM as it was in the other host? Based on the VM name? And what so if you change the name of another VM and mix it all up?

[GrZeCh]

No, Anton means using the whole ESXi host as the source of your backup, instead of selecting single VMs in the job: in this way Veeam will scan the host at every backup run, will see the new VM an will backup it.
One drawback of this solution is that your VM will be saved inside different jobs depending on its position, so it will really be hard to find it...

About the request, Veeam uses moref to identify the VM, just like vCenter does. If you change the moref, how can Veeam know that one is the same VM as it was in the other host? Based on the VM name? And what so if you change the name of another VM and mix it all up?

I'm not changing VM names at all and I'm not moving VMs between datastores or hosts too often but sometimes it happens. I don't want to Veeam B&R make automaticall assumption based on VM name (but this could be showed as a some kind of a hint like "Have you moved VM with name .... to another hosts?" or something like that). I was thinking more about some kind of manually done checking and updating where I can "tell" Veeam that VM has been moved and has new ID. Since moving VMs is done not too often this would solve this problem and make Veeam B&R more friendly to standalone hosts. If this is only an ID checking then there should not be to hard to implement this kind of functionality. What do you think?

[Gostev]

Anything is doable in software, but because very few customers run VMware without vCenter, I don't think this will ever be implemented as a feature based on the value to the product.

However, the good news is that you can script this fairly easily even today. Lookup the PowerShell script for vCenter backup on this forum, it deals with exact same issue (finds vCenter VM on the other host it was migrated to, and updates the job with new moRef).

[GrZeCh]

I've found what I was looking for and now I will try to check solution fro this topic:

viewtopic.php?p=41616#p41616

Can you consider adding this functionality to your application anyway? In my environment I don't need additional functionality from VMWare other that Essentials license is giving me but backup solution must work correctly and since this is simple ID updating it should not take too much time for you to implement it.

Thank you.

[Gostev]

Highly unlikely, for the reason I've mentioned above. With hundreds of much more valuable features pending (feature that are being requested over and over again all past years), I don't believe this one stands a chance, no matter how simple it is to implement (and it is not that simple). Additionally, this feature will only be usable in tiniest environments with just a handful of VMs (environments where updating some IDs in the job manually after each VM move is not a big deal). This size of environments is not exactly our focus down the road... as you may tell from the new 6.1 UI.

Why are you not using vCenter Server that comes with VMware Essentials?

[GrZeCh]

I'm using vCenters but I was thinking that it will be better when I add all hosts as standalone instead of adding two vCenters (since I'm evaluating I was not sure how Veeam tracks VMs and I was hoping that somehow my scenario will be handled correctly). It looks like that until I will be migrating my VMs inside one vCenter Veeam will keep track of VM and I will only have to run update script when I unregister VM from one vCenter and add it to second one. Correct? If yes then I can agree with you that other features which are waiting to be implemented are far more important.

[Gostev]

If your VMs are under vCenter, then you would not have to update anything or run any scripts at all as you migrate them (using vSphere functionality), as they will retain their moRef through migrations. Just be sure to configure your Veeam jobs through vCenter connection, instead of adding individual hosts.

[dellock6]

Also, if you are concerned by licensing costs, VMware offers vCenter in a virtual appliance version, so you do not have to use a Windows license for it.

[GrZeCh]

Also, if you are concerned by licensing costs, VMware offers vCenter in a virtual appliance version, so you do not have to use a Windows license for it.

Yes. I'm using vCenter appliance. My biggest concern was that I will have to have two vCenters added to Veeam and I've thought that all VMs have some ID which is not being changed during removing and importing VM to another ESXi server and thats why I've decided to add my ESXi servers as a standalone. Now wheb I've checked everything I know how I should handle moving VM properly in Veeam.

I will probably write small c# winforms application which will get MoRef value using Powershell:

Read all VM names from vCenter with host which they are located

Code: Select all

Add-PSsnapin VMware.VimAutomation.Core
Connect-VIServer -server VCENTER -user USER -password PASSWORD
$Information = @()
Foreach ($VM in (Get-VM  | Sort Name)){
    $MyDetails = "" | Select-Object VMName
    $Information += $VM.Name+","+$VM.VMHost
}
$Information


Read MoRef for certain VM

Code: Select all

Add-PSsnapin VMware.VimAutomation.Core
(Connect-VIServer -server ESXiHOST -user USER -password PASSWORD).Name
((Get-VM VMNAME| Get-View).MoRef).Value


and update BObjects table in Veeam DB.

Thank you for sorting this out.

[rbrambley]

I think all the discussion of moref ids, although technically accurate, has made your solution a lot more complex then it really needs to be. Let's back up for a second and over simplify things.

Veeam uses the VMware API to find your VMs. More specifically it saves a record of the VMware object you pick in the Add VMs screen of our job wizard. So, when you pick a VM by name from the Add VM wizard, think of that VM's position in the VMware API. Hostname > VM Name to oversimplify it, for example.

What is happenng to you is that you created a job that is looking for Hostname > VM Name every time it runs, but occassionally the record in the API has been changed to NEWHOSTNAME > VM Name.

Now, if you pick parent objects in the API for example Clustername > VM Name, Resource Pool > VM Name, Foldername > VM Name - when your VMs move around via VMotion, SVMotion, cold migration, etc then the API record has not changed! Veeam actually re - creates the VM list each time it runs by rescanning the child VMs of the parent API object.

Obviously, you need vCenter added to Veeam to use vCenter created parent objects in the Veeam Add VM screen of a new job wizard (BTW, top right corner of the Add VM screen has little square icons. Hover over them and click them to see all the ways you can add VMs to a job). Multiple vCenters in Veeam is no problem.

If you move a VM between vCenters, then yes, your VM will then move between jobs. That's OK, Veeam will auto adjust to using the job that has been created for the parent object (new Cluster for example) where the VM was just moved to, and you should not receive errors. This is also the case if you follow the advice in the first reply to this thread from Gostev - use Hostnames as a parent object without vCenter. No warnings or errors should be triggered as the VMs are removed from one job and added to the other.

Be sure to install the Veeam Enterprise Management Server (included with Veeam BaR). That is where you would be able to search for a VM by name and see all of it's restore points even when it moves between jobs.

Fact of the matter is, I don't know of another customer that cares about keeping track of the MoRef ID - honestly, most don't even know what it is. Point is you don't need to!

[GrZeCh]

Hello,

I would like to return to this topic with one more question. What should happen with VM backups which had changed ID in B&R DB when I set "Deleted VMs data retention period" to 1 day in storage Advanced -> Advanced settings and set in Storage part Restore points to keep on disk to 1? I've just modified my job with this settings and I had a bunch of "... is outdated and will be deleted" lines for all VMs protected by this job and it ended with completely deleting all backup files and now I'm wondering if there should be changed VM IDs in other B&R DB tables.

Regards

EDIT: I've found this topic: viewtopic.php?f=24&t=12262&p=55904#p55904 and it looks like retention period should not be changed in the first place (I've just wanted to save some space until I will replace disks in my backup NAS).