tenthirtyam's Posts

Use the following: esxcli vsan storage tag remove -d <device name> -t capacityFlash Example: [root@esxi153:~] esxcli vsan storage tag remove -d naa.55cd2e415146402c -t capacityFlash [... See more...
Use the following: esxcli vsan storage tag remove -d <device name> -t capacityFlash Example: [root@esxi153:~] esxcli vsan storage tag remove -d naa.55cd2e415146402c -t capacityFlash [root@esxi153:~] vdq -qH -d naa.55cd2e415146402c DiskResults:       DiskResult[0]:             Name:  naa.55cd2e415146402c         VSANUUID:             State:  Ineligible for use by VSAN           Reason:  Has partitions           IsSSD?:  1 IsCapacityFlash?:  0           IsPDL?:  0         Size(MB):  915715      FormatType:  512e
Since the SSDs are the same size, you'll need to tag the capacityFlash of each host: Get the Disks: esxcli storage core devices list Check the status of a specific SSD disk. vdq -qH -d <d... See more...
Since the SSDs are the same size, you'll need to tag the capacityFlash of each host: Get the Disks: esxcli storage core devices list Check the status of a specific SSD disk. vdq -qH -d <disk> Example: <disk> = t10.ATA_____INTEL_SSDSxxxx...... Results: t10.ATA_____INTEL_SSDSxxxx...... ..............    IsCapacityFlash?:  0 Tag the SSD as capacityFlash esxcli vsan storage tag add -d <disk> -t capacityFlash Tag the SSD as capacityFlash esxcli storage core devices list t10.ATA_____INTEL_SSDSxxxx...... ..............    IsCapacityFlash?:  1
This document provides you all 864 design decisions in the VMware Validated Design for Software Defined Data Center 6.0 Architecture and Design documentation into simple spreadsheet for quick ref... See more...
This document provides you all 864 design decisions in the VMware Validated Design for Software Defined Data Center 6.0 Architecture and Design documentation into simple spreadsheet for quick reference. Management Domain: 229 Design Decisions Virtual Infrastructure Workload Domain: 174 Design Decisions Kubernetes with vSphere Workload Domain: 168 Domain Design Decisions Cloud Operations and Automation: 293 Design Decisions It includes columns for determining your level of adherence to the architecture and any justification for deviations.
As many of you may know, this Early Access sub-community provides you an opportunity to download and discuss pre-released design materials for the VMware Validated Designs and VMware Cloud Founda... See more...
As many of you may know, this Early Access sub-community provides you an opportunity to download and discuss pre-released design materials for the VMware Validated Designs and VMware Cloud Foundation. We want you to discover the latest content that is in development and learn about the potential directions in these designs. I'm pleased to share the work that my team and I have been working on recently - Architecture and Design for vRealize Suite 2019 - that's applicable over the foundation for both the currently shipping versions of VMware Validated Design 5.1.1 and VMware Cloud Foundation 3.9.1. This early access material covers the architecture and design elements - no implementation guidance is provided at this time - for the use of vRealize Suite Lifecycle Manager 8.0.1, vRealize Log Insight 8.0, vRealize Operations 8.0.1, vRealize Automation 8.0.1, and Workspace ONE Access (f.k.a. Identity Manager) and the related management and content packs with a single-region or dual-region SDDC. You may notice that the design currently uses NSX Data Center for vSphere for the load-balancing of the Workspace ONE Access, vRealize Operations, and vRealize Automation as this is currently used in the management domain for both the VMware Validated Design and VMware Cloud Foundation. Our plan is to convert this over when as we progress in the transition from NSX Data Center for vSphere to a pure NSX-T Data Center based management domain - stay tuned! Please note that the implementation of the design and the software bill of materials is not fully validated at the time of early access publication. We encourage you to review, comment, and provide your input on the design and even examine it in a proof-of-concept deployment. No assumption should be made that deploying the design on top of the VMware Validated Design 5.1.1 and VMware Cloud Foundation 3.9.1 has been fully validated, nor supported with current or future integrations with SDDC Manager. Please feel free to reach out to me directly at johnsonryan@vmware.com or DM @tenthirtyam on Twitter with any questions or suggestions - I'd be happy to delve into the design and discuss improvements. Got feedback? We want to hear from you. So dive into this latest early access content and share your feedback directly with our solutions architects and product managers!
As many of you may know, this Early Access sub-community provides you an opportunity to download and discuss pre-released design materials for the VMware Validated Designs and VMware Cloud Founda... See more...
As many of you may know, this Early Access sub-community provides you an opportunity to download and discuss pre-released design materials for the VMware Validated Designs and VMware Cloud Foundation. We want you to discover the latest content that is in development and learn about the potential directions in these designs. I'm pleased to share the work that my team and I have been working on recently - Architecture and Design for vRealize Suite 2019 - that's applicable over the foundation for both the currently shipping versions of VMware Validated Design 5.1.1 and VMware Cloud Foundation 3.9.1. This early access material covers the architecture and design elements - no implementation guidance is provided at this time - for the use of vRealize Suite Lifecycle Manager 8.0.1, vRealize Log Insight 8.0, vRealize Operations 8.0.1, vRealize Automation 8.0.1, and Workspace ONE Access (f.k.a. Identity Manager) and the related management and content packs with a single-region or dual-region SDDC. You may notice that the design currently uses NSX Data Center for vSphere for the load-balancing of the Workspace ONE Access, vRealize Operations, and vRealize Automation as this is currently used in the management domain for both the VMware Validated Design and VMware Cloud Foundation. Our plan is to convert this over when as we progress in the transition from NSX Data Center for vSphere to a pure NSX-T Data Center based management domain - stay tuned! Please note that the implementation of the design and the software bill of materials is not fully validated at the time of early access publication. We encourage you to review, comment, and provide your input on the design and even examine it in a proof-of-concept deployment. No assumption should be made that deploying the design on top of the VMware Validated Design 5.1.1 and VMware Cloud Foundation 3.9.1 has been fully validated, nor supported with current or future integrations with SDDC Manager. Please feel free to reach out to me directly at johnsonryan@vmware.com or DM @tenthirtyam on Twitter with any questions or suggestions - I'd be happy to delve into the design and discuss improvements. Got feedback? We want to hear from you. So dive into this latest early access content and share your feedback directly with our solutions architects and product managers!
Visit vmware.com/go/vvd-docs!
That's correct, Daniel.
This is exactly the case, Daniel. These. RPs are used in the consolidated design to ensure resource requirements are met for management, edge, and workload when in the single, initial domain ... See more...
This is exactly the case, Daniel. These. RPs are used in the consolidated design to ensure resource requirements are met for management, edge, and workload when in the single, initial domain and default cluster. RPs are using the standard design to ensure resource requirements are met for the first (default) cluster for edge and workload in a workload domain. Those in the management domain are not required.
As many of you may know, this Early Access sub-community provides you an opportunity to download and discuss pre-released design materials for the VMware Validated Designs. We want you discover t... See more...
As many of you may know, this Early Access sub-community provides you an opportunity to download and discuss pre-released design materials for the VMware Validated Designs. We want you discover the latest content that is in development and learn about the potential directions in these designs. I'm please to share the work that we recently completed, Architecture and Design for VMware Cloud Automation Services with the VMware Validated Design. This early access material covers the architecture and design elements. VMware Cloud Automation Services streamlines multi-cloud infrastructure and application delivery, enhances visibility and cross-functional collaboration, and provides continuous delivery and release automation. This design is applicable to usijg VMware Cloud Automation Services with a single-region or dual-region VMware Validated Design 5.1 deployment, as well as extension the VMware Cloud on AWS. Got feedback? We want to hear from you. So dive into this latest early access content and share your feedback directly with our solutions architects and product managers!
In fact, they would. Because the Master vROps node recieves the .pak and sends it to all connected nodes. Same for vRA, where the primary node informs the secondaries and IaaS nodes. It just w... See more...
In fact, they would. Because the Master vROps node recieves the .pak and sends it to all connected nodes. Same for vRA, where the primary node informs the secondaries and IaaS nodes. It just would not be reflected in the SDDC Manager inventory yet.
Unfortunately, there’s currently not a method to specify a particular instance name. The default (mssqlserver) is expected. There is support, via a KB, to use an alternate port.
With each release of the VMware Validated Designs, the Solutions Architecture and Information Experience teams create or update the diagrams provided in the Architecture and Design sections of th... See more...
With each release of the VMware Validated Designs, the Solutions Architecture and Information Experience teams create or update the diagrams provided in the Architecture and Design sections of the documentation. These are created as vector files with which we export the PNG files you see in the official documentation. It's my pleasure to now share the diagrams from VMware Validated Design for SDDC 5.1.x in Microsoft Visio format with the community. If you have deployed or plan to deploy the VMware Validated Design, you can use these diagrams to update hostnames, IP addresses, and the like for your environment. The set includes: Standard Architecture, plus Multi-AZ Consolidated Architecture VMware NSX-T for Workload Domains VMware Enterprise PKS with NSX-T Workload Domains Download from the GitHub repository. NOTE: All official diagrams for the VMware Validated Design are provided in the product documentation found at vmware.com/go/vvd-docs.
It is our pleasure to share the updated architecture reference poster for the VMware Validated Design for Software-Defined Data Center 5.1. This poster depicts many portions of the fundamental ar... See more...
It is our pleasure to share the updated architecture reference poster for the VMware Validated Design for Software-Defined Data Center 5.1. This poster depicts many portions of the fundamental architecture for both quick reference and discussion. If you’d like to print the poster and hang it on your office wall, the PDF size is 51in x 31in. For more information on VMware Validated Design for SDDC 5.1, read the release notes and documentation at vmware.com/go/vvd-docs
sbhowan09​ - Yes, the manual expansion could lead to some potential untested issues for the vRealize Suite components in future automated upgrades if not included in the SDDC Manager inventory. F... See more...
sbhowan09​ - Yes, the manual expansion could lead to some potential untested issues for the vRealize Suite components in future automated upgrades if not included in the SDDC Manager inventory. For example, pre-flight checks and snapshots. The product managment team is aware of the need to perform the expansion, such as with vRealize Operations, and add this to the native product capability.
Yes, that is correct.
sbhowan09​ Today, VMsare Cloud Foundation system instances are not natively aware of each other. As such, the system deployment in "Region B" or "recovery region" is not nativley aware of "Reg... See more...
sbhowan09​ Today, VMsare Cloud Foundation system instances are not natively aware of each other. As such, the system deployment in "Region B" or "recovery region" is not nativley aware of "Region A" or "primary region". Additionally, in the current version of Cloud Foundation, the addition of vRealize Operations remote collectors and vRealize Automation IaaS Proxy Agents are not automation. You can, however, manually deploy these the traditional way or use vRealize Suite Lifecycle Manager. Note that you will need to add the vCenter Server instance from Region B into the vRealize Suite Lifecycle Manager instance in Region A, download/upload the peroduct binary from the BOM and then perform the organic expansion / scale to add the objects. However, these will not be added to and reflecting in the SDDC Manager inventory but they will be added to their respective deployment.
sbhowan09​ - There are some differences in the architecture for VMware Cloud Foundation and the VMware Validated Designs, this is one of those deltas. No changes are required to the deploy... See more...
sbhowan09​ - There are some differences in the architecture for VMware Cloud Foundation and the VMware Validated Designs, this is one of those deltas. No changes are required to the deployment of the Platform Services Controllers in VMware Cloud Foundation, these should remain as deployed. Any post-deployment introduction of an load-balancer for the services, endpoint repointing, and the like would be unknown to the SDDC Manager inventory and workflows and will result in issues with day-two operations like WLD creation and lifecycle management. You can expect to see someconvergence in the architecture for both in due course since deprecation of external Platform Services Controllers was announced for future vSphere releases.
Updated 2019-04-19 to add NSX-T Workload Domain Diagrams It's my pleasure to share a minor update to the diagrams for VMware Validated Design for SDDC 5.0.1 in Microsoft Visio format with the commun... See more...
Updated 2019-04-19 to add NSX-T Workload Domain Diagrams It's my pleasure to share a minor update to the diagrams for VMware Validated Design for SDDC 5.0.1 in Microsoft Visio format with the community. The set includes: Standard Architecture, plus Multi-AZ Consolidated Architecture NSX-T Workload Domains Download the diagrams from our GitHub repository. NOTE: All official diagrams for the VMware Validated Design are provided in the product documentation found at vmware.com/go/vvd-docs.
cyberwookie NSX is an explicit requirement for alignment with the VMware Validated Design and the management components run within NSX-v logical networks. Additionally, Cloud Builder automates... See more...
cyberwookie NSX is an explicit requirement for alignment with the VMware Validated Design and the management components run within NSX-v logical networks. Additionally, Cloud Builder automates the deployment and configuration to the design specification with the design default or customer provided parameters.
@ERA_GoBlue, We actaully see this quite often - especially for workload domain ckusters where customers wish to use existing storage investments or have specific requirements. While the VMw... See more...
@ERA_GoBlue, We actaully see this quite often - especially for workload domain ckusters where customers wish to use existing storage investments or have specific requirements. While the VMware Validated Design for SDDC is built on and validated with vSAN as the primary storage platform, customers can, in fact, use alternative storage as long as that storage is compatible with the vSphere version in the BOM. Below is an excerpt from the 5.0.x documentation: Physical Storage Design: All functional testing and validation of the design is on vSAN. Although VMware Validated Design uses vSAN, in particular for the clusters running management components, you can use any supported storage solution. If selecting a storage solution other than vSAN, you must take into account that all the design, deployment, and Day-2 guidance in VMware Validated Design applies under the context of vSAN and adjust appropriately. Your storage design must match or exceed the capacity and performance capabilities of the vSAN configuration in the design. For multiple availability zones, the vSAN configuration includes vSAN stretched cluster. Additionally, if you look at the Deploy Parameters on the configuration workbook for 5.0.x you see that vSAN is optional: