dvSwitch Migration

I was rebuilding my lab and decided to capture the process of moving machines from the standard switch to the distributed virtual switch

In these screenshots, I’ve already created the new distributed switch and added portgroups.

 

Adding my 2 lab hosts to the distributed switch

Now we need a physical uplink.

In my lab, vmnic1 and vmnic2 are carrying virtual machine traffic. Prior to this step, I disconnected vmnic2 from the standard switch. This is the part that has the most risk in that if you have a bunch of VLANs, it’s possible that vmnic1 doesn’t have all of them trunked. This is where you can cause an outage, so it’s important to check the physical switch configuration for all VLANs to ensure they’re all trunked.

I assign vmnic2 to Uplink 2 for no reason other than to keep the “2”s together. After the migration is done, you’d come back in here and assign vmnic1 to an uplink – I would assign it to Uplink 1 for consistency’s sake., but the name of the uplink doesn’t actually matter.

 

Repeat the process for host #2.

You get a summary of the changes before the changes are made

This screen will detect if you’re about to make a disastrous change

My VM traffic is VLAN 203

Now to migrate VMs to the distributed switch, I right click and click Migrate MVs to another network

 

My source network is the standard switch VLAN203 network

 

Destination is the DVS portgroup, still VLAN203

Here’s where it’s awesome. You could migrate every single VM on VLAN203 to the distributed switch by just selecting all here. I play it safe to start by only migrating one. You obviously would probably not want to start with a domain controller, but I like to live dangerously 🙂

Continous ping to the domain controller

 

I get a little blip but don’t drop a ping

 

VM is migrated. I can now migrate all of the VMs on VLAN203, then remove vmnic1 from the standard switch, then come back and add vmnic1 so I have redundant uplinks.

VCIX6 designation clarifications

There is a lot of confusion out there regarding the upgrade paths, the VCIX6, and underlying VCP6 requirements to achieve certification. The Certification folks are working on clarifying language on our website and accurate instructions for our customer-facing employees behind the certification@vmware.com alias.

I am writing this point from the standpoint of the Datacenter Virtualization exam, since that is the track that I am following for my VCDX attempt. If you’re in a different track, the same policy applies for your specific track.

      • If you are brand new to the DCV track, you have to pass the VCP6-DCV exam.  You can’t use a VCP6-DTM to start up the DCV track

 

      • If you are a VCAP5-DCA, you can pass the VCAP6-DCV Design exam to achieve VCIX6-DCV designation

 

      • If you are a VCAP5-DCD, you can pass the VCAP6-DCV Administration exam to achieve the VCIX6-DCV designation

 

      • If you are both a VCAP5-DCA and VCAP5-DCD, you can take either the VCAP6-DCV Design *OR* VCAP6-DCV Administration exam to achieve your VCIX6-DCV designation

 

      • Your VCP in the Datacenter Virtualization track must be valid (unexpired). VCAP5 holders with a valid VCP do NOT have to take the VCP6-DCV exam to sit a VCAP6 exam.

 

      • Passing the VCAP6-DCV Design or Administration exam extends the expiration date of your VCP for 2 additional years

 

      • Achieving the VCIX6-DCV designation will not give you the underlying VCP6-DCV certification.

 

      • The VCIX6-DCV is the only prerequisite for VCDX. You DO NOT need a VCP6-DCV certification

 

VCAP6-DCV Design exam 3V0-622 – Rescore

Update December 6, 2016

The rescore process is complete, all results have been posted to Cert Manager.

Update December 5, 2016

The batch processing at Pearson continues to fail. The certification team is manually updating all score results. This will take a considerable amount of time, but they are making good progress. The hope is to have all rescore results posted by the end of the day Pacific time on December 6th.

Original Post November 30, 2016

Exam takers who failed the 3V0-622 received a notice from Pearson that the exam was under review and might be rescored. The date in this email was that a rescore was expected by November 20th.  We are obviously well beyond that date and people are still anxiously awaiting results of the rescore. I am among those waiting for news.

I have volunteered some of my time with the certification team as a SME to help develop exam content (not for 3V0-622). It’s given me insight into just how extraordinarily time consuming it is to create a legally defensible certification exam. No portion of the process is simple. It’s quite similar to putting code into production – even the slightest change means you have to run your entire battery of testing before promoting code.  Any hiccup means re-running your tests from the beginning.

I have spoken internally with the Certification team at VMware regarding the staus of 3V0-622. They are doing everything they can to get the rescores out. However, you cannot magically make the processes work faster – the whole process from end-to-end takes 3-4 days. QA processes take the amount of time they take and cannot be rushed or skipped. Pearson has encountered a number of technical difficulties with the exam drivers and have had to run the process multiple times. Progress was further impeded by various resources being unavailable due to the Thanksgiving holiday last week.

At this point we are hoping for exam results to be available online on Friday December 2nd.

 

Workspace One screenshots

Today, VMware announced the launch of Workspace One and I wanted to throw a couple of screenshots out there. As a field engineer, I use Horizon Workspace every day to access my work applications. I’ve been using Workspace One for the last month and I’m happy with how responsive it is.

This is the Android URL to get the Workspace One App on your phone:
https://play.google.com/store/apps/details?id=com.airwatch.vmworkspace&hl=en

And the Apple AppStore:
https://itunes.apple.com/us/app/vmware-workspace-one/id1031603080?mt=8

This is what my workspace looks like in Google Chrome. I’ve got the Favorites showing, which are the 6 primary apps I use at VMware. Our catalog is full of many dozens of apps, it’s nice to have a quick Favorites list.

Workspace One - Chrome

 

This is the Workspace One app on my iPhone. It’s an almost identical look and feel, and the favorites I set while in Chrome are the same favorites on my iPhone.

Workspace One- iPhone

 

At VMware, we use two factor authentication to access Workspace One. However, I only had to enter my credentials with RSA key once. After that, I can go back into the app with my Touch ID stored on the iPhone.

Workspace One - Credentials

NSX per-VM licensing compliance

I had a customer with a production cluster of around 100 VMs. They needed to segment off a few VMs due to PCI compliance, and were looking at a large expense to create a physically separate PCI DMZ. I suggested instead the purchase of our per-VM NSX solution. This is a great cost-effective way to license NSX when you’re in a situation like this that doesn’t require socket licenses for your whole cluster.

The problem with per-VM licensing is with compliance. VMware doesn’t have a KB explaining a way to make sure you aren’t using more than the number of licenses that you bought. If you add a 25-pack of NSX licenses to a cluster with 100 VMs in it, the vCenter licensing portal will show that you’re using 100 licenses but only purchased 25. VMware KB 2078615 does say “There is no hard enforcement on the number of Virtual Machines licensed and the product will be under compliance.” However, this post is related to the way per-socket licensing displays when you add it to vCenter, not related to per-VM pricing.

I’ve had a few conversations with the NSX Business Unit (NSBU) and the intent of per-VM licensing is to allow customers to use the NSX distributed firewall without physically segmenting clusters. You can run NSX-protected VMs in a cluster alongside non-NSX-protected VMs. However, you have to take some steps to ensure that you’re remaining in licensing compliance. This post shows you how to do it.

One way to do this is to avoid using ‘any’ in your firewall rules. If all of your firewall rules are VM to VM or security group to security group, all you have to do is keep the total VM count below your purchased VM count. It is difficult to craft a firewall policy without using ‘any’, though this is the simplest method if your requirements lend themselves to this method.

An alternative way is to use security tags. It’s a bit more involved but lets you have precise control over where your NSX security policy is applied.

First, I create two custom tags, Custom_NSX.FirewallDisabled and Custom_NSX.FirewallEnabled

nsx-custom-tags

I then assigned tags to my VMs as shown below. The disadvantage to this method is you have to keep making sure that you security tag VMs. But it does make rule writing easier. I’m only creating two groups – NSX enabled and disabled. However, there’s nothing stopping you from creating multiple tags – maybe you have a DMZ1 and DMZ2, maybe PCI and HIPAA are separate tags.

In this case, I assign all of my PCI VMs the FirewallEnabled tag and the rest of my VMs the FirewallDisabled tag.

assign-security-tag

Now, instead of going to the Firewall section, I go to Service Composer. Don’t be confused by the fact that the security groups already exist – I took the screenshot of the Security Groups tab after I created the groups.

service-composer

First, I create an NSX_Disabled group with a dynamic membership of CUSTOM_NSX.FirewallDisabled.

custom-disabled

Next, I create an NSX_Enabled security group with a dynamic membership of CUSTOM_NSX.FirewallEnabled

custom-enabled

I then specifically exclude NSX_Disabled from the NSX_Enabled group. This guarantees that no firewall rules can touch my excluded VMs.

nsx-exclude

I create a new security policy in Service Composer

new-security-policy

In the Firewall Rules section, NSX has something called “Policy’s Security Groups”.  If we assign the policy to the NSX_enabled security group, we can safely use an ‘any’ rule as long as the other side is ‘Policy’s Security Groups’. So source could be ‘any’ if dest is Policy’s Security Groups, or dest could be ‘any’ if source is Policy’s Security Groups. The security group we made enforces that NSX won’t apply rules on VMs that aren’t in the NSX_enabled group.

policys-security-groups

I then apply my new policy to the NSX_Enabled security group.

policy_apply security-group-select

Doing a security policy this way is a bit more involved than simply using the Firewall section of NSX, but it’s worth considering. It’s a perfect way to ensure 100% compliance in a per-VM model. It’s also helping you unlock the power of NSX – all you have to do is security tag VMs and they automatically get their security policy.

 

Unable to connect virtual NIC in vCloud Air DRaaS

I had a customer open a service request, they were in the middle of a DR test using vCloud Air DRaaS and were unable to connect 1 virtual machine to the network. It kept erroring out with a generic unable to connect error.

It turns out that their VM had a VMDK sized with a decimal point, like 50.21GB instead of just 50GB. I don’t see it often, but this sometimes happens when P2V a machine. The vCloud Director backend can’t handle the decimal point in the disk size, so it errors out.

I’m not entirely sure why the error happens, but the fix is to resize your source disk to a non-decimal number and run replication again.

A quick NSX microsegmentation example

This short post demonstrates the power of NSX. My example is a DMZ full of webservers – you don’t want any of your webservers talking to each other. If one of your webservers happens to be compromised, you don’t want the attacker to then have an internal launching pad to attack the rest of the webservers. They only need to communicate with your application or database servers.

We’ll use my lab’s Compute Cluster A as an a sample. Just pretend it’s a DMZ cluster with only webservers in it.

Compute Cluster A

 

I’ve inserted a rule into my Layer 3 ruleset and named it “Isolate all DMZ Servers”. In my traffic source, you can see that you’re not stuck with IP addresses or groups of IP addresses like a traditional firewall – you can use your vCenter groupings like Clusters, Datacenters, Resource Pools, or Security Tags to name a few.

Rule Source

I add Computer Cluster A as the source of my traffic. I do the same for the destination.

NSX Source Cluster

 

My rule is now ready to publish. As soon as I hit publish changes, all traffic from any VM in this cluster will be blocked if it’s destined for any other VM in this cluster.

Ready to publish

 

Note that these were only Layer3 rules – so we’re secured traffic going between subnets. However, nothing’s stopping webservers on the same subnet from talking to each other. No worries here though, we can implement the same rule at layer 2.

Once this rule gets published, even VMs that are layer 2 adjacent in this cluster will be unable to communicate with each other!

NSX layer 2 block

This is clearly not a complete firewall policy as our default rule is to allow all. We’d have to do more work to allow traffic through to our application or database servers, and we’d probably want to switch our default rule to deny all. However, because these rules are tied to Virtual Center objects and not IP addresses, security policies apply immediately upon VM creation. There is no lag time between VM creation and application of the firewalling policy – it is instantaneous!  Anybody who’s worked in a large enterprise knows it can take weeks or months before a firewall change request is pushed into production.

Of course, you still have flexibility to write IP-to-IP rules, but once you start working with Virtual Center objects and VM tags, you’ll never want to go back.

Alzheimer’s Association – Forgotten Donation

Chris Wahl just put up this blog post showing the donation of royalties from his book, Networking for VMware Administrators. I won my copy for free and at the time I promised to donate to the Alzheimer’s association. I failed to do so, but I have rectified that today.

Below is my personal donation along with VMware’s matching gift. $31.41 is the minimum donation to receive a matching gift with VMware’s matching program.  alz-donation alz-matching