I thought perhaps we had removed this functionality in vSphere 5.1, but it is still there, just very buried. You have to go into the properties of the Host, Actions/All vCenter Actions/ Add Networking.. (see below)
Here is the published document on how to do it.
This is a guide for deploying vCloud in a LAB environment, these settings are not the most secure or performant, but this should get you up and running with vCloud 5.1 so you can test and learn it. The easiest way is with the appliance, you don’t need to use a MS SQL DB, but occasionally I need to crack open the DB and I am the most comfortable with that technology.
1) Configure the database server.
A database server configured with 16GB of memory, 100GB storage, and 4 CPUs should be adequate for most vCloud Director clusters. (this is for production level quality)
2) Specify Mixed Mode authentication during SQL Server setup.
Windows Authentication is not supported when using SQL Server with vCloud Director.
3) Create the database instance.
The following script creates the database and log files, specifying the proper collation sequence.
USE [master]
GO
CREATE DATABASE [vcloud] ON PRIMARY
(NAME = N'vcloud', FILENAME = N'C:\vcloud.mdf', SIZE = 100MB, FILEGROWTH = 10% )
LOG ON
(NAME = N'vcdb_log', FILENAME = N'C:\vcloud.ldf', SIZE = 1MB, FILEGROWTH = 10%)
COLLATE Latin1_General_CS_AS
GO
The values shown for SIZE are suggestions. You might need to use larger values.
4) Set the transaction isolation level.
The following script sets the database isolation level to READ_COMMITTED_SNAPSHOT.
USE [vcloud]
GO
ALTER DATABASE [vcloud] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [vcloud] SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [vcloud] SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAIT;
ALTER DATABASE [vcloud] SET MULTI_USER;
GO
For more about transaction isolation, see http://msdn.microsoft.com/en-us/library/ms173763.aspx.
5) Create the vCloud Director database user account.
The following script creates database user name vcloud with password vcloudpass.
USE [vcloud]
GO
CREATE LOGIN [vcloud] WITH PASSWORD = 'vcloudpass', DEFAULT_DATABASE =[vcloud],
DEFAULT_LANGUAGE =[us_english], CHECK_POLICY=OFF
GO
CREATE USER [vcloud] for LOGIN [vcloud]
GO
6) Assign permissions to the vCloud Director database user account.
The following script assigns the db_owner role to the database user created in Step 5.
USE [vcloud]
GO
sp_addrolemember [db_owner], [vcloud]
GO
Good Links:
If your like me, you always want to know what changed in the latest version, so here is a list of links to all the new PDF’s
vSphere 5.1 (Marketing Overview)
VMware vCloud Suite (Marketing Overview)
VMware vCenter Configuration Manager 5.5.1
VMware vCloud® Networking and Security Overview
I’m sure there are more, if you know of any more, let me know and I’ll add it.
If you see an Error such as:
Unable to deploy virtual machines in resource pool "LBM4".
Even though the vDS (VMware Distributed Switch) maximum went up from 4,096 to 20,000 in vSphere 4.1, the vDS won’t be able to go over 8192 unless you manually modify the vDS. You would have already upgraded the vDS from a 4.0 to a 4.1 to have a number this high.
Here is the VMware KB that tells you how to manually increase the size of your vDS
Greg Robertson recently did a VCDX Spotlight paper about me, Thanks for the mention!
http://thesaffageek.co.uk/2012/07/31/vcdx-spotlight-brian-smith/
My vCenter is running Windows 2008R2. I tried Running the Microsoft sysinternals tools to find out which host is locking out this user and it kept pointing me to vCenter. Of course to me it didn’t make any sense why vCenter would be locking this user out every 60 minutes. I also checked the standard stuff, no services running as the user, nothing under the “Credential Manager” on vCenter. There are also several VMware KB’s for dealing with the issue, they want you to use TCPVIEW, and some other tools, but none of them helped me on this one.
I’ll start my troubleshooting steps below after the normal sysInternals AD “find out which machine is locking the user out” steps.
1) I logged into vCenter and opened “Server_Manager/Diagnostics/Event_Viewer/Windows Logs/Security”
I saw the following 3 Audit Failures happening ever 60:16 seconds (not sure if that interval is important to the issue, but it gave me an ability to predict the next occurrence). Since the last event was at 9:31:30am, I can predict the next occurrence at 10:31:46am. You can see the “Account for Which Logon Failed:” “Account Name:” is the usersloginname, this is key information we’ll use later.
2) Logging into vCenter I see this under “Tasks & Events”, the timestamp is an exact match to the Event Log Event above. I see nothing that correlates to this timestamp under vCenter Tasks, which makes me think this is being initiated from an external (to vCenter Service) source.
3) Before I realized this was happening every 60:16 I grabbed a large packet capture on my vCenter Server. Now that I could predict the exact second this would happen again, I decided to capture a smaller time window with a script.
I setup a single scheduled wireshark dumpcap by utilizing Windows Task Scheduler.
The dumpcap –a parameter specifies a 4 second duration of packet capture, the –w specifies what to name the output file, lo.pcap in this example. I dumped the files into a directory called c:\output . I didn’t use the default location because when I ran the script manually (from the command line to test) I received access denied, and since I’m too lazy to troubleshoot it, but I’m pretty security minded, I setup a temp directory called output that I gave everyone full control to. I setup the schedule to start the capture 2 seconds before the planned event and it did successfully gather the data I needed.
4) Now to analyze what I captured. Because the user swore that he was not manually doing anything to the systems, I though if I did a search within the file for the users name, it may give me some good data. I did a Wireshark Filter of tcp contains usersloginname. What I saw was 4 packets containing his name, the first going from vCenter to DC, then the response from DC to vCenter, then the same repeated.
By itself, this isn’t overall useful, but IF this problem wasn’t coming FROM virtual center (or a locally installed app), it must be coming over the network. And if vCenter is talking to AD, most likely something is happening right before this event to cause it. You see this communication started with packet 316 @ 2.74 seconds after I began capturing. This is a good correlation since I started the capture 2 seconds early, I was right on time. I was also able to verify that the issue had happened again right on time in the Windows Event log. So what is happening on vCenter’s network RIGHT BEFORE packet 316? I removed my filter and scrolled up a bit, most of the traffic was from vShield Manager, the SQL DB, misc vCloud items, but one IP stood out, it was not from my vCloud farm of servers. This Mystery IP seemed like my most likely candidate. I also did a ping –a 10.x.x.x hoping for a strike on reverse DNS to get a hostname without luck.
To confirm my suspicions that the mystery IP was somehow triggering the lockouts, I switched to analyzing my older bigger packet capture and did a Filter by ip.src==10.x.x.x (the mystery IP). This came up with traffic starting at packet 67701 @ 305.4 seconds into the capture. Now if my hypothesis is correct and this mystery IP is the culprit, then there should be some talk back and forth with my DC immediately following. I did another search in this old capture with tcp contains usersloginname and found this traffic on packet 67714 @ 305.5 seconds into the capture!!! This means the Mystery IP was contacting vCenter, and then locking out my users AD account, but since it was vCenter talking directly to AD, vCenter was getting credit for locking the user out.
5) I located the Mystery IP VM, it was a VMware vCenter Operations VM using the users old password, we fixed it and then waited until 60:16 more seconds had passed, no new logs in vCenter, no new failures in AD, the issue is resolved!
Trying to delete a folder (with files in it) on my server today, for whatever reason I could not enter, delete, or take ownership of this folder. I tried the UI, as well as the takeown command, both returned an access denied trying to take ownership. Because I am a full administrator, my suspicion is that there is an open file. Because this is a file server with hundreds of open files and folders, I could not easily identify the connection to close. I rebooted the server, and without issuing any more commands my access to the files/folders had returned. GO MICROSOFT!..
First, some good links for documents about this:
The Problem:
Upon building a new HP chassis full of blades, hoping to connect my new blades to storage, I was build zoning rules connecting them to our EMC VNX, Inside of Cisco Fabric Manager I did not see the HP blades listed so that I could build zoning rules. The other suspicious item was that inside of HP Virtual Connect Manager, inside of the “SAN Fabrics” tab, I was giving a warning for a status.
The Setup:
I had setup this up in a fully meshed fiber with NPIV enabled everywhere. 1 HP Chassis, two Flex 10 modules, two Cisco MDS switches, and one EMC VNX. My flex 10 modules were each connected directly to both of the Cisco MDS Switches. Each of the Cisco MDS’s were connected directly to each of the SP’s on the EMC VNX (fully meshed).
The Solution:
I worked on this for some time, then after changing the connections on the Flex 10’s to both go directly to the SAME Cisco MDS switch (removing the mesh from the Compute side), the HP Virtual Connect finally showed happy, and the Cisco MDS began to see all the HP Blades and I was able to connect storage. So what did I do wrong originally? I am sure there is a great reason, but what part of Fiber Channel for Dummies did I miss?
Single initiator with a single target is the most efficient approach to zoning
Just jotting down some links
http://routerjockey.com/2011/12/23/mds-fiber-channel-switching-basics-for-network-engineers/
The EMC Whitepaper on VNX Best Practices h8268_VNX_Block_best_practices.pdf is the way to go, I used version 31.5 as it is the most current one available.
Storage Pools vs Raid Groups vs MetaLuns
From an design perspective, MetaLuns were basically replaced by Storage Pools, Storage pools allow for the large stripping across many drives that MetaLuns offers, but with a lot less complexity. MetaLuns are now generally used to combined/expand a traditional LUN. Raid Groups have a maximum size of 16 disks, so for larger strips this isn’t a viable option. For situations where guaranteed performance isn’t critical, go with Storage Pools, use Raid Groups if you need deterministic (guaranteed) performance. The reason behind this is that you are probably going to create multiple LUNs out of your storage pool, so this could lead to one busy LUN affecting the others.
Raid Level Selection
Assuming your going with a Storage Pool, your options are Raid 5, 6, or 1/0. If you are using large drives (over 1TB) then Raid 5 is not a good choices because of long rebuild times, Raid 6 is almost certainly the way to go. Always use suggested drive numbers in the pools, Raid 5 is 5 disks, or a number that evenly divides by 5, Raid 6 & Raid 1/0 is 8 disks or a number that evenly divides by 8. If you use less than the recommended you will be wasting space.
How Big of a Storage Pool do I start with?
Create a homogeneous storage pool with the largest number of practical drives. Pools are designed for ease-of-use. The pool dialog algorithmically implements many Best Practices. It is better to start with a large pool, as you add disks to the pool, it does not (currently) restripe the disks, and therefore if you only added 5 disks to an existing 50 disk pool, the new LUNS would have much lower performance. The smallest practical pool is 20 drives (four R5 raid groups). It is recommended practice to segregate the storage system’s pool-based LUNs into two or more pools when availability or performance may benefit from separation.
I am only covering a small portion of what you need to know.
When dealing with storage, there are thousands of options, homogeneous drives vs. heterogeneous, Thick vs. Thin Provisioning, Fast VP Pools, Drive Speeds, Fast Cache and Flash Drives, Storage Tiering, the whitepaper above does a great of of detailing all of that, I won’t try to improve on what EMC has said.
DISCLAIMER: I am not an TFS expert, at all.
Besides the normal of modifying the password in service manger, I found a few other things.
Hopefully it’s a VM so you can take a snapshot before you do anything.
Much of this data I got from “How to change the Service Account or Password for Team Foundation Server”
1) SQL reporting services will need to get updated, I believe you can do it through the TFSAdminUtil with the /ra option, or you can run through the Reporting Services Configuration again.
2) You may need to modify service account passwords on IIS Application Pools, such as the “Microsoft Team Foundation Server Application Pool” under Identity update the password, I had to update 3 of my pools.
Good Luck!
Recently upon pushing patches to our ESX 4.1 and ESXi 4.1 hosts, I was unable to re-enable 2 of our 23 blades. We had one of each flavor, ESX and ESXi. After much frustration I found our KB 1026364, which says:
===================================================
To resolve this issue, restart the Lab Manager VSLA backend service.
To restart the VSLA backend service on Lab Manager:
When you restart the Lab Manager VSLA service , the DVS becomes unavailable. When the service starts again, Lab Manager gets the latest status from the vCenter Server.
After the Lab Manager VSLA service starts again, you can start repairing the ESX hosts or try re-enable host-spanning within Lab Manager.
===================================================
After restarting this service, I was able to repair our Hosts without issue.
For some reason the UI makes it difficult to find this option. It’s not hard to find when you remember where to look. Go into Home/Inventory/Networking, choose your DvS you want to remove the host from, then choose the “Hosts” tab, then click the host you want to remove and choose “Remove from vSphere Distributed Switch…”
My application was accepted, I get to defend in Toronto! My paper is based on vSphere 5.0 Technology, but this is a VCDX4 defense, so I have to be ready for questions on either technology. I’ve already taken VCAP5-DCD beta and will take the VCAP5-DCA beta soon, Not sure what VCDX5 will look like, but hopefully I will pass and meet the pre-requisites for the upgrade immediately!
For my testing lab, I get tired of replacing the SSL self signed cert every 4 months, this should make it last for 9999 days, or 27 years. It also assumes you installed Java jre version 1.6.0_29 . Obviously you may need to modify this to fit your environment, using a self signed cert is bad for security, plus as I’m doing below using the same cert for both http and consoleproxy is also bad for security. And using a password of password isn’t something I do even in my lab.
Step 1: Create New Certs
./usr/java/jre1.6.0_29/bin/keytool –keystore /opt/vmware/certificates.ks -storetype JCEKS -storepass password -validity 9999 -genkey -keyalg RSA -alias http
./usr/java/jre1.6.0_29/bin/keytool -keystore /opt/vmware/certificates.ks -storetype JCEKS -storepass password -validity 9999 -genkey -keyalg RSA -alias consoleproxy
Step 2: Stop vCloud Service
service vmware-vcd stop
Step 3: Go through configure wizard to replace certificates
./opt/vmware/vcloud-director/bin/configure
Step 4: Service should restart at end of the configure command, so there really is no step 4 other than to bring up your vCloud web page and examine the certificate to see your new extended certificate.
I always have to look this up, so I’m blogging the cfgmaker command I like to use for windows.
perl cfgmaker community@10.10.10.10 -–global "WorkDir: c:\MRTG\MRTGDATA" --global "options[_]: growright,bits" --output FW1.cfg
Initially only the last 24 will show bits, but as data grows the other charts converts from bytes to bits.
If you use a Scheduled Tasks
Run: C:\Perl64\bin\perl.exe mrtg FW1.cfg
Start in: C:\MRTG\mrtg-2.xx.x\bin
Advanced settings to run ever 5 minutes for 23 hours and 55 minutes
If you already have MRTG setup and working and you want to move from bytes to bits, you can always just modify your .cfg file and remove the comment marks on the second line.
# to get bits instead of bytes and graphs growing to the right
# Options[_]: growright, bits
So it should look like
# to get bits instead of bytes and graphs growing to the right
Options[_]: growright, bits
1) If you don’t have the commands on your device you expect, update your junos.
2) If you login as root over the serial port, type “cli” to get out of linux mode and into junos.
3) To reboot type “request system reboot”
4) Transparent mode on Junos is painful. You need to configure a management IP on a irb interface and a “bridge-domains” to make it all work.
5) When in configure mode, type “run ping 8.8.8.8” to execute commands
6) Type show | display set if you want your commands piped into a command line friendly format.
7) When in configure mode, type “sho” to show the config, or “sho interfaces” to display only that sections information.
This can happen due to the default mechanic for slot size calculation in VMware HA. The default slot size is calculated based on the size of your largest VM in the cluster, and in this example I’m talking about memory because that is generally the first HA bottleneck, not CPU. If your like me and you have a single large 8GB VM and a bunch of small 256MB VM’s, your cluster admission policy will stop deployments even when ESX host memory usage is below 50%. To increase your slot size, which you can see here:
You can see the Slot size is 8332 MB, I’d prefer it was down around 1024 to be closer to reality.
To make the change, go into the Advanced Options of HA
And set das.slotmeminmb to a value of 1024
Now when you go back and look at the current slot allocation “Advanced Runtime Info” you see that you have gone from 112 slots to 966
HA should again work as expected, but you should know that even though this will allow you to essentially overcommit your HA settings and HA working properly for your large VM in a disaster is no longer guaranteed due to the custom settings.
Here is the text from the vSphere Availability Guide
Slot Size Calculation is comprised of two components, CPU and memory.
VMware HA calculates the CPU component by obtaining the CPU reservation of each powered-on virtual machine and selecting the largest value. If you have not specified a CPU reservation for a virtual machine, it is assigned a default value of 256 MHz. You can change this value by using the das.vmcpuminmhz advanced attribute.)
VMware HA calculates the memory component by obtaining the memory reservation, plus memory overhead, of each powered-on virtual machine and selecting the largest value. There is no default value for the memory reservation.
If your cluster contains any virtual machines that have much larger reservations than the others, they will distort slot size calculation. To avoid this, you can specify an upper bound for the CPU or memory component of the slot size by using the das.slotcpuinmhz or das.slotmeminmb advanced attributes, respectively.
I am trying to use host profiles in a full NFS vCenter, no block level storage other than the local SSD disks for the ESXi 5 servers to boot from and some various emulated CDROM’s attached to some of the hosts. Because I don’t really care about the uniformity of my local storage I just want to ignore these errors and get a Green “Compliant” result for my cluster so I can fix the important issues. I tried going into Edit Profile and removing a lot of data from under Storage Configuration/PSA & NMP & iSCSI, but this led to more errors, such as below:
Failures Against Host Profile
Host state doesn’t match specification: device mpx.vmhba32:xx:xx:xx Path Selection Policy needs to be set to default for claiming SATP
Host state doesn’t match specification: device mpx.vmhba32:xx:xx:xx needs to be reset
To resolve the issue, you need to right click on the Actual storage profile under “Host Profiles” on the left hand side of the screen and choose “Enable/Disable Profile Configuration…”
Then unselect items from here such as PSA device configuration and whatever else causing you unnecessary grief.
After hitting OK, rescan your hosts and you should finally get your Green Light!
Credits go to the knowledge base and to Kevin Space.
When using ESX on a server it is good to have a lot of network cards, especially if using vCD (vCloud) . This is a follow up to my previous post about dividing a single Dell NIC into multiple nics (partitioning) http://bsmith9999.blogspot.com/2012/01/divide-single-network-into-multiple.html.
Before you begin, you need to design your setup, for my example I want 9 VLAN’s.
1010 – mgmt (the vCenter & vCM & vCell, etc…)
1020 – guests (external facing)
1030 – vMotion
1040 – NFS (not using FC)
4010 – vcdni1
4020 – vcdni2
4030 – vcdni3
4040 – vcdni4
4050 – vcdni5
Step 1 Login and look around.
Login to Dell OpenManage, Open Switching/VLAN/ choose “VLAN Membership”. Out of the box you will only see the default VLAN 1. Assuming you are using multiple chassis with clusters that will span these chassis like I am, you will need Tagging to flow through your core switches into these. On this default VLAN, you will see the “Lags” at the bottom left hand side, the Current is set to “F” which is forbidden, meaning this default VLAN will not pass through the trunk into the core switch and cross chassis, for the default VLAN 1, this is good, for the other VLANs, we will change it.
Step 2, Add VLAN’s.
Under “VLAN Membership”, click “Add” near the top, type in your VLAN ID and name, then click Apply. Repeat step to create all of your VLAN’s.
Step 3, Change VLAN Lag type to Tagged.
Click on Detail after you have created your VLANs. Choose your VLAN under “Show VLAN”, Under Lags, change the “Static” box from “F” to “T” by clicking it a couple times. Then click apply, repeat for all new VLAN’s you’ve created that you want to have flow through your core network.
Step 4, Change VLAN Port Settings to “Trunk”
**Warning** before you do this, you must have iDRAC console access to your blade or you may lose connectivity to it****
Click on “Port Settings” which is just below “VLAN Membership”. You will now see the port Detail page. For each Port Te1/0/1 through Te1/0/16 change the Port VLAN Mode from Access to Trunk, then Click Apply. This will allow the blades to pass multiple VLAN networks to and from themselves. Repeat this step 16 times.
Step 5, Modify ESXi to accommodate the new VLANs
Open a iDRAC session to your blade(s). F2 to Login, Choose “Configure Management Network”, Choose “VLAN (optional)”, then type in your VLAN ID
Hit Enter, then ESC. It will ask if you want to Apply changes and restart mangement network? Say (Y)es.
NOTE ***In the dell Switch UI, make SURE to click the little floppy disk picture in the upper right to Save your work when your done or you’ll get to repeat it after your next power outage like I did***
You should be done, repeat these steps to get all your blades online and using VLAN’s.
I was looking for the Dell equivolent to HP Flex-10’s FlexFabric Adapter. In dell speak this is called “independent NIC partitioning“ or just “NIC partitioning” or NPAR.
First let me give you some background into my new system. It consists of M1000E blade cabinets, M710HD Blade Servers with Broadcom 57712-k 10GbE 2P nics, and PowerConnect M8024-k Cabinet Switches. My goal is to turn two 10GB NIC’s into four NIC’s made up of two 1GB NIC’s and two 9GB NIC’s
Before you connect to iDRAC, If you want to use your mouse, you must set the Mouse Mode to USC\Diags (also don’t do this through remote desktop) Make this change from the iDRAC GUI. I always change the media to attach or I won’t be able to install ESX later.
Apply the setting, make sure to wait for the confirmation, otherwise it didn’t happen.
To make the actual NIC Partitioning changes, you must use the ""Dell Unified Server Configurator”, which being the noob I am, I tried to find for download, but apparently you access it during the blade server boot by pressing F10 to access the UEFI (System Services")
Then you will see something like this when it boots to UEFI
Select “Hardware Configuration”, you can do that with your mouse or the arrows on the keyboard.
Then choose tab over to HII Advanced Configuration
You will need to do the following twice, once per nic.
Then Device Configuration Menu
Change Disabled to “Enabled”
After you hit back, you will see a new options, “NIC Partitioning Configuration Menu”, select it now.
Then Select “Global Bandwidth Allocation Menu”
Tab doesn’t work on the next page, some person decided to make tab only go back and forth between the top row and the back button. However, luckily you can use your UP and Down arrows to move between rows.
Unfortunately it doesn’t appear you can Partition a NIC into less than 4, I only want 2, so using that methodology I will create one with 90 and one with 10, the other two I will give 1 to because I can’t give them 0. You are allowed to over allocate the Maximum Bandwidth. 1%=100MB, so the find 2 NIC’s I will create will be 100MB adapters I won’t end up using.
Type in your number, then hit enter, then choose the next row.
HINT: if using the mouse and it gets a bit squirrly, Play with “ALT-C” and toggle Hide Local Cursor on and off to improve mouse response.
Choose Back, then Back, then Finish, It will prompt you to Save, of course say yes, then repeat for your next adapter.
After you have done both NIC’s, Choose back, then Exit and Reboot.
Here comes the really fun part. After installing and booting into ESX, it appears that only the 2nd NIC took the partitioning command as the first one is still at 25/25/25/25 and the second one is 10/90/1/1 correctly. I made the changes again for the first NIC and rebooted again, and it works. I verified this over 3 different new blades, if anyone knows the solution, I’d love to hear it.
Credits, I found the information for this article HERE
http://www.dell.com/downloads/global/products/pwcnt/en/broadcom-npar-users-manual.pdf
http://www.dell.com/downloads/global/products/pedge/en/Dell-Broadcom-NPAR-White-Paper.pdf
http://www.dell.com/us/enterprise/p/broadcom-netxtremeii-57712-k/pd
