esxcli Mindmapped

Well like the title states: esxcli mindmapped. I used a application called xmind and then over the last week I did a mind map of the esxcli commands. The result was that I have learned a lot of the esxcli structure and the power on what one can do with it.

Here is some of the commands that I found interesting:

  1. esxcli system version get
  2. esxcli system welcomemsg set -m
  3. esxcli storage filesystem list
  4. esxcli storage filesystem rescan
  5. esxcli network firewall set –enable true –default-action DROP

I created a PDF for complete list of commands and their options. you can download it here.

Added : People have asked me for the source….esxcli.zip.

Posted in VMware | 7 Comments

Oracle Support on VMware just got BETTER !

In the last 2 weeks I had to clarify 3 times the Oracle support statement to clients that have Oracle. But the GOOD news is that VMware have done something about this to help clients running Oracle on VMware. I dont know when this was changed but you can read below what VMware is doing.

This is VMware’s Support Policy on Oracle:

Summary

VMware’s business mission is to reduce complexity, lower costs, and improve information technology service delivery for customers. This extended support perform delivers this, by driving resolution of customer technology issues that involve multiple product venders. VMware is committed to its customers’ success and supports their choice to run Oracle software in modern, virtualized environments.

Expanded Support

VMware is committed to the success of its customers in deploying simplified, cost-effective, and better information technology services. To further this, we recently announced expanded support for Oracle Database technical issues with
the VMware vSphere platform. This expanded technical support is driven by our VMware customers’ choice to deploy increasing amounts of their Oracle Database software with VMware products.
This expanded support is targeted at Oracle Database usage “above and below”  vSphere, where the Oracle database is:
  1. used as a data store for VMware products
  2. run within a virtual machine on vSphere/ESX
VMware Oracle Support provides customers the following new advantages as part of the existing Support and Subscription contract at no additional charge:
  1. Total ownership of Oracle Database technical issues reported to VMware Support
  2. Access to a team of Oracle DBA resources within VMware Support to troubleshoot related to Oracle Databases used as a data store or run within a VM
  3. Performance tuning and best practices related to Oracle Database used as a data store or run within a VM
  4. Faster resolution of technical issues in VMware environments via a TSANet collaborative support arrangement between VMware Support and Oracle Support.

Total Ownership

VMware Support will accept accountability for any Oracle-related issue reported by a customer. By being accountable, VMware Support will drive the issue to resolution regardless of which vendor (VMware, Oracle, or others) is responsible for the resolution. In most cases, reported issues can be resolved
via configuration changes, bug fixes, or feature enhancements by one of the involved vendors.
In the rare situation that another vender is unable or unwilling to provide a satisfactory technical resolution, VMware Support will immediately notify the customer, assist in escalation and explore other potential technical workarounds with the customer.
VMware will also assist its customers with technical issues for other Oracle software products, besides the Oracle Database and provide similar escalation assistance if needed.
Besides technical assistance, VMware Support will advocate on the customer’s behalf to:
  1. Provide any relevant evidence that virtualization does not play a part in the Oracle product technical problem
  2. Engage Oracle Support in resolving the customer’s technical issue, escalating management attention as appropriate

 

Posted in VMware | Leave a comment

“Manage Port Goups” – so cool !!

I am sure this option was not in v4..maybe I am wrong. But if you had like 100 Port Groups and u had to change a setting like “Forged Transmits” to Reject, you either had to script it or make the change to all Port Groups one at a time.

With v5 there is an option to Right click vDS and select “Manage Port Groups” . Once you have done this you can select what vDS Policies you want to change. In my case it want to change Security and Monitoring:

Select Next and then you are asked on which Port Groups you want to make changes. My case all of them:

Next is to select which Policies you want to change :

When you are done with this, you will see tasks for each change:

 

 

 

 

 

 

 

 

I know this was a pain for me to do in the past…but now it is really easy to get done.

Posted in VMware | 1 Comment

Chargeback base costing : tools and advice

I have been helping a few ISP’s to get to a base cost’s calculated for VM that is in a hosting environment. But as one learn from one ISP to the other, cost do change and the most important thing is also the way Resources can be sold. Some ISP’s sell on a “Pay as you Go” bases and some sell on a “Reserved Based”. The most importing thing to remember always is not to make it complicated. Keep the costing simple and for people to understand. The more complicated one makes it….the more issues there will be with the billing.

There is some calculators one can use to get to an estimated base cost. I use two of them for most of my calculations. The one is a XLS spreadsheet that VMware have created and the other is the Base Rate Calculator that is included in the Chargeback Product (Top right hand side ->Tools -> Base Rate Calculator)

 

 

 

 

 

 

 

 

 

 

 

Some of the basic cost models used is Pay as u Go or Fixed costs. Let look at the Pay as u go model first.

Pay as u go is often use when u have dynamically resources that is added and removed. This can be a typical on a Development as a Service. You can set a fixed cost for vCPU, Gb memory, Network usage and Gb Storage usage. In addition you can also charge for VM creations and deletions.

Reservation based usually done at a Resource Pool level. Thus a client will request 10Ghz CPU, 20Gb Memory and some disk. The CPU and Memory is set as a reserved value on the Resource Pool. The client is charged for this reservation whether he uses the resource or not. From a design perspective this reservations should be carefully planned and monitored.  In addition when u deploy a cluster, you know how much resources u have and know how much you can sell and have left to sell. Also keep HA sizing into consideration.

Fixed Costs is widely used when u want to charge for monthly charges. Some examples is as follow :

  • Fixed Network costs (Firewall service, Port Charges, Line charges)
  • OS Costs (Windows OS is needed)
  • Application Charges (SQL, Custome apps)
  • Infrastructure Services (Backups, AV, Monitoring)

Other costs that need to be added to get to a base cost is as follow:

  • Power consumption
  • VSPP Licensing
  • Management Operating Systems and Applications (vCenter and SQL Server OS)
  • Monitoring Applications
  • Floor space

The bottom line is to keep the costing as simple and understandable. The more complex one makes the costing, the more difficult it will be to sell and bill.

(Note that this is based on my experience on implementing Chargeback at clients in South Africa)

Posted in VMware | Leave a comment

vSphere Replication : Adding a new VMDK to an existing replicated VM

With SRM 5 we now have the ability to do VM replication over a network between 2 or more sites. This is cool as you can have Storage Vendor X on site A and Storage Vendor Y on site B and still have VM replicated with a certain RPO (Min 15min). I did a demo today for a client and one of the questions that came up was: What happens when we add a new VMDK to the VM that is being replicated ? Good question !!

This can be done and one have to note that u will need to do a re-config of the vSphere Replication for that VM to include the new VMDK that was added. Lets look at how this is done. Below we can see that the VM (Dev01-Server) is protected and only have one VMDK being replicated.

 After I added the new VMDK, the replication of this VM will go into a “Pause” state until we have added the new disk for replication. 

 

Now you can Right Click on the VM and select vSphere Replication. Once you have done this you will notice that there is another Hard Disk 2 (in my case it is the second disk). Select the Datastore at the remote site you want to replicate to. You also have the option not to set this new disk to replicate. The default is to Enable Replication.

 Form here on the new VMDK is configured for replication and a full replication is done for only the new VMDK.

Something to remember: if you create a second VMDK on a different Datastore, the name of the VMDK will be the same as the first VMDK. Thus when you specifiy the same datatore to replicate to on your DRP site you will get an error that the file already exist. You will need to specify a differnt datastore to replicate to.

 

Posted in VMware | Leave a comment

vDS Netflow explained

In this article we will be looking at how to configure NetFlow and how the traffic is send from the ESXi hosts to the NetFlow collector.

First lets understand the configuration files and how the traffic is send from the ESXi host. When NetFlow is configured on the vDS the file /etc/vmware/dvsdata.db is updated op each host that belongs to the vDS switch with the relevant NetFlow configuration. In addition the vDS port data is also updated that is located on the datastore of the VM’s vmx location under a folder .dvsData. Each ESXi host will send the NetFlow data to the NetFlow collector, thus the vCenter does not send any data to the collector.

When data is send/received thru the vPort a new NetFlow record is created. This record has a lifespan based on the “active flow export timeout” and “Idle flow timeout”.  This works as follow:

  1. New record is created and data is collected actively for 60sec. After 60sec the record is exported (Based on “Active flow export timeout).
  2. New record is created and after 20sec no more data is recorded. At 35sec (20sec + 15sec(Idle flow export timeout)) the record is exported.
  3. New record is created and for 15sec no data is record and thus the record will be exported .
  4. A new record will only be created once there is data flow again.

When setting the sample rate to 2, the record is only updated every 2 sec with data at that 2sec interval (not data collected over that 2 sec).

Next is to understand what the settings is that enabled NetFlow on the vDS.

Collector IP Address : This is the NetFlow Collector IP address that each ESXi host will send the NetFlow data to.

Collector Port : This is the Port address the that the NetFlow collector listens on for traffic for the ESXi hosts.

vDS IP address  : If you don’t enter an IP address in here you will see each ESXi host as a device in the NetFlow collector. If you do enter an IP address then the NetFlow Data send form each ESXi host will have the same originate addresses and you will only see one device n your NetFlow Collector with this IP address.

Process internal flows only : If this option is selected then only data between VM’s on the same host will be exported to the collector.

Once you have configured the above you need to enable NetFlow on the Port Groups that NetFlow traffic is needed. Do this on the Port Group settings on Monitor and then Enable the NetFlow Status (Disabled by default).

Once you have done this you should see data in your NetFlow Application immediately.

I want to thank Hua from our Networking R&D team for his help on this article.

Posted in VMware | 2 Comments

DVS Port Group consideration

I was involved in a design that had 2 sites, active/active with SRM failover between each site. Thus each site can failover to the other site. What make the networking easy was that we had strech vlans’s betwen the sites.

This is were it got interesting. As we only had 10 vlans at the time we configured each DVS switch at each site with 256 ports per portgroup as we used a class c mask. Thus in a vlan we could not have more than 256 ip’s/vm’s. Also when we failed over we would have enought ports on the other site’s DVS switch to startup the failed over VM’s….all good.

Then we had to increase the numer of vlans due to a migration project and this is were it got interesting…as we got to vlan 33 we ran out of ports on the DVS switch…max ports is 8096. Thus with 32 ports groups of 256 ports we hit the max.

We relooked the requirements of the new port groups only to find out that we do not have more than 30 vm’s per vlan per site…so updated the design and made the changes to the port groups to have max 64 ports per port group.

Lesson learned here was to not always just use the design defaults but to relook, adjust and justify your design for new changes were needed.

Posted in VMware | Leave a comment