One-liner for cluster information

Get-Cluster | Select Name,@{N="NumHosts";E={($_ | get-vmhost).Count}},@{N="TotalGB";E={[math]::Round(($_ | Get-VMHost |Measure-Object -Sum MemoryTotalGB).Sum,0)}},@{N="Capacity N-1";E={[math]::Round((($_ | Get-VMHost |Measure-Object -Sum MemoryTotalGB).Sum / ($_ | get-vmhost).Count) * (($_ | get-vmhost).Count-1),0)}},@{N="TotalUsedGB";E={[math]::Round(($_ | Get-VM| where {$_.PowerState -eq "PoweredOn"}|Measure-Object -Sum MemoryGB).Sum,0)}},@{N="Free";E={[math]::Round((($_ | Get-VMHost |Measure-Object -Sum MemoryTotalGB).Sum / ($_ | get-vmhost).Count) * (($_ | get-vmhost).Count-1) - ($_ | Get-VM| where {$_.PowerState -eq "PoweredOn"}|Measure-Object -Sum MemoryGB).Sum,0)}},@{N="VM Count"; E={($_ | Get-VM).Count}} | Sort-Object Name | ft -AutoSize

Results look like this:
Name NumHosts TotalGB Capacity N-1 TotalUsedGB Free VM Count
---- -------- ------- ------------ ----------- ---- --------
Cluster 1 4 3071 2304 2034 270 345
Cluster 2 2 768 384 172 212 11
Cluster 3 2 1024 512 431 81 117


Veeam – Migrating to a new vCenter Server

Veeam doesn‘t support moving VM‘s between vCenters without removing them from backup jobs and re-adding them resulting in a new full backup and all sorts of problems with restoring old points.

This method is not supported by Veeam and requires modification for each configuration. The method should still be valid.

All data for backup is saved into repositories so messing with the database will ( hopefully ) not mess with your actual data.

The method is therefore to pick up what data Veeam uses to identify VM‘s and where they‘re located but that is the problem veeam faces when you‘ve moved the VM. It tries to connect to the old vCenter to look for the VM but can‘t find it. You therefore need to dig a little in the database and find which values are used to identify the location.

First table to look at is „dbo.Hosts“, it contains these important values:
ID – The actual host ID, you‘ll need this later
Name – This is the name you can use to identify which host is which
Type – You‘re most likely looking for type with ID = 1 ( vCenter )

Now you can look at „dbo.BObjects“, it has these important values
ID – the ID of the VM
host_id – This should match the ID in the „dbo.Hosts“ table, before you edit this it should contain the same value as the ID of your original vCenter server.
type – type = 1 here means VM, yes this is confusing but we only use this for minor things.
object_id – this is and ID that each vCenter assigns to their VM‘s. When you move that VM between vCenters then this ID changes.
object_name – this is your VM name, it should be the same as the name in your vCenter
uuid – This is the VM Unique ID, it should not change between vCenters but I make no guarantees. Some records don‘t have this ID and I have no clue why, I can‘t be arsed to check because we can go around it.

So what do we need to change to make this work? We actually just need to change the object_id and host_id in „dbo.BObjects“. So why all this other stuff? Because we need to make sure we‘re changing the right VM‘s so we don‘t mess up the actual backups.

Now there‘s one more thing to note. If you look at the BObjects table you‘ll see that it has a „path“ column which directs to a vCenter server and corresponding Resource pool. I have no idea what this is and having the wrong path has no noticeable affect.

I like working with databases because you can easily connect things through SQL but in order to use the information we have we have to add one table to the VeeamBackup database. Because I‘m from a special country I use my own langague for tablenames so please excuse that but basically it means „jointable“, feel free to change the tablename to adapt but remember to change it everywhere in the coming scripts.

So here‘s the table:

USE [VeeamBackup]
CREATE TABLE [dbo].[tengitafla](
[id] [int] IDENTITY(1,1) NOT NULL,
[Name] [varchar](500) NULL,
[UUID] [varchar](500) NULL,
[vmid] [varchar](50) NULL,
[bobj_id] [uniqueidentifier] NULL

We‘re ready to go now really, just disconnect the hosts from your vCenter and move them over to the new one but don‘t touch a single button in the Veeam environment yet, we need to do everything manually.

Oh…. and before moving further, take a backup of your VeeamBackup database just in case something goes wrong.

Now that we‘ve hooked the ESXi hosts under the new vCenter we can grab the information we need to fill the table we created, start with a little powerCLI script to get the data from the vCenter:

$sourceVI = Read-Host “Please enter name or IP address of the source Server”
$creds = get-credential
connect-viserver -server $sourceVI -Credential $creds
$report = @()
filter get-stuff
$bleh = 0
foreach ( $row in $_ )
$row = “” | Select ID, Name, UUID, vmid
$row.ID = $bleh
$row.Name = $_.Name
$row.UUID = $_.config.uuid
$row.vmid = $_.moref.value
$report = get-view -ViewType VirtualMachine |get-stuff
$report | Export-Csv -Delimiter “;” -NoTypeInformation -Path “$defaultviserver.csv”
$a = “$defaultviserver.csv”
(Get-Content $a) | Foreach-Object {$_ -replace ‘”‘, ”}| Select -Skip 1 | Out-File $a
disconnect-viserver -server $sourceVI -Confirm:$false

Output is a CSV with all your VM‘s and the values we need, now to get them into our database. For this we need to have „Bulkadmin“ role on the DB server. To explain before we take a look, I delete all records from the table, import them from the csv which I saved to C:\temp and because my new vCenter is called myvcenter the filename represents that:

from [VeeamBackup].[dbo].[tengitafla]
insert tengitafla
from ‘c:\temp\myvcenter.csv’
fieldterminator = ‘;’,
rowterminator = ‘\n’

Ok, table filled and we‘re good to go… right? Not quite, because I‘m not the best with update statements in SQL I need to match the vm‘s in the join table first with the objects that already exist, so I do like this:
update dbo.tengitafla

set bobj_id =
from BObjects b, tengitafla t
where t.Name = b.display_name

Now we should have all columns in „dbo.tengitafla“ filled, at least for object that we are backing up.

PLEASE, if you haven‘t already, take a full backup of your VeeamBackup database. Murphy is bad and we‘d hate to mess something up just because we were lazy and didn‘t bother to run that tiny script to back up your data.

We now need to find out the ID‘s of our vCenters within the VeeamBackup so we can update the correct values, do this:

select id, name, type from hosts
where type = 1

Output should be something like this ( Data is from my DEV setup )

D283A3C1-A8D2-44A1-8124-3F3D5AE1F13D   new-vcenter     1
61810DAD-C34F-45AB-974B-B89C7FBF769A   old-vcenter     1

Now that I have the ID‘s of the old and the new vCenter we just need to put those into a formula and this is the final script that we run, if you haven‘t already: BACK UP YOUR VEEAMBACKUP DATABASE, if you mess this up and you‘ve broken your setup then it‘s not my problem ( not that it was before! )

update BObjects
set [VeeamBackup].dbo.BObjects.host_id = ‘D283A3C1-A8D2-44A1-8124-3F3D5AE1F13D’, [VeeamBackup].dbo.BObjects.object_id = [VeeamBackup].dbo.tengitafla.vmid
from [VeeamBackup].dbo.tengitafla, [VeeamBackup].dbo.BObjects
where [VeeamBackup].dbo.BObjects.host_id = ‘61810DAD-C34F-45AB-974B-B89C7FBF769A’
and [VeeamBackup].dbo.tengitafla.NAME = [VeeamBackup].dbo.BObjects.display_name
and [VeeamBackup].dbo.BObjects.uuid is null
and [VeeamBackup].dbo.BObjects.type = 1

Not quite there yet though!

Open Veeam client, go to Backup Infrastructure, open Vmware vSphere -> vCenter servers, right click your NEW vCenter and click rescan. Do a backup and see the wonders of my magical fingers at work on your systems!

One more thing…. when you‘re doing restores from points older then your new vCenter, alas before the switch, you‘ll need to manually select restore points even though the names in the restore window all point to the right ones. There is something somewhere that I didn‘t update that still points to your old vCenter so if you restore to original location it will fail, you‘ll need to manually

Ramblings of a mad man

Here you will find ramblings of a mad virtual-guy.

This site is aimed at myself and myself only, all posts here are just my thoughts put on virtual paper and might brake your systems if you try to apply them blind.