I am having issues with our SCVMM instance where I can't delete Private Clouds...even if there empty. 

When I right click the Private Cloud and click Delete, the "Jobs" panel says it finished successfully, however, the Private Cloud is not deleted. 

After doing some researching, I believe its because entries in the tbl_WLC_PhysicalObject database table are not being updated correctly, when a VM is moved from one Private Cloud to another. After determining the "CloudID" of the Private Cloud I am trying to delete, I still see resources assigned to this Private Cloud in the tbl_WLC_PhysicalObject table, even though from VMM Console, the Private Cloud shows up empty. 

For some testing purposes, I assigned a VM back to the Private Cloud I am trying to delete, only to move it out again and gather some tracing/logging. When I moved the VM back out of the Private Cloud, I had a SQL Profiler running in the background, capturing the SQL statements on the DB server. Looking at the "exec dbo.prc_WLC_UpdatePhysicalOBject" statement, I see the @CloudID variable is assigned the "CloudID" of the Private Cloud the VM is currently assigned to/the Private Cloud I am trying to delete and is NOT the CloudID of the Private Cloud the VM is being moved to/assigned to. 

Instead of having the VMM Console GUI do the Private Cloud assignment/change...I copied the PowerShell commands out...so I can run them manually. Looks like the script gets 4 variables ($VM, $OperatingSystem, $CPUType, and $Cloud), and then runs the "Set-SCVirtualMachine" CMDLET. For the $Cloud variable, it does return the proper "CloudID" of the Private Cloud I am trying to move the VM too (I ran it separately and then ran an ECHO $Cloud to look at its value). When I run the "Set-SCVirtualMachine" CMDLET, the output has values for "CloudID" and "Cloud" and these are still the values of the source Private Cloud/Private Cloud I am moving the VM out of and ultimately want to delete. 

Has anyone ran into this? Is something not processing right in the "Set-SCVirtualMachine" CMDLET?

Which VMM version are you running? (2012, 2012 sp1, 2012 R2?)

In addition which Update Rollup have you installed across your environment?

-kn

Our version is VMM 2012 R2 with Rollup Update 4 installed. Believe this is the latest and greatest still. 

The VMM database, is it store on a SQL AlwaysOn with availability groups? 

-kn

As of right now...its on a single DB server that doesn't use AlwaysOn, Availability Groups, etc. 

I been slowing looking into this and this is where I am at:

I built a development SCVMM 2012 R2  instance that mocks our production environment (minus all the VM's...just the networking configuration and all the private clouds have been mocked). From there, I started at SCVMM 2012 R2 GA and one by one installed the 4 rollup patches in ordered and at each new patch level,  I monitored the queries coming in through SQL Profiler, as I moved a VM between private clouds and created new VM's within clouds. As I created new VM's and moved the VM's between clouds. the stored procedure "prc_WLC_UpdatePhysicalOBject" all have a value of NULL for the CloudID column....so a CloudID isnt even associated to the physical objects (basically the VHDX files and any mounted ISO's I have on the VM's). 

I did find out this SCVMM instance was upgraded from SCVMM 2008 (I took over after the 2012 R2 upgrade was completed). 

I am thinking at this point...nothing is wrong with SCVMM 2012 R2 if you build and recreate it from scratch and a new DB. I am thinking this might be a depreciated field from SCVMM 2008. The only other thing we did, was put in a SAN and moved VM's from stand-alone hosts to the new CSV's (A mixture of 2008 R2 and 2012 NON R2 hosts). 

At this point...since we dont have Self-Service enabled yet....it will be a days work to rebuild a new instance of SCVMM 2012 R2 and migrate the hosts/VM's to it and start from a clean slate. 

I know the DB structure isnt really published...but does anybody have any other insights into this?