 © Rakhesh Sasidharan
|
Posted: June 28th, 2015 | Tags: powercli, vsphere | Category: Virtualization | § Was trying to delete a VM template but it kept throwing the above error. I had a feeling this was because the underlying disk was missing in the datastore (because I couldn’t find any folder with the same name as the VM in the datastore) but there was no way to confirm this as you can’t right click a VM and note its settings.
Thanks to PowerCLI though, you can:
|
|
PowerCLI> Get-HardDisk -Template "2012R2_Gold (Aug2014)" | fl FileName Filename : [xxxDATA01] 2012R2_Gold (Aug2014)/2012R2_Gold (Aug2014).vmdk Filename : [xxxDATA01] 2012R2_Gold (Aug2014)/2012R2_Gold (Aug2014)_1.vmdk |
The Get-HardDisk cmdlet can be used to return the hard disks used by a VM or template. It can even be used to return all hard disks on a datastore (or in a specified path on the datastore):
|
|
PowerCLI C:\> Get-HardDisk -Datastore "xxxData02" CapacityGB Persistence Filename ---------- ----------- -------- 40.000 Unknown [xxxDATA02] VS-EXCH01/VS-EXCH01.vmdk 250.000 Unknown [xxxDATA02] VS-EXCH01/VS-EXCH01_1.vmdk 40.000 Unknown [xxxDATA02] VS-WSCOM01/VS-WSCOM01.vmdk PowerCLI C:\> Get-HardDisk -Datastore "xxxData02" -DatastorePath "[xxxDATA02] VS-DC01" CapacityGB Persistence Filename ---------- ----------- -------- 20.000 Unknown [xxxDATA02] VS-DC01/VS-DC01_1.vmdk 20.000 Unknown [xxxDATA02] VS-DC01/VS-DC01.vmdk |
Posted: June 23rd, 2015 | Tags: powercli, powershell, vsphere | Category: PowerShell, Virtualization | § More as a note to myself than anyone else, here’s a quick and dirty way to list all the VMs in a cluster with the number of snapshots, the used space, and the provisioned space. Yes you could get this information from the GUI but I like PowerShell and am trying to spend more time with PowerCLI.
|
|
Get-VM -Location (Get-Cluster -Name "My Cluster") | ft Name,PowerState,@{Name="Snapshots";Expression={(get-snapshot $_.Name | Measure-Object).Count}},@{Name="Used Space (GB)"; Expression={$_.UsedSpaceGB};FormatString="F0"},@{Name="Provisioned Space (GB)"; Expression={$_.ProvisionedSpaceGB}; FormatString="F0"},DatastoreIdList -AutoSize |
Posted: June 21st, 2015 | Tags: exchange, powershell | Category: PowerShell, Windows | § As the title says, here’s a one-liner to quickly create a list of all Exchange mailboxes in an OU with mailbox size, Inbox size, Sent Items size, and the number of items in each of these folders.
|
|
Get-ADUser -filter * -SearchBase "ou=MyOffice,ou=DomainUsers,DC=MyDomain,DC=com" -Properties * | ?{ $_.msExchHomeServerName -like "*Exchange*" } | Sort-Object DisplayName | Select-Object Name,@{Name="MailboxSize"; Expression={(Get-MailboxStatistics $_.Name).TotalItemSize}},@{Name="InboxSize"; Expression={(Get-MailboxFolderStatistics $_.Name -FolderScope Inbox | Select -First 1).FolderSize}},@{Name="InboxItems"; Expression={(Get-MailboxFolderStatistics $_.Name -FolderScope Inbox | Select -First 1).ItemsInFolder}},@{Name="SentSize"; Expression={(Get-MailboxFolderStatistics $_.Name -FolderScope SentItems | Select -First 1).FolderSize}},@{Name="SentItems"; Expression={(Get-MailboxFolderStatistics $_.Name -FolderScope SentItems | Select -First 1).ItemsInFolder}} | Export-CSV -Path \path\to\file.csv |
Posted: June 19th, 2015 | Tags: bitlocker, encryption, SEDs, SSDs | Category: Windows | § Got myself a new 1TB Crucial MX200 SSD today. This is a Self Encrypting Drive like my other SSDs. When I tried enabling BitLocker on it as I usually do, I noticed that it was asking me about how to encrypt the drive and taking more time with the encryption than I have seen in the past with SED drives that support the TCG OPAL standard.
 Not good if you get this screen! Something was not right. So I went back to Microsoft’s page on BitLocker and SEDs and noticed that one of the requirements was that the drive must be uninitialized! Damn! In the past I usually enable encryption and then copy over data, but today I had copied the data first (thus initializing the drive and creating partitions) and then I was trying toe enable encryption. Obliviously that was a no-go so I had to copy the data out of the drive, uninitialize it, and then turn on BitLocker encryption.
Uninitializing is easy via diskpart:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
DISKPART> list disk Disk ### Status Size Free Dyn Gpt -------- ------------- ------- ------- --- --- Disk 0 Online 447 GB 1024 KB * Disk 1 Online 931 GB 1024 KB * <--- this is my SED Disk 2 Online 119 GB 0 B Disk 3 Online 931 GB 0 B * Disk 4 Online 465 GB 1024 KB DISKPART> select disk 1 Disk 1 is now the selected disk. DISKPART> list partition Partition ### Type Size Offset ------------- ---------------- ------- ------- Partition 1 Reserved 128 MB 17 KB Partition 2 Primary 400 GB 129 MB Partition 3 Primary 531 GB 400 GB DISKPART> clean DiskPart succeeded in cleaning the disk. DISKPART> list partition There are no partitions on this disk to show. DISKPART> exit Leaving DiskPart... |
Now Disk Management will show the disk as uninitialized.
Create partitions as usual but before writing any data to the disk turn on BitLocker encryption. This time it will be a one-second operation and you won’t get a prompt like above.
To confirm that the drive is hardware encrypted (in case you wonder whether BitLocker didn’t just zip through coz the drive had no data on it) use the manage-bde command:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
C:\>manage-bde -status BitLocker Drive Encryption: Configuration Tool version 6.3.9600 Copyright (C) 2013 Microsoft Corporation. All rights reserved. Disk volumes that can be protected with BitLocker Drive Encryption: Volume D: [DATA] [Data Volume] Size: 450.00 GB BitLocker Version: 2.0 Conversion Status: Fully Encrypted Percentage Encrypted: 100.0% Encryption Method: Hardware Encryption - 2.16.840.1.101.3.4.1.42 Protection Status: Protection On Lock Status: Unlocked Identification Field: Unknown Automatic Unlock: Enabled Key Protectors: Password Numerical Password External Key (Required for automatic unlock) |
As you can see the drive is hardware encrypted.
One of the things you can do with a portgroup is define teaming for the underlying physical NICs.
If you don’t do anything here, the default setting of “Route based on originating virtual port” applies. What this does is quite obvious. Each virtual port on the virtual switch is mapped to a physical NIC behind the scenes; so all traffic to & from that virtual port goes & comes via that physical NIC. Since your virtual NIC connects to a virtual port this is equivalent to saying all traffic for that virtual NIC happens via a particular physical NIC.
In the screenshot above, for instance, I have two physical NICs dvUplink1 and dvUplink2. If I left teaming at the default setting and say I had 4 VMs connecting to 4 virtual ports, chances are two of these VMs will use dvUplink1 and two will use dvUplink2. They will continue using these mappings until one of the dvUplinks dies, in which case the other will take over – so that’s how you get failover.
This is pretty straightforward and easy to set up. And the only disadvantage, if any, is that you are limited to the bandwidth of a single physical NIC. If each of dvUplink1 & dvUplink2 were 1Gb NICs it isn’t as though the underlying VMs had 2Gb (2 NICs x 1Gb each) available to them. Since each VM is mapped to one uplink, 1Gb is all they get.
Moreover, if say two VMs were mapped to an uplink, and one of them was hogging up all the bandwidth of this uplink while the remaining uplink was relatively free, the other VM on this uplink won’t automatically be mapped to the free uplink to make better use of resources. So that’s a bummer too.
A neat thing about “Route based on originating virtual port” is that the virtual port is fixed for the lifetime of the virtual machine so the host doesn’t have to calculate which physical NIC to use each time it receives traffic to & from the virtual machine. Only if the virtual machine is powered off, deleted, or moved to a different host does it get a new virtual port.
The other options are:
- Route based on MAC hash
- Route based on IP hash
- Route based on physical NIC load
- Explicit failover
We’ll ignore the last one for now – that just tells the host to use the first physical NIC in the list and use that for all VMs.
“Route based on MAC hash” is similar to “Route based on originating virtual port” in that it uses the MAC address of the virtual NIC instead of virtual port. I am not very clear on how this is better than the latter. Since the MAC address of a virtual machine is usually constant (unless it is changed or a different virtual NIC used) all traffic from that MAC address will use the same physical NIC always. Moreover, there is the additional overhead in that the host has to check each packet for the MAC address and decide which physical NIC to use. VMware documentation says it provides a more even distribution of traffic but I am not clear how.
“Route based on physical NIC load” a good one. It starts off with “Route based on originating virtual port” but if a physical NIC is loaded, then the virtual ports mapped to it are moved to a physical NIC with less load! This load balancing option is only available for distributed switches. Every 30s the distributed switch checks the physical NIC load and if it exceeds 75% then the virtual port of the VM with highest utilization is moved to a different physical NIC. So you have the advantages of “Route based on originating virtual port” with one of its major disadvantages removed.
In fact, except for “Route based on IP hash” none of the other load balancing mechanisms have an option to utilize more than a single physical NIC bandwidth. And “Route based on IP hash” does not do this entirely as you would expect.
“Route based on IP hash”, as the name suggests, does load balancing based on the IP hash of the virtual machine and the remote end it is communicating with. Based on a hash of these two IP addresses all traffic for the communication between these two IPs is sent through one NIC. So if a virtual machine is communicating with two remote servers, it is quite likely that traffic to one server goes through one physical NIC while traffic to the other goes via another physical NIC – thus allowing the virtual machine to use more bandwidth than that of one physical NIC. However – and this is an often overlooked point – all traffic between the virtual server and one remote server is still constrained by the bandwidth of the physical NIC it happens via. Once traffic is mapped to a particular physical NIC, if more bandwidth is required or the physical NIC is loaded, it is not as though an additional physical NIC is used. This is a catch with “Route based on IP hash” that’s worth remembering.
If you select “Route based on IP hash” as a load balancing option you get two warnings:
- With IP hash load balancing policy, all physical switch ports connected to the active uplinks must be in link aggregation mode.
- IP hash load balancing should be set for all port groups using the same set of uplinks.
What this means is that unlike the other load balancing schemes where there was no additional configuration required on the physical NICs or the switch(es) they connect to, with “Route based on IP hash” we must combine/ bond/ aggregate the physical NICs as one. There’s a reason for this.
In all the other load balancing options the virtual NIC MAC is associated with one physical NIC (and hence one physical port on the physical switch). So incoming traffic for a VM knows which physical port/ physical NIC to go via. But with “Route based on IP hash” there is no such one to one mapping. This causes havoc with the physical switch. Here’s what happens:
- Different outgoing traffic flows choose different physical NICs. With each of these packets the physical switch will keep updating its MAC address table with the port the packet was got from. So for instance, say the two physical NICs are connected to physical switch Port1 and Port2 and the virtual NIC MAC address is VMAC1. When an outgoing traffic packet goes via the first physical NIC, the switch will update its tables to reflect that VMAC1 is connected to Port1. Subsequent traffic flows might continue using the first physical NIC so all is well. Then say a traffic flow uses the second physical NIC. Now the switch will map VMAC1 to Port2; then a traffic flow could use Port1 so the mapping gets changed to Port1, and then Port2, and so on …
- When incoming traffic hits the physical switch for MAC address VMAC1, the switch will look up its tables and decide which port to send traffic on. If the current mapping is Port1 traffic will go out via that; if the current mapping is Port2 traffic will go out via that. The important thing to note is that the incoming traffic flow port chosen is not based on the IP hash mapping – it is purely based on whatever physical port the switch currently has mapped for VMAC1.
- So what’s required is a way of telling the physical switch that the two physical NICs are to be considered as bonded/ aggregated such that traffic from either of those NICs/ ports is to be treated accordingly. And that’s what EtherChannel does. It tells the physical switch that the two ports/ physical NICs are bonded and that it must route incoming traffic to these ports based on an IP hash (which we must tell EtherChannel to use while configuring it).
- EtherChannel also helps with the MAC address table in that now there can be multiple ports mapped to the same MAC address. Thus in the above example there would now be two mappings VMAC1-Port1 and VMAC1-Port2 instead of them over-writing each other!
“Route based on IP hash” is a complicated load balancing option to implement because of EtherChannel. And as I mentioned above, while it does allow a virtual machine to use more bandwidth than a single physical NIC, an individual traffic flow is still limited to the bandwidth of a single physical NIC. Moreover there is more overhead on the host because it has to calculate the physical NIC used for each traffic flow (essentially each packet).
Prior to vCenter 5.1 only static EtherChannel was supported (unless you use a third party virtual switch such as the Cisco Nexus 1000V). Static EtherChannel means you explicitly bond the physical NICs. But from vCenter 5.1 onwards the inbuilt distributed switch supports LACP (Link Aggregation Control Protocol) which is a way of automatically bonding physical NICs. Enable LACP on both the physical switch and distributed switch and the physical NICs will automatically be bonded.
(To enable LACP on the physical NICs go to the uplink portgroup that these physical NICs are connected to and enable LACP).
 That’s it for now!
Update
Came across this blog post which covers pretty much everything I covered above but in much greater detail. A must read!
Posted: June 17th, 2015 | Tags: esxi, vcenter | Category: Virtualization | § Most likely you set the VCSA to regenerate its certificates upon reboot and forgot to uncheck it after the reboot. (It’s under Admin > Certificate Regeneration Enabled). So each time you reboot VCSA gets a new certificate and your browser throws the above error.
Fix is to refresh (Ctrl+F5 in Firefox) the page so the new certificate is fetched and you get a prompt about it.
A year ago I went for VMware training but never got around to using it at work. Now I am finally into it, but I’ve forgotten most of the concepts. And that sucks!
So I am slowly re-learning things as I go along. I am in this weird state where I sort of remember bits and pieces from last year but at the same time I don’t really remember them.
What I have been reading about these past few days (or rather, trying to read these past few days) is networking. The end goal is distributed switches but for now I am starting with the basics. And since I like to blog these things as I go along, here we go.
You have a host. The server that runs ESXi (hypervisor).
This host has physical NICs. Hopefully oodles of them, all connected to your network.
This server runs virtual machines (a.k.a guests). These guests see virtual NICs that don’t really exist except in software, exposed by ESXi.
What you need is for all these virtual NICs to be able to talk to each other (if needed) as well as talk to the outside world (via the physical NICs and they switches they connect to).
You could create one big virtual switch and connect all the physical and virtual NICs to it. (This virtual switch is again something which does not physically exist). All the guests can thus talk to each other (as they are on the same switch) and also talk to the outside world (because the virtual switch is connected to the outside world via whatever it is connected to).
But maybe you don’t want all the virtual NICs to be able to talk to each other. You want little networks in there – a la VLANs – to isolate certain traffic from other. There’s two options here:
- Create separate virtual switches for each network, and assign some virtual NICs to some switches. The physical NICs that connect to these virtual switches will connect to separate physical switches so you are really limited in the number of virtual switches you have by the number of physical NICs you have. Got 2 physical NICs, you can create 2 virtual switches; got 5 physical NICs, you can create 5 virtual switches.
- Create one big virtual switch as before, but use port groups. Port groups are the VMware equivalent of VLANs (well, sort of; they do more than just VLANs). They are a way of grouping the virtual ports on the virtual switch such that only the NICs connected to a particular port group can talk to each other. You can create as many port groups as you want (within limits) and assign all your physical NICs to this virtual switch and use VLANs so the traffic flowing out of this virtual switch to the physical switch is on separate networks. Pretty nice stuff!
(In practice, even if you create separate virtual switches you’d still create a port group on that – essentially grouping all the ports on that switch into one. That’s because port groups are used to also apply policies to the ports in the group. Policies such as security, traffic shaping, and load balancing/ NIC teaming of the underlying physical NICs. Below is a screenshot of the options you have with portgroups).
Now onto standard and distributed switches. In a way both are similar – in that they are both virtual switches – but the difference is that a standard switch exists on & is managed by a host whereas a distributed switch exists on & is managed by vCenter. You create a distributed switch using vCenter and then you go to each host and add its physical NICs to the distributed switch. As with standard switches you create can portgroups in distributed switches and assign VM virtual NICs to these portgroups.
An interesting thing when it comes to migration (obvious but I wasn’t sure about this initially) is that if you have a host with two NICs – one of which is a member of a standard switch and the other of a distributed switch – but both NICs connect to the same physical network (or VLAN), and you have VMs in this host some of which are on the standard switch and others are on the distributed switch, all these VMs can talk to each other through the underlying physical network. Useful when you want to migrate stuff.
I got side tracked at this point with other topics so I’ll conclude this post here for now.
Posted: June 16th, 2015 | Tags: dhcp, powershell, powershell4 | Category: PowerShell, Windows | § Our deployment team needed a few DHCP options set for all our scopes. There was a brickload of these scopes, no way I was going to go to each one of them and right-click add the options! I figured this was one for PowerShell!
Yes, I ended up taking longer with PowerShell coz I didn’t know the DHCP cmdlets but hey (1) now I know! and (2) next time I got to do this I can get it done way faster. And once I get this blog post written I can refer back to it that time.
The team wanted four options set:
- Predefined Option 43 – 010400000000FF
- Custom Option 60 – String – PXEClient
- Predefined Option 66 – 10.x.x.x
- Predefined Option 67 – boot\x86\wdsnbp.com
PowerShell 4 (included in Windows 8.1 and Server 2012 R2) has a DHCP module providing a bunch of DHCP cmdlets.
First things first – I needed to filter out the scopes I had to target. Get-DhcpServerv4Scope is your friend for that. It returns an array of scope objects – filter these the usual way. For example:
|
|
Get-DhcpServerv4Scope -ComputerName MyDHCPServer | ?{ $_.Name -notmatch "Voice" -and $_.Name -notmatch "Wireless" } |
Now, notice that one of the options to be added is a custom one. Meaning it doesn’t exist by default. Via GUI you would add it by right clicking on “IPv4” and selecting “Set Predefined Options” then adding the option definition. But I am doing the whole thing via PowerShell so here’s what I did:
|
|
Add-DhcpServerv4OptionDefinition -ComputerName MyDHCPServer -Name PXEClient -Description "PXE Support" -OptionId 060 -Type String |
To add an option the Set-DhcpServerv4OptionValue is your friend. For example:
|
|
Set-DhcpServerv4OptionValue -ComputerName MyDHCPServer -ScopeId "MyScope" -OptionId 060 -Value "PXEClient" |
I had a bit of trouble with option 43 because it has a vendor defined format and I couldn’t input the value as given. From the help pages though I learnt that I have to give it in chunks of hex. Like thus:
|
|
Set-DhcpServerv4OptionValue -ComputerName MyDHCPServer -ScopeId "MyScope" -OptionId 043 -Value 0x01,0x04,0x00,0x00,0x00,0x00,0xFF |
Wrapping it all up, here’s what I did (once I added the new definition):
|
|
Get-DhcpServerv4Scope -ComputerName MyDHCPServer | ?{ $_.Name -notmatch "Voice" -and $_.Name -notmatch "Wireless" } | %{ $Scope = $_.ScopeId; Write-Host -ForegroundColor Yellow "Working on $Scope" Set-DhcpServerv4OptionValue -ComputerName MyDHCPServer -ScopeId $Scope -OptionId 043 -Value 0x01,0x04,0x00,0x00,0x00,0x00,0xFF Set-DhcpServerv4OptionValue -ComputerName MyDHCPServer -ScopeId $Scope -OptionId 060 -Value "PXEClient" Set-DhcpServerv4OptionValue -ComputerName MyDHCPServer -ScopeId $Scope -OptionId 066 -Value "10.x.x.x" Set-DhcpServerv4OptionValue -ComputerName MyDHCPServer -ScopeId $Scope -OptionId 067 -Value "boot\x86\wdsnbp.com" } |
And that’s it!
Posted: June 7th, 2015 | Tags: vmware, workstation | Category: Virtualization, Windows | § Came across this problem today and couldn’t find any Google hits that helped me. Finally hit upon a solution.
VMware tools requires the guest to have a CD drive. In my case the physical host doesn’t have a CD drive, and I had no need to mount any CDs in the guest, so while creating the guest I removed the CD drive. No CD drive => no place for VMware to insert the CD. But rather than complain about it, it simply grays out the option.
So that’s it. Enable the CD drive and you will be able to install VMware tools! Hope this helps.
|