News Categories
Announcement (9) Amy Babinchak (64) Tips (1) SBS 2011 (6) Windows Essentials 2012 (4) Edwin Sarmiento (28) SQL Server (22) SQL Server 2012 (6) SQL Server Clustering (3) SQL Server Disaster Recovery (6) Windows Server 2008 Clustering (1) log shipping (1) Brian Higgins (3) Uncategorized (42) Hyper-V (67) Virtualization (13) Windows 8 (13) Cisco VPN Client (1) Windows Server 2012 (24) Friend of TT (4) Hangout (2) Office365 (4) DNS (8) Jeremy (7) Cliff Galiher (3) Active Directory (12) ClearOS (4) Linux (4) presentations (2) SQL PASS (6) Chris Matthews (4) Printers (2) SharePoint (8) SQL Server Administration (7) Windows PowerShell (3) recovery model (1) sql server databases (1) Dave Shackelford (7) SMB Nation (1) Steve (1) Boon Tee (5) Kevin Royalty (3) Lee Wilbur (2) Philip Elder (10) SMBKitchen Crew (31) Susan Bradley (15) AlwaysOn (1) AlwaysOn Availability Groups (4) readable secondaries (1) row versioning (1) undocumented (1) The Project (2) Webinar (3) Enterprise for SMB Project (9) Security (25) Remote Desktop Connection for Mac (1) Remote Desktop Services (8) Windows Server 2008 (1) Exchange (15) Powershell (6) Microsoft (15) Performance (7) data types (1) Server 2012 (1) monitoring (1) DevTeach (1) SQL Server High Availability and Disaster Recovery (5) Clusters (44) Hyper-V Server 2012 (2) Business Principles (26) Cost of Doing Business (13) DHCP (7) sbs (15) Windows Server (30) SMBKitchen (26) Windows Server 2008 R2 (4) StorageCraft (1) P2V (1) ShadowProtect (6) StorageCraft ShadowProtect (1) VHDs (1) Intel RAID (2) Intel Server System R2208GZ (1) Intel Server Systems (17) RAID (2) SAS (2) SATA (2) Server Hardware (12) Microsoft Licensing (2) OEM (2) System Builder Tips (4) Intel (5) Intel Channel Partner Program (4) Intel Product Support (10) Intel Server Boards (2) Intel Server Manager (2) Cloud (26) IT Solutions (2) On-Premises (20) SMB (9) WIndows Azure (2) StorageSpaces (1) Error (47) Error Fix (35) Intel Desktop Boards (2) Intel SSDs (2) SSD (2) Business Opportunity (17) Data Security (11) Identity Security (7) Information Security (14) Privacy (2) Intel Modular Server (6) Promise (2) Storage Systems (9) Live ID (2) Microsoft ID (4) User Profiles (2) Articles (2) Building Client Relationships (6) DBCC IND (2) DBCC PAGE (2) filtered indexes (2) SQL Server Index Internals (2) training (11) Adobe (3) Internet Street Smart (8) Intel Storage Systems (2) LSI Corp (2) LSI SAS6160 Switch (2) Storage Spaces (7) Firmware Update (2) Product Support (7) Hybrid Cloud Solutions (3) Server Core (2) MAXDOP (1) SharePoint 2013 (1) SharePoint best practices (1) SQL Server Authentication (1) Family (5) Alternatives (1) SBS 2011 Standard (4) Microsoft Small Business Specialist Community (2) Microsoft Surface (2) SBSC (2) Networking (4) Availability Groups (3) CANITPro (1) HA/DR (1) Step-By-Step: Creating a SQL Server 2012 AlwaysOn Availability Group (1) webcast (1) VMWare (2) Conferences (2) Client Focus (2) Disaster Recovery (6) Error Workaround (8) Troubleshooting (4) Logitech (2) Product Review (7) Windows Features (4) XBox Music (2) SBS 2008 All Editions (4) MDOP (2) Microsoft Desktop Optimization Pack (2) Software Assurance (2) W2012E (6) Windows Server 2012 Essentials (6) Internet Explorer (3) USB 3.0 (2) USB Hard Drive (2) Bug Report (2) Microsoft Office 365 (5) sharepoint online (2) BitLocker (2) Windows (2) Microsoft Update (3) Swing Migration (2) Windows Update (4) Outlook (2) Group Policy (9) WS2012e (2) WSUS (3) Office (3) Microsoft Downloads (5) Microsoft Office (3) DRP (3) Virtual Machines (2) Virtual Server Hardware (2) online course (1) SQL Server learning (7) 2 Factor Authentication (2) 2FA (2) PASS Summit 2013 (4) SQLPASS (5) Contest (1) e-learning (1) Udemy (1) smbtechfest (1) backups (2) PASS Summit First Timers (3) IIS (2) RD Gateway (4) RD RemoteApp (2) RDWeb (4) Remote Desktop Connection (2) Remote Web Access (2) Remote Web Workplace (2) Cryptolocker (6) Backup (4) Restore (2) CryptoLocker (1) AuthAnvil (1) SBS 2003 (1) SBS Migration (1) Windows Server 2012 R2 (9) Documentation (1) IE 11 (4) testimonials (11) SQL Server 2008 (1) Best Practices (1) Support (1) Intel Xeon Processor (1) RemoteApp (1) Android (1) iOS (1) Hyper-V Replica (2) PowerShell (2) SBS (3) Break (1) Business Intelligence (1) Excel 2013 (1) Power Map (1) Power Query (1) PowerBI (1) MultiPoint (2) Surface (1) Net Neutrality (1) Opinion (2) ASP (9) HP (2) Scale-Out File Server (8) SOFS (10) Windows Phone (1) Updates (1) Intel NUC (1) Intuit (1) QuickBooks (1) Office364 (1) Intel Server Systems;Hyper-V (1) Firewall (1) Patching (1) Mobile (1) Mobility (1) sharepoint (1) Microsoft Security (1) Beta (1) Storage Replication (1) outlook (1) Hyper-V Setup (3) JBOD (1) Azure (1) PCI (1) PCI DSS (1) PII (1) POS (1) MicroStaff (2) Catherine Barr (2) Third Tier (1) BeTheCloud (1) BrainExplosion (1) LookAWhale (1) Manuel (1) Rayanne (3) SuperSecretNews (1) TechYourBooks (3) Managed Services (1) Training (1) E-mail (1)
RSS Feed
News
Sep
13
Why We Never Dedicate a NIC Port to a VM
Posted by Reprinted Article on 13 September 2013 09:39 AM

We never dedicate a NIC port to a VM. We always _team_ NIC ports. Generally there are two teams in standalone and cluster setups.

Team0: Management (Port 0 on NIC 0 and 1)

Team 1: vSwitch (Ports 1+ on NIC 0 and 1) – Dedicated

I kinda understand the logic of doing that, that is dedicating a NIC port to a VM. However, the whole purpose of virtualization is to separate the guest operating system from the hardware. So, one needs to break from that mindset.

There is no reason why the dual Intel quad-port configurations (8 ports total with 6 for the vSwitch) we do would have a problem with the in some cases 20+ VMs running on the host.

Team configuration exception to the rule would be for CAD/CAM/High Bandwidth needs:

  • Team0: Management (Port 0 on NIC 0 and 1)
  • Team1: vSwitch High I/O (Port 1 on NIC 0 and 1)
  • Team2: vSwitch General VMs (Ports 2+ on NIC 0 and 1)

That leaves a dedicated pair to the higher network bandwidth VM or VMs. We would leave VM density on Team1 at two or three maximum.

BTW, in a disaster recovery scenario having things teamed makes recovery a lot simpler. Trying to keep track of all of those vSwitch names mapped to what VM would be a real PITA when things were tense. Plus, getting all that configured would be that much more time wasted getting things back. Keep It Simple Sir

Oh, and one more thing: Why would one use a dedicated physical port on each node in a cluster for a highly available guest hosted on that cluster?

That leaves a single point of failure and yet we see that it is quite common for NIC teaming to not be used.

With NIC teaming now built into Windows Server 2012 RTM and newer there is no real reason to avoid teaming NICs or NIC Port groups to avoid that single point of failure.

So, when architecting a cluster setup please use NIC Teaming.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/

Windows Live Writer


Read more »



Sep
13
Why We Never Dedicate a NIC Port to a VM
Posted by Reprinted Article on 13 September 2013 09:39 AM

We never dedicate a NIC port to a VM. We always _team_ NIC ports. Generally there are two teams in standalone and cluster setups.

Team0: Management (Port 0 on NIC 0 and 1)

Team 1: vSwitch (Ports 1+ on NIC 0 and 1) – Dedicated

I kinda understand the logic of doing that, that is dedicating a NIC port to a VM. However, the whole purpose of virtualization is to separate the guest operating system from the hardware. So, one needs to break from that mindset.

There is no reason why the dual Intel quad-port configurations (8 ports total with 6 for the vSwitch) we do would have a problem with the in some cases 20+ VMs running on the host.

Team configuration exception to the rule would be for CAD/CAM/High Bandwidth needs:

  • Team0: Management (Port 0 on NIC 0 and 1)
  • Team1: vSwitch High I/O (Port 1 on NIC 0 and 1)
  • Team2: vSwitch General VMs (Ports 2+ on NIC 0 and 1)

That leaves a dedicated pair to the higher network bandwidth VM or VMs. We would leave VM density on Team1 at two or three maximum.

BTW, in a disaster recovery scenario having things teamed makes recovery a lot simpler. Trying to keep track of all of those vSwitch names mapped to what VM would be a real PITA when things were tense. Plus, getting all that configured would be that much more time wasted getting things back. Keep It Simple Sir

Oh, and one more thing: Why would one use a dedicated physical port on each node in a cluster for a highly available guest hosted on that cluster?

That leaves a single point of failure and yet we see that it is quite common for NIC teaming to not be used.

With NIC teaming now built into Windows Server 2012 RTM and newer there is no real reason to avoid teaming NICs or NIC Port groups to avoid that single point of failure.

So, when architecting a cluster setup please use NIC Teaming.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/

Windows Live Writer


Read more »




Help Desk Software by Kayako Fusion