Comments (0) 
The new version 4.1 of vShield Manager and vShield Zone
By admin, April 11, 2011 4:12 pm
- The good thing, it’s FREE with ESX Advance/Enterprise/Enterprise Plus version.
- Yes, it’s simply a transparent firewall utilizing VMsafe API, so there is no need to change the default public IP on VMs, vShield Zone (ie, firewall) comes with limited functions comparing to real stuff like Netscreen, but it does get the job done by limiting ports, source, destination, direction on L2/L3 and L4 layer, one extra nice thing is vShield Zone comes with a bunch of dynamic ports based application such as FTP, DNS, etc.
- In version 4.1, there is no more separate OVF for vShield agent, it’s been renamed to vShield Zone, and deployment of vShield Zone is simply by clicking the Install link on the menu, it’s so much simpler to install a firewall on each ESX host with v4.1, no need to create any template for vShield Zone like in the old days as well. In additional, A new vSwitch, called vmservice-vswitch, is also created. It has no physical NICs assigned to it and has a VMkernel interface with a 169. IP address. This vSwitch should not be modified. It’s used exclusively by the Zones firewall VM, which has two vNICs connected to it. Through the vNICs , the Zones VM communicates with the LKM in the VMkernel. One vNIC is used forcontrol, and the other is for data path communication.
- The original version of vShield operated in bridged mode and sat inline between vSwitches so that all traffic to the protected zones passed through it. The new method of monitoring traffic at the vNIC, instead of the vSwitch, eliminates the vSwitch reconfiguration that previously occurred, and it provides better protection. In bridged mode, VMs in a protected zone had no protection from other VMs in the protected zone, but now that vShield Zones operates at the vNIC level, every VM is totally protected.
- So if something happens to the Zones virtual firewall VM (e.g., it’s powered off), the networking on a host will go down, because nothing can route without the virtual firewall VM. If you migrate a VM from a Zones-protected host to an unprotected one, vCenter Server automatically removes the filter, so a VM won’t lose network connectivity on its new host.
- Also in the new version of 4.1, VM Flow is gone (it was available free in is previous version), you need to upgrade to VShield App get have it back again. For my environment, I use PRTG’s packet analyzer on switch mirror ports, so such feature is not required.
- In this new version 4.1, committed firewall policy is applied in real time, there is no need to login to console and issue validate sessions anymore.
- vShield Zone firewall can apply to 3 levels, Data Center, Cluster and Port Groups (?), I usually deploy it at Cluster level due to DRS.
- If you have a cluster, then it’s highly recommended to install vShield Zone on all ESX hosts as VMs may got vMotioned between ESX hosts in the cluster and they will still be protected by vShield Zone (ie, firewall).
- Install vShield Zone process does not need to reboot the ESX host, but uninstall vShield Zone does require reboot the ESX host, after the reboot, often you will find the originally configured vShield Zone switch is not removed, so you need to remove it manually.
- It’s nice to see the extra tab in vCenter interface, but I still prefer to manage vShield using the web interface.
- You can always get more features by upgrading to other advanced vShield Products like vShield Edge as those will provide features like VPN, routing, load balancing, etc.
- Under Maintenance Mode, vShield Zone for a particular ESX host SHOULD NEVER NOT be vmotioned away although vShield Manage can. You will need to manually shut it down (by using CLI shutdown) after DRS automatically migrates all other VMs on the host and reboot the host. I am still trying to figure out how to set maintenance mode DRS recommendation for vShield VM, if you know, please do let me know, thanks.
Part of the above were quoted from Eric Siebert’s newly revised Installing VMware vShield Zones for a virtual firewall and don’t forget to review his article on “Top 10 VMware security tips for vShield users”
Update: Oct 30, 2011
I found the solution to my last question in how to avoid vShield Zone VM to be moved away during Maintenance Mode by DRS, the answer is at the end of the Install vShield Zone PDF (Page 13, can’t believe I missed this extremely important piece of information). Basically, you need to set vShield Zone VM Restart Priority to Disable under HA and Automation Level to Disabled under DRS.
To prove it’s working I did a test, I put the host in to Maintenance Mode, DRS was able to vmotion away everything to other available nodes except the vShield Zone VM, then it shuts it down nicely, everything is done automatically.
Bravo!
人為什麼活著﹖
By admin, April 11, 2011 2:44 pm
這是最近台灣大眾銀行激動人心的廣告﹐令人不得不再次思考這個嚴肅的問題。
1963年﹐前美國人權領袖馬丁路德曾經講過“I have a dream”﹐去年“老男孩”這套很給力的網絡影片也是圍繞著類似的主題﹐的確人是要有夢想﹐沒夢想的人生就如失去了靈魂的軀殼般冰冷。
How to Update Firmware on ESX using Dell Repository Manager
By admin, April 9, 2011 9:55 pm
No more guessing, I finally got it working and performed the firmware updates on ESX. So now it’s time for Dell to make its vCenter Plugin product for FREE? 
So the following is what I did today, btw, many thanks for local Dell Pro-Support as well:
1. Download the latest version of Dell Repository Manager (v1.2.158) and install it with all the default options.
2. Start DRM in Server Mode (Client Mode is for desktop and notebook).
3. Create a new inventory, select the options with care and according to your requirement ONLY, this wil greatly reduce the total update package size, like Rack, R710, Windows Package Only.
* IMPORTANT: You will ONLY NEED TO DOWNLOAD the LATEST Windows Package, no need to download any Linux Package as USC or Life Cycle Controller 1.4 or above will only support SUU ISO/USB with Windows Package anyway, so using Windows DUP (Dell Update Package) to update Powerdge server firmware even with ESX installed is perfectly O.K.!
4. Export the whole update to ISO, select Export as Server Update Utility (SUU) ISO.
5. Reboot your ESX server (of course migrate your VM away to another ESX host first) and then use iDRAC console to enter USC (ie, F10), select firmware update, mount virtual media with the DRM SUU ISO created in the above step. Soon you will encounter “Catalog file not authenticated correctly”, Don’t Worry! Just ignore it and continue the ISO export because the exported SUU is simply NOT digitally signed.
6. Select firmwares need to be updated and then reboot, system will return to USC by default, go to firmware update again, and compare the update result with DRM ISO if needed.
Finally, the catalog.xml on dell.ftp.com is always a few months behind the latest update. This is where Dell RM does the magic that you can simply Add the latest firmware to an existing inventory and customize to whatever you want it to be, just remember to download those latest firmware first to any folder, Dell RM will copy it over again to root of the RM’s inventory folder, then save it and export a new SUU ISO again.
PS. I just found another great article “The Easiest Way To Update A Dell Server’s Firmware
Update Jul-19-2011
After reading page 77-79 of the latest Dell vCenter Plugin 1.0.1 User Guide, I found DVP still requires a manual creation of a Fimrware Repository like the above (and requires CIFS or NFS). So this step really renders DVP obsolete as we can achieve the same result using Dell Repository Manager with even better control and management.
In that sense, I strongly believe Dell will make its Dell vCenter Plugin for Free within the next 12-24 months.
Update Nov-26-2011
The following improvements have been made in Repository Manager v1.3 which was released in July 2011:
- Support for Dell PowerEdge maintenance driver packs and Dell Unified Server Configurator (USC) driver pack management
- Repository Manager now displays the size of bundles and components
- New plugin management support for Server Update Utility (SUU) and Deployment media plug-ins
- Tool tips in the Export Bundles/Components wizards to explain the various options
- Enhanced performance and reliability for downloading files from ftp.dell.com
- Runtime logs now enabled to capture error, warning, and information
- Improved Success / Failure feedback after each process with reasons for failure if any + recommendations to remedy.
- Report dialog box displayed upon completion of tasks such as repository creation and component downloads
- Cancellation functionality added for time-consuming tasks
- Compare button easier to find, with wizards to guide you through the process.
- Added ability to download, store, and run SUU & DTK plugins locally
- Improved user interaction for time-consuming tasks
Capping the Resources on VM
By admin, April 8, 2011 10:40 pm
I am starting to put different capping policies on VM resources such as CPU, Memory, Storage and Network this week.
The concept is very simple, but implementation takes a lot more thinking and planning than the followings:
High: 2000 vCPU, 20 VM RAM
Normal: 1000 vCPU, 10 VM RAM
Low: 500 vCPU, 5 VM RAM
High:Normal:Low = 4:2:1
For example, a VM with 1 vCPU and 1GB (1024MB) RAM Shares = NORMAL
So CPU Shares will show 1000 and Memory Shares wil show 10240.
In fact, after the capping starts to kick in, I begin to fall in love with VMware’s Resources Managment!
My First Encounter with Xangati for ESX
By admin, April 6, 2011 12:57 pm
Xangati for ESX (Free Edition) is always ranked as one of the top 10 Free ESX Appliances. I finally got time to test it although not very successful, the following is my findings.
- Xangati called its product a management tool for ESX, in fact, it is really a packet sniffer built on Linux CentOS like Wireshark or Ethereal and on top it combines the ESX monitoring capability like Veeam Monitor or Vizioncore’s vfoglight.
- Documentation for Xangati for ESX (Free Edition) is too simple, although you will find two video on Youtube that showing how to setup Xangati, but there is FAQ or community help (There is a community, but it’s really an one way Xangati board)
- Importing OVF into ESX is straight forward, but after starting up the VM, I encountered a problem that the screen showing blank with only X cursor moving, hence, I have no way to open GUI and continue to installation. There was a error in VM event showing my video ram is not big enough, so I’ve increased it to 16MB and the problem continues, quitting the session, I found VM console was showing some kind of JAVA error, I guess there is something wrong with JAVA that prevents the GUI (or JAVA) console to be shown. Finally, I’ve also tried to re-deploy the OVF as thick as thin format may cause the reason, but it still showing blank screen anyway
- After google a bit, again I was lucky to find a PDF that showing a bit more details for the installation, although it’s for Xangati Dashboard, within I was able to locate the username “setupip”, but where is the password? So I used the same username as password, ok, I got in and successfully configured my Network, DNS, Time Zone, etc. Btw, I’ve sent an email to support@xangati.com regarding the blank screen originally, but still got no reply after 24 hours.
- After connected to the configured Xangati appliance via browser and login as admin, I was able to pull some traffic across my internal ESX host and management IP range. Then I figured out the Free Version can only support 10 IP devices and most importantly, it doesn’t support vCenter, but only 1 ESX Host although I’ve already configured my vCenter IP and tested the connection is valid (no warning in that step), so I’ve changed the vCenter IP to a ESX Host IP and removed all the discovered devices and let the appliance run for 5 minutes, later it just show the traffic for the ESX host and not the VM within, so what’s the point after all?
- The biggest draw back is there is no where mentioning in that 4 page quick installation guide which network portgroup should we connect Xangati VM to. To my instinct, I just use the Service Console portgroup network segment, as it’s where most these kind of monitoring tools works, like Veeam Monitor and Vizoncore vfoglight. However, why there is no VM showing up? I don’t know.
- Veeam Monitor and Vizoncore vfoglight are not appliance based, but application based software instead but they can also provide almost exactly the same feature for showing exactly what’s going on each ESX Host as well as individual VM. Yes, they do not provide any insight into traffic pattern, such as how much WWW is going though at the moment, as well as Email traffic etc. However since I am using PRTG’s packet monitoring that can directly connect into the external switch’s mirror port and monitor all the incoming/outgoing traffic from there, so I don’t really need this feature with Xangati. Last time, this great feature allows me to quickly identify a server IP that’s sending 100Mbps outgoing DDOS via UDP protocol using an encrypted PHP script, which was uploaded by hacker to a client’s web site through it’s ASP upload security hole.
- Finally, the UI of Xangati is not eye catching and easy to use as the Veeam Monitor or Vizoncore vfoglight, combining with installation and the rest, I think it’s potentially a great product, but still has a long way to catch up.
ESX VLAN Configuration: VST Mode 802.1q
By admin, April 4, 2011 10:21 pm
Recently, I tried to configure vSphere VLAN 802.1q VST Mode with external Netgear switch. On Netgear side, VLAN (ID=10) was set correctly on ports by using Tagged Port (ie, 802.1q), the same VLAN ID is also assigned to ESX Portgroup, but the connected VMs couldn’t visit the outside Internet.
I did a simple test by giving a private IP 10.0.18.10 to VM1 on ESX Host 1 which is on vlan 10, then I did the same for VM2 on ESX Host 2 which is also on vlan 10.
Guess what? They can ping each other!
To future prove my original Netgear VLAN setting is correct, I did the following tests as well:
Test 1. Change vlan 10 to vlan 20 on ESX Host 1, now VM1 cannot ping VM2, so original VLAN tagging or 802.1q is working!
Test 2. Change Netgear Port 11 & Port 12 (both on ESX Host 1) to Untag, now VM1 cannot ping VM2, so original VLAN tagging or 802.1q is working indeed!
After researching for several days, I found the following, BINGO!
For example, consider the organization whose servers plug into distribution layer switches. These distribution layer switches then connect to a core switch. If the connections between the core switch and the distribution switch are not already configured as VLAN trunks, i.e., are capable of carrying multiple VLANs simultaneously, then using VST is impossible. Each of the distribution switches only carries a single VLAN and is only capable of carrying a single VLAN.
I thought I don’t need to get my Netgear to talk to data center’s core switch in order to have ESX VST working, this is exactly I was wrong! After talking to my data center, I got it working finally, but I still decided not to use VLAN (VST mode) on public IP addresses as it doesn’t provide real benefits and ESX Portgroup won’t allow traffic sniffer anyway, so it’s pretty secure, rather I found a private or local 802.1q VLAN is more useful say to configure a Private LAN between VMs (sometimes, you need a private LAN for backup)
90年代的超跑對60年代的經典
Sponsored By
