Port Conflicts between PRTG Network Monitor and VMware vCenter

By admin, December 28, 2010 2:07 pm

I didn’t know this could happen until last night. I restarted VMware vCenter server after installing Microsoft patches for Windows Serve 2008 R2. Then used vSphere client to connect to vCenter, suddenly it started to pop up with error, also found vCenter Server Service has stopped or crashed to be precious and error logs showed Event 1000 ID, luckily I found this is to do with vCenter port conflicts. I was also able to confirm this by another user’s post in VMware community who’s having the same port conflicting problem with PRTG and ESX 4.

As usual, my memory needs to rewind and back to the point where I installed PRTG Network Monitor 4 days ago, by trial and error, I stopped the PRTG Server and Probe Services, then I was able to restart vCenter server again and login with vSphere client. Finally, I was also able to restart PRTG server without any problem, PRTG somehow was able to bind itself dynamically to another port which vCenter couldn’t.

In additional, I did try to change the port for PRTG and its Probe services, but after restarting the server, somehow PRTG is still conflicting with vCenter’s port (I don’t know which port, but PRTG is using a range of ports above 23560)

The solution is quite simple but a bit troublesome, as it’s a matter of precedence, I just need to start vCenter Server service before starting the PRTG services MANUALLY every time after restarting the server.

If you know how to change the service start dependence or any proper way to solve this, please do let me know, as somehow I still couldn’t figure out the permanent solution for this port conflict problem, thanks!

罕見的黃色Ferrari F430

By admin, December 27, 2010 9:09 pm



Another Poweredge Firmware Update Nightmare: 2nd Time Disappointment

By admin, December 23, 2010 1:11 pm

Dell has a new “Build-in OS” called System Service (USC) that you can simple update firmware and deploy different OS using the simple GUI. I like it a lot for OS deployment as it indeed saved me a lot of time in finding different drivers, but until recently, I found the specific USC module that is the Platform (Firmware) update feature isn’t very stable and may cause various system problems.

The following is what I’ve encountered:

I press F10 during boot time and enter USC and select Platform Update for firmware update process, configure IP for USC and then next connect to ftp.us.dell.com to check a list of update firmware, after 5 minutes, as usual, USC found a list of outdated firmware (about 15 of them) and asked me if I would like to continue to update those. Great! then click apply, “Please Wait” is what I get on screen and wait, and wait and wait, I waited for more than 2 hours and definitely sensed some kind of strangeness as my last update using USC for BIOS and IDRAC only took 15 mins.

Immediately I called Dell Pro-Support regarding this issue, they suggested me to wait and they ensure me everything should be ok, as even bad thing happens, I can still use Firmware Roll Back under USC, and if a particular firmware download process isn’t completed then the update won’t carry on.

O.K., then I went to sleep, after 12 hours, I checked the server, it is still showing the annoying “Please Wait”, NOTE there is NO WAY for me to know the status of the update progress as it won’t tell me which module/firmware it has finished downloading or completed the upgrade process for a particular firmware.

I have no choice but to reboot the server, luckily, the server (OS is Windows Server 2008 R2) came back ok, and I checked the firmware information in OpenManage, NOTHING HAS BEEN UPDATED, and worst some of the sensors in OpenManage are gone such as temperature/voltage/fan, etc. Right away I KNEW iDRAC Must Have Been Damaged during the firmware update under USC, so I connected to R610 iDRAC and indeed found all of the sensors showing reading errors. Huh???

Then I thought by updating the iDRAC firmware may help, so I tried to update iDRAC6 to latest 1.5.4 using the standard windows firmware file, immediately error shows “This update package is not compatible with your system configuration”, thank you very much!

After searching Google with no solution found, I suddenly thought of a way to update it by downloading the raw iDRAC6 firmware update file and using iDRAC’s own update feature from Remote Access > Update and I have successfully updated it! Yeah! Then I reboot the server, and checked OpenMange again, thank god, everything is back to normal this time!

Finally, I simply go back to the traditional way of updating firmware on Poweredge which I have been doing for the past 10+ years, that is download the firmware one by one and update my Poweredge R610 BIOS/Network/Raid etc one by one.

So my conclusion is:

1. Platform Update utility under USC is NOT A MATURED PRODUCT!

2. Probably USC FTP process hanged, network issue, but USC won’t alert at all, just showing “Please Wait” that really DOESN’T HELP AT ALL!

3. You NEED TO UPDATE iDRAC first (probably using the above method) before using USC, as USC uses iDRAC to facilitate the rest firmware upgrade process. I remembered ont time USC warned me it will upgrade iDRAC first before anything else, but it didn’t warm me this time.

Dell please correct this bug ASAP in USC Platform Update, at least show us the update process bar or some useful detail information!


If you want to read about my first disappointment regarding firmware update, please refer to Do not update firmware/BIOS from within ESX console.



Just received an update from Virtualization Buster, which is the proper way to update firmware using an USB method via F10 Unified Server Configuration (USC).

Updating Dell R-Series aka 11-th Generation Servers via USB and Repository Manager


Finally, since there is no way to attach an USB via iDRAC6, so if you need to update Driver thru USC, you can use Dell Repository Manager, export the drivers to an ISO. (Tips from Dell Pro-Support)

Veeam B&R 5: Block Size Optimization and Reversed Incremental or Synthetic Full

By admin, December 20, 2010 12:31 pm

Saw these two piece of useful information on Veeam’s forum today, mostly contributed by Tom:

Block Size Optimization

In the job properties, on the “Backup Destination” if you hit “Advanced” and then select the “Storage” tab with V5 you can now select to optimize for Local disk, LAN target, and WAN target. What this is really doing is setting the “block size” of the VBK. Previous version of Veeam always used 1MB blocks, which is now the equivalent of the “Local disk” option. LAN target uses 512KB blocks, and WAN target uses 256KB blocks. The smaller blocks sizes typically mean that incrementals are smaller and thus less data is transferred over the LAN or WAN at the cost of some CPU. Because we push our backups across sites we always use the WAN target settings.


Reversed Incremental or Synthetic Full

As a general rule, reverse incrementals are going to use the least amount of space on disk, but the most amount on tape, while the reverse is true of forward incrementals, they will use more disk space, but significantly less tape space. The only exception might be if you have a fairly small retention period.

Assume you have a 100GB full backup with 10GB of changes a day, here’s how the space would break down assuming 4 weeks retention:

Reverse Incremental:
Disk — 100GB Full + 280GB (10GB/day * 28 days) of reverse incrementals = 380GB
Tape — 100GB VBK copied to tape every day * 28 days = 2.8TB

Forward Incremental w/Synthetic Full:
Disk — 400GB (100GB Full * 1 per week) + 240GB (10GB/day incrementals * 24 days) = 640GB
Tape — Same as disk, since you simply copy the full or incremental to tape every day = 640GB

So, the Forward Incremental/Synthetic option in this scenario would use ~70% more disk space, but less than 25% of the tape space. If you’re planning to keep only a short period of disks on retention and use tape for long term storage then forward incrementals will save space, but that’s about the only scenario where it will save space. For the best space savings with on disk retention, reverse incremental are the way to go, but at the cost of a large amount of tape space.


Personally I prefer reversed incremental because my main strategy is to get a full working backup to tape every night without the need to merge increments when in an emergency need to get my files back from tape.

ASTON MARTIN ONE-77 亞洲巡迴展香港站

By admin, December 19, 2010 7:38 pm

價值愈千萬港元的英國超級跑車ASTON MARTIN ONE-77,雖然未知香港可以獲得的配額究竟有幾多,但可以肯定是在全球77台限額中,已經有60台成功售出,只餘下17台配額而已。與此同時,廠方亦已為這台限量超跑新貴展開亞洲巡迴展,日本東京站已於日前結束,緊接會是新加坡和台灣等地,至於擁有大量超跑的香港亦會在當中之列,不過仍有待代理公布才可作實。


Classic & Sports Car這期的主題﹕奔馳在歐洲大陸上的Countach們﹗

By admin, December 17, 2010 9:53 pm





By admin, December 17, 2010 3:29 pm

早在今年8月的時候就已經收了Ferrari 410 Superamerica銀色和黑色的兩個版本(之後還先後出過褐色和金黃色的版本)。


但正如所有的Super Elite系列一樣﹐它們的標價真的太昂貴了﹐而且大多數Super Elite系列的車模性價比都不太高。但凡事還是有例外的﹐我曾經詳細比較過所有Super Elite系列的出品﹐直至現今﹐質量最高的車模只有3款﹕ Ferrari F430 Scuderia, FXX 和這款棗紅色的410 Superamerica (排名不分先後)。現在聽說Hotweels即將擱置Super Elite系列﹐因為多年來的銷情不是太過理想。另一方面聽說Hotweels會大力提昇Elite系列的品質﹐這個傳聞可以從最近大獲好憑而且熱賣的599XX身上看得出一點跡象。

話歸正題﹐為了Super Elite的它﹐前陣子﹐我曾好一度徘徊國外的拍賣網站﹐但最後還是因為勝出價錢再加上運費太高而放棄了繼續下標。

黃天不負有心人﹐今天無意間打開了一間本地車模店的網頁﹐看到了它竟然在做聖誕節大特價﹐而且是所有的Elite/Super Elite系列都有半價﹐哇﹗激動﹗這太好了﹗馬上(真的是馬上)跑去選購﹐到達的時候﹐發現很多熱門的Elite/Super Elite已經給人買走﹐幸虧它還在﹐哈哈﹗仔細觀摩下﹐沒發現什麼問題﹐就乖乖奉獻上了銀子。

這款Super Elite的車模真沒什麼可以挑剔的﹐完美無瑕的棗紅色金屬油漆﹐全車極多的蝕刻片﹐加上Hotweels Elite系列出名的精緻內飾﹐看得我是愛不釋手。

最後不知是否同是法拉利兄弟﹐ 410 Superamerica的側面實在太像250 California了﹐所有下一個目標是那款最近出的紅色250 California。


1/18 Hotwheels Super Elite Ferrari 410 Superamerica


YY(Yonex)的ISO Metric果然確名不虛傳

By admin, December 14, 2010 9:29 pm

多謝六叔同Will和我今天爆左好多板﹐平時最弱的開波今日竟然發揮到﹐靠它拿了不少分﹐總結就是絕對不能懶﹐由拋球﹑彎腰﹑weight transfer到擊球﹐樣樣都不能懶﹐還有就是上次師兄提醒我拋球是要拋去左邊一些﹐才能做出大角度和多些Spin﹔加上Wolf兄在星期日示範了如何運用前臂去包球而產生更加多的旋轉和向前沖的力量﹐這些都增加了今日的發球的穩定性和力量。


最後嘗試了Will的新YY Ezone球拍﹐YY 的ISO Metric果然確名不虛傳﹐跟之前試過的一系列YY一樣﹐真的很SPIN和容易控制尤其是上網和Approach Shot﹐而且手感極好﹗





By admin, December 10, 2010 10:59 pm





By admin, December 9, 2010 11:31 pm





好了終于等到Hotwheels Elites的紅色和黃色458版本出了﹐但那門縫大得嚇人﹐比之前的普通版F430還要大許多﹐怎麼搞的﹖雖說價錢的確便宜了4/5﹐但這樣的品質實在有點令人失望和難以購買。

直到黑色的版本出現了﹐當然門縫還是大得嚇人﹐但因為黑色的原因﹐還好﹐看不太出來﹐而且紅色的運動內飾又格外令它份外醒目﹗認識我的朋友都知道我幾乎不收黑色的超跑﹐但今天碰到了它則是一個例外﹗Hotwheels Elites的黑色458其實是金屬黑色﹐不知為何﹐458在黑色的外殼下突然顯得沒那麼難看了﹐開始順眼了許多。


1/18 Hotwheels Elite 458 Italia Black



今天看到MC TIKI的評論才恍然大悟﹕ 

F458 的丑,我一早已經有這個感覺,先前在東區走廊看見一部淺銀藍色的,真是不忍相信是法拉利。我也只是象徵式的收了一輛 hotwheel 的算了。458 是把 430 的頭加 Enzo 的尾复制過來,但敗筆是首尾的比例不協調,如果把駕駛室後移一些,或者把頭部加長少許也許會平衡一些。車頭入氣口的兩片翼不倫不類,沒有實質整流作用,又不能混入車身設計,像為了仿效 Enzo 而強行加上去。車頭燈是純為時尚設計而設計,刻意之餘有點做作,但卻與傳統的尾燈不呼應。而最丑的是那兩只超大碼的尾燈,應該設計一套新的跟頭燈的 LED 配合。車身後半部太臃腫,如果把兩邊側窗的線條開得低一點會好看些。

Pages: 1 2 Next