Comments (0)

By admin, May 4, 2011 3:37 pm

Mix Greens from Australia, Cherry Tomatoes from Israel, Organic Cucumber from Local, Feta Cheese from Greek, and a touch of Extra Virgin Olive Oil and Balsamic from Italy. Together with a slice of home baked bread and some left over Carbonara, this makes a perfect lunch!

The cost for the salad per serve is about HK$25, way cheaper and healthier than buying the ready-made ones from super market, this price of course not counting the labor that is.

Comments (0)

By admin, April 29, 2011 10:02 pm

作為前殖民地的香港﹐大家還是極之關心這個大不烈顛的皇家盛事﹗

Comments (0)

By admin, April 29, 2011 2:55 pm

I’ve read the Wiki page for installing OVF on ESX and failed once already because I bridged the vNICs on the same vSwitch without using VLAN, so eventually I crashed my network as looping started to occur.

So this is my second attemp, please refer to the picture I’ve attached, hope you can give me some advice and suggestions.

1. So basically, I have ONE vSwitch with TWO physical NICs binded together to have Load balancing and failover.

2. Within, I have THREE Port Groups:
- External (no VLAN) connects to Internet
- Untangle DMZ (VLAN 21) – Useless as I will use Transparent Mode
- Untangle Internal (VLAN 22) – where I put VMs that I want to protect behind the Untangle.

Is the following concept correct?
1. When I use Untangle in Bridge or Transparent Mode, I will ONLY utlilize two interfaces External (no VLAN) and Untangle Internal (VLAN 22), so these are the two vNICs Untangle VM will connect to. This leaves Untangle DMZ useless, so I can remove it from VMX or VM configuraiton GUI?

2. I Understand I need to enable Promiscuous Mode in order to have Untangle to scan the network in transparent mode (ie, a sniffer that is), (side topic: Do I need to have Promiscuous Mode if I am using Route Mode?)

I understand I need to enable Promiscuous Mode on Virtual Switch Level (ie, toppest level), which I DON’T WANT to due to security reasons (ie, VM behind Untangle can sniff the whole network right?), Can I enable Promiscuous Mode in individual Port Group Instead?

If Yes, the ONLY Port Group need to have Promiscuous Mode enabled is Untangle Internal (VLAN 22) right? Where it is the Port Group all the VMs are going to connect to. I do not need to enable Promiscuous Mode in External (No VLAN), is this correct?

Or I HAVE TO ENABLE IT on vSwitch level? but why? I thought individual Port Group will OVERWRITE the default setting, NO?

But wait, no matter where I enabled the Promiscuous Mode (ie, vSwitch level or Port Group level), the risk is still here, can I say I am allowing all the VM to have the capability to sniff traffic on the network? If yes, this is absolutely NO GOOD in using Untangle as enabling Promiscuous Mode will open a big security hole in L2 (ie, enabling Promiscuous Mode will render my switch to a hub)

3. FYI, the TWO PHYSICAL NICs (ie, vmnic8 and vmnic0) are connected to the same physcial L2 switch. VLAN 21 AND VLAN22 have been configured on this physical switch as well, also VMware VST VLAN tagging is used on the Port Group. I wonder if my current configuration will STILL create a loop that will crash my network again? (I don’t see how it can, but really want to double make sure and confirm with you guys)

4. Where is the management interface for Untangle going to be in this case? Do I need to create a new port group say Untangle – Management VLAN 23, and also add a new vNIC (probably just use the one for DMZ) and then connect to this Untangle – Management port group.

Update May-1-2011

Now I understood Port Group with VLAN VST Mode won’t work with Untangle and confirmed again with what’s on the Wiki, the document said it clearly “Each vSwitch should be connected to it’s own Physical NIC, or at least be separated by VLAN tagging at the physical NIC level. ” (ie, on the Physical NIC level and the picture attached above also confirmed this).

So does this mean Promiscuous Mode for bridge mode can ONLY work on Virtual Switch Level, but not Port Group Level?

Um…it’s quite disapointed as I gradually found out Untangle on ESX has so many limitation (ie, no VLAN tagging, must enable Promiscuous Mode for vNic connecting VMs, must have Promiscuous Mode on vSwitch but not on Port Group).

So I have decided to use Route Mode now to aovid the above limitation now.

Since I don’t have any more physical NIC to spare, can I create an internal vSwitch (ie, WITHOUT NIC) for Untangle VM ?

ie, External > Untangle External > Untangle Internal (which is on the internal vSwitch without NIC) and all the VM will be on this same internal vSwitch, which will be all protected by Untangle that is.

This will work right? Anyone Please?

Update May-19-2011

Finally, I’ve got Untangle 8.1 OVF working under ESX 4.1 in route mode, the solution is very simple:

1. Simply remove the last NIC in VM configuration, this will get rid of the DMZ NIC, leaving only External and Internal NICs. These two NICs are exactly what Route Mode requires.

2. Assign External NIC to your external connectivity to the Internet, and Internal to a seperate Port Group (in my case it’s VLAN 20 – Untangle)

3. Reboot Untangle, now, you won’t be able to use the default admin/passwd to login, it’s ok, just reset it, after successfully login to the console, configure the statics IP for both External and Internal.

That’s all you need, simple and neat! and I am really starting to fall in love with Untangle’s GUI, they do look so much cooler than my dull Netscreen’s GUI.

Comments (0)

By admin, April 25, 2011 5:57 pm

號稱全球第一部的香港3D三級片﹐鋪天蓋地式地宣傳的確令吸引力大增﹐看完後﹐覺得3D效果很不給力﹐最後才知道原來肉蒲團是套警世的愛情片。

Comments (0)

By admin, April 24, 2011 11:23 am

Yesterday, I tried the cpuid.coresPerSocket setting on a testing W2K3 Web Edition VM (plain install, no SP), I set cpuid.coresPerSocket = 4 with 8 vCPUs and I was able to boost the VM to 8 CPUs in task manager (ie, 2 sockets with 4 cores on each sockets), then I remove the cpuid.coresPerSocket parameter from .vmx and reduce the vCPU to 1, problem started to occur after reboot the VM.

Veeam Monitor and ESX Performance Tab started to show CPU over usage alarm and CPU stayed at 100% no matter what, I even remove the VM from Inventory as added it back again as I though it may solved the problem, nothing worked until I found VMware KB1077.

However there is no option in Device Manager > Upgrade Computer HAL to change from Multiprocess HAL to Uniprocessor HAL prior W2K3 SP2, I do have a little program to do it, but I forgot where I put it, so I simply upgrade the VM to SP2 and all the problem disappear after reboot.

I don’t think this will occur in W2K8, probably only happen in old OS like W2K, W2K3 prior SP2, so all you need to do is to select the correct processor HAL for your VM.

Comments (0)

By admin, April 22, 2011 11:40 am

最近和不少朋友進行單打比賽﹐他們都不約而同地說我的球技穩健了﹐我覺得最明顯的是開球方面每Set少于3個Double Fault﹐而且第二發比以前有明顯的穩定性﹐應該是轉了半Backhand Grip和加強Spin的原因吧﹐現在更嘗試反手開多些大斜角Kick Serve。

而底線方面﹐對著強勁的上選﹑平擊時也鎮定了不少﹐而且儘量會做足Foot Work﹐令自己可以有充分的時間減少Late Hit的機會﹐所以來回10幾板已經可以應付自如了﹐但面對正反手都用強勁下側旋的攻擊還是無能為力。唯一的不好處就是感覺膝蓋的壓力不斷增加﹐開始酸軟了﹐年紀的關係吧﹐哈哈。。。

總結近期的進步最主要可能是心態上的改變和動作上的完整和流暢﹐儘量集中精神﹐別浪費體力和亂打﹐要有Plan﹐最後就是Focus真的極之重要﹐發現如果能Focus到﹐感覺連球速也相對地減慢了﹐真的很神奇﹐好玩﹗妙哉﹗

Comments (4)

By admin, April 22, 2011 11:14 am

Content has been removed by the request of VMware on Apr. 28, 2011.

Comments (5)

By admin, April 21, 2011 10:23 pm

Anton (CTO of Starwind) gave me a great gift last night (StarWind v5.6 Ent), thanks!  I couldn’t wait to set it up and do some tests on this latest toy!

The setup is very easy, took me less than 5 mins, probably I’ve installed the previous v4.x back in 2009, but setup according to my own taste is a bit tricky as you need to tweak starwind.cfg and understand the first few parameters especially under the <Connection> section.

It took me 1 hours to get everything working (ie, ESX MPIO+Starwind) as I want to limit the NICs to only iSCSI subnet, as well as change the default iSCSI port to 3268. Yes, sure you can use a non-default port as 3268, as my 3260 is occupied by Microsoft’s iSCSI Target 3.3. I found the default installation also opens the management and iSCSI port 3261/3260 to public in firewall, you definitely want to disable it and limit the NIC access in StarWind management console as well the .cfg file.

So I have configured two Gbit NICs on WindStar box,

10.0.8.2:3268
10.0.8.3:3268

On each of the ESX Host there are 4 Gbit NICs on iSCSI subnet, I added one of the target IP 10.0.8.2:3268, then I found ONLY 4 MPIO Paths discovered, but not the 8 paths, all 4 were using the 10.0.8.2 path, this mean the other redundant path 10.0.8.3:3268 was not being used at all, so MPIO was not working technically specking. On contrast, Microsoft iSCSI Target will add the other one 10.0.8.3:3268 automatically, so it correctly shows 8 Paths.

After searching Starwind forum with Google (yes, use that site: command, so powerful), I quickly located the problem is within starwind.cfg

You can do normal ESX multipathing in Starwind without the HA cluster feature of Starwind 5, just follow the instructions for configuring Starwind to work with XEN and uncomment the <iScsiDiscoveryListInterfaces value=”1″/> line in the starwind.cfg file. This allows ESX to see all the possible paths to the iSCSI target on the server.

After enabled it, and restarted the StarWind service, Bingo! Everything worked as expected! 8 MPIO paths showing Active (I/O). This tweak does work for ESX as well not just Xen, and in fact it’s a MUST to enable it in order to see all paths.

So within the last 3 days, I was able to added two software iSCSI SAN to my VMware environment together with Equallogic, now I virtually have three SANs to play with, I will try to test Storage vMotion between all 3 SANs and perform some interesting benchmarking on StarWind as well as Microsoft iSCSI Target.

Later, I will try to configure the StarWind HA mode on VM (which is hosted on Equallogic), so it’s an iSCSI SAN within another iSCSI SAN.

Comments (0)

By admin, April 21, 2011 4:02 pm

As usual, I would wait at least 1 month before taking the firmware update, probably not to update the firmware at all as none of the following  issues occur to me.

Issues Corrected in this version (v5.0.5) are described below:

• In rare cases, a failing drive in a array may not be correctly marked as failed. When this occurs, the system is unable to complete other I/O operations on group volumes until the drive is removed. This error affects PS3000, PS4000, PS5000X, PS5000XV, PS5500, PS6000, PS6010, PS6500, and PS6510 arrays running Version 5.0 of the PS Series Firmware.

I thought this has been fixed in v5.0.4 where the fix list indicates Drives may be incorrectly marked as failed. So this basically means a supposed failed drive is marked as health, but a healthy drive is marked as failed, wow, interesting!

• A resource used by an internal process during the creation of new volumes may be exhausted, causing the process to restart.

• If an array at the primary site in a volume replication relationship is restarted while the replication of the volume is paused, resuming replication could cause an internal process to restart at the secondary site.

• A resource used by the network management process could be exhausted causing slow GUI response.

• Volume login requests in clustered host environments could timeout resulting in the inability of some hosts to connect to the shared volume.

• A management process could restart while attempting to delete a local replica snapshot of a volume, resulting in slow array response at the primary site for that volume.

• When a management process is restarted, or a member array is restarted, a volume that is administratively offline could be brought online.

• If a member of the secondary site restarts while a volume replication is active, the group at the primary site could continue to report that the secondary site group is offline after the secondary site member is back online.

Comments (0)

By admin, April 21, 2011 8:12 am

I often extend partition live (without downtime) for Windows VM using either diskpart or extpart from Dell, but extending partition under Linux is a totally different thing, it’s a bit complex if you are from Windows world.

1. Increase the disk from vCenter GUI, reboot the server. (Take a Snapshot)
2. ls -al /dev/sda* to find out the last created partition, sda2 is the one in my case
3. fdisk /dev/sda type n for new partition, then p and 3 for the partition number (ie, sda3), then accept all the default first and last cylinders and finally w to complete the partition creation, then finish with reboot.
4. pvcreate /dev/sda3 create a new Physical Volume
5. vgextend VolGroup00 /dev/sda3 add this new volume to default Volume Group VolGroup00.
   (Note: vgextend cl /dev/sda3 in CentOS 7)
6. vgdisplay to show the FREE PE (size of the free disk space), lvdisplay to show the volume name.
7. Extend the volume by lvextend -L +XXG /dev/VolGroup00/LogVol00, you can find out the exact path of the default Logical Volume by lvdisplay. (ie, lvextend -L +20G…)
   (Note: lvextend -L +XXG /dev/cl/root in CentOS 7)
8. Resize the file system by resize2fs /dev/VolGroup00/LogVol00 to complete the whole process. (If everything works, remove the Snapshot)

Update: May 15, 2017
For CentOS 7 , use xfs_growfs /dev/cl/root as it’s use XFS file system instead of the traditional ext3/4 based file systems, also Group and volume name have been changed to cl (was VolGroup00) and root (was VolGroup00).