jftwp's Posts

Hi all.  Quick question.  We're upgrading from 6.0 U2 ESXi hosts to 6.7 U1. Just wanted to confirm that this is a POST 6.7U1 patch (given 6.7U1 went GA in mid October and this patch was released Nov 9). VMware ESXi 6.7, Patch Release ESXi670-201811001 So... upgrade 6.0 U2 hosts >>> 6.7 U1 >>> then apply ESXi670-201811001 as final step for hosts.  All caught up?  Thanks!

Is anyone who is using the embedded database experiencing any issues?  I've read the install/config guide and apparently the embedded db is just as scalable as using an external SQL db where maximums, etc are concerned.  Other than that, the guide (and release notes) mention no caveats and provide backup/restore procedures via cmd line which is fine (and which I will do).  Just being cautious before implementing, because we've experienced some vendor's variants of PostgreSQL db's wherein the 'vacuuming' can become problematic or other issues have arisen.  I just don't want to kick myself in the future for not having used an external SQL database instead, as I've done for prior versions of SRM going back nearly 10 years, but using the embedded makes the overall deployment infinitely easier.  Trade off? For what it's worth, I can't FIND anything/anyone complaining about the Postgre database in either SRM 5.8 or 6.1.x Thanks for any feedback.

I'm wondering how best to configure our vCenter environment.  We only need 2 vCenters (external PSC model) for the entire US.  Originally, I've been thinking that I'll install a first PSC, then point vCenter in that physical site to that PSC in that newly created 'SSO site'.  Then, install a PSC in the other city/physical site, joining to the existing SSO domain by pointing to the first installed PSC and configuring as a new SSO site.  Finally, install the 2nd vCenter and point it to the 2nd installed PSC in the same SSO domain but in its own SSO site. Then I started thinking---why configure a 2nd SSO site in the 2nd physical location at all?  The WAN links are plenty fast if I ever needed to repoint a vCenter to the other physical site's PSC (documented KB's for both inter and intra repointing available with 6.0 U1 I know).  Couldn't I simplify my deployment further by not creating a 2nd SSO site in the SSO domain?  Why not just have the 2nd PSC join the existing SSO site that was created when the 1st PSC was deployed?  Each vCenter would use the PSC specified in its PHYSICAL location at deployment time, sure/absolutely.  Having just a single SSO site with 2 PSC's in it doesn't appear to be one of the many deployment topologies that VMware has made available in various KB's etc UNLESS it's behind a hardware load balancer----and I just plain don't want to use a LB for this deployment because I don't think the complexity is worth it.  Thoughts?

I have a plan that would allow for our 10 version 5.1 vCenters to be consolidated down to 4 running version 6.0U1.  This would entail spinning up the new vCenters and moving the 'old' vCenter objects/hosts into them.  This will entail a bit of work where dVS's are concerned, but we have that piece more or less figured out using 'swing NICs'.  It's a bit tedious but it's not that bad, and perhaps I can just export existing dVS's and import them into the new vCenters to save a step or two where building any new dVS's are concerned. The issue is that I have a colleague who thinks we should just leave the old environment up on version 5.1 and not migrate ANY of those 'old' clusters/hosts into it and instead build new hosts into the new environment.  We would subsequently move the VMs over to new hosts via swing LUNs, reconfigure their networking, etc.  Of course, that approach would entail VM downtime whereas my approach would not. I like the idea of moving older vCenter resources into the new vCenters but I guess I need more reasons to go the route of my colleague and wait for new host hardware and storage (which we do plan to procure, albeit eventually).  Only about half of our hosts in the 'old' environment would get upgraded in-place, with the other half being replaced with new hardware within the next 6-12 months or so. Which approach would YOU take?  What are the pros/cons to my approach vs that of my colleague?

Hi all.  We have 9 vCenters (5.1 U1, all Windows/no appliances), spanning several geographical locations over relatively high speed WAN links. It was previously 6 vCenters at 4.1 back in 2010, then we upgraded all to 5.1 and have added 3 since. 2 of these 9 vCenters are SRM-enabled.  The other 7 are in linked-mode.  We have a single SSO server (centralized) for the 7 in linked-mode, and the 2 SRM servers are 'isolated' and have their own SSO's.  Together, these 9 vCenters manage 'only' about 75 hosts and 750 vm's combined. Having just come from VMworld, one session on vCenter discussed SSO's, the Inventory service, web client, deployment scenarios and everything else and as the slide deck went on, and it made me think, "Hmmm... why DO we have so many vCenters??? In planning for vSphere 6, why not just consolidate the 7 non-SRM vCenters into a SINGLE vCenter?  That single vCenter could run within the SRM cluster in our primary site, and be recoverable in the SRM cluster in the recovery site. What are some of the pitfalls of just having a single vCenter for the majority of our virtual datacenters and hosts?  vMotion and svMotion wouldn't suffer since all such operations would still only occur within those virtual datacenters (which happen to be located in different geographical regions).  We have high speed links (nothing slower than gigabit except for our London vCenters).  Authentication might be a little bit slow for remote admins outside of the SSO site but we're already used to that.  vCenter<>ESXi host agent communication would be affected since it would no longer be at LAN speed but again our WAN links are pretty fast overall.  We don't have any 'political' barriers where administration and security and so on might necessitate such administrative boundaries. I'm just trying to think of any gotchas before planning on a pre-vSphere 6 consolidation of vCenters.  Thanks for any feedback.

Software:  SRM 5.1.2 on vCenter 5.1 U1, adding vSphere Replication 5.1.2 into the mix. We are using array-based replication and want to 'cutover' our array-based Protection Groups to vSphere Replication-based PG's, and, ultimately, stop using array-based replication altogether. I did not install the vSphere Replication components during the original SRM installation so I'm aware that I need to run the SRM installer in repair/maint mode and select for VR.  But in my reading, I came across the following statement on page 17 of the SRM 5.1 Installation and Configuration Guide:  NOTE: Do not attempt to configure vSphere Replication on a virtual machine that resides on a datastore that you replicate by using array-based replication. I would like to know 'why'---what might happen?  Why would this be a bad thing?  Host-based replication should not be 'aware' of array-based replication and vice-versa given they are 2 totally separate replication mechanisms. Ideally, I would get my VR appliances up and running, and, once VR components were installed on SRM, I could then create VR-based PG's for all of the same VM's that are currently array-based PG's, have respective RP's for them, and, once I'm satisfied with the new PG's and RP's on the VR side of things, then just delete all the array-based PG's and RP's, get rid of the SRA's, and array-level replicated devices, and call it a day. We don't use SRM 'extensively' at all here, and given our WAN pipes and other factors, we have decided that, after some satisfactory initial testing of VR (without SRM), we've decided to rid ourselves of the complexity/costs associated with array-based SRM.  I would just rather run them in parallel (array-based PG's/RP's and VR-based PG's/RP's) so we're not 'exposed' while I would otherwise have to sVmotion these same VM's off of the currently array-level replicated datastores that they now sit on, then setup new PG's based on VR.  Thanks for any feedback.