I have set up Storage Manager (awesome product!) and added my main Virtual Center and all the VMs have mapped nicely to the storage and LUNs etc.
I've tried to add my VMWare View Virtual Center (very small VDI pool) that is a Virtual Machine in my main Virtual Center but I get the message that the Device already exists - which it does, but only as a virtual server and not a Virtual Center to be added and storage mapped.
Any tips (other than make it physical!) to get this added so I can map the virtual desktops to the storage assigned?
Thanks in advance,
Although we don't specifically support VMware' View VC, the VDI Desktops are VM's and therefore should still be showing within the virtual infrastructure. Since some data collection is taken directly from the ESX Hosts, any host which has a VDI Guest should be reporting that desktop.
Are you not seeing the VDI hosts anywhere?
Thanks for the reply.
I can add the Hosts directly, which is what I plan to do if I can't add the Virtual Center.
The Virtual Center for my VDI (lets call it VC-VDI) is a virtual machine in my main ESX Cluster managed by the main hardware Virtual Centre.
All of the VMs from the main VC are in Stoarge Manger, but including the virtual VC-VDI. So when I go to add this new Virtual Center to Storage Manager it reports "device aleady" exists.
I was just wondering if there was a way of chaging that VM into a VC in Storage Manager and managing it with an agent so I get all the nice linked data from it. The VC-VDI has it's own 2 node ESX cluster it manages, so I'll go with adding the two esx hosts directly if I can't add VC-VDI normally to Storage Manager... hope some of that makes sense!
Yeah - I think that it makes sense, but these vCenters within vCenters always made my head hurt.
Let's try some quick graphics. Is this a (very) rough approximation of your environment?
Graphic Assumptions: There is a Virtual Machine which acts like a "mini" vCenter, but controls *just* VDI Desktops (regardless of the ESX host on which they reside)?
If this is the configuration, are you seeing all of the VM's - meaning, can you see those outside the VDI "box" and those within?
"Please excuse the crudity of this model. I didn't have time to build it to scale or paint it."
Spot on with the diagram. My kids loved colouring it in
Because the VDI Desktops are managed by VC-VDI (and sit on 2 seperate esx hosts not managed by the main VC (they are managed by VC-VDI) - which I think is the bit I missed in my explanation of my setup! Apologies) I don't currently see them in Storage Manager. But I do see everything outside of the VDI box you have drawn.
I know this is not the best setup! I plan on moving VC-VDI to a physical machine. Trying to untangle someone elses setup.
EDIT: I editted your diagram to represent the setup...
I think it's more of an issue with me having the VC-VDI as a VM inside my main VC and therefore Storage Manager (quite rightly) says it's already a device.
Can I remove a device that has been auto discovered (I'm thinking not)?
I think I'll go with just adding the 2 vdi esx hosts individually as I need to see the mapping of storage to VMs for an issue I'm having with IOPs.
But thank you very much for your time and assistance - finding the whole Solarwinds experience to be exceptional!
If anything does spring to mind on adding it, do let me know.
Thanks again and regards,
Had a bit of a brain glitch!
Would this make sense...
Remove the current VC from Storage Manager.
Add the VC-VDI - let it map out.
Then add the main VC back in and let it map out.
That should work shouldn't it?
Mainly trying to do this to get the fullest mapping of VC to VM to LUN to SAN
That would be my best recommendation. Only issue that I potentially see is that you *may* get some duplicate information, though much of it should be normalized.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.