My first attempt to find out whether the issue is the engine proved to be anything less than fruitful. It goes without say that the dealership, Boardwalk Nissan in Redwood City was less than cooperative. It seems that they're interested in taking in the highest volumes with quick turnaround without actually taking the time to explore issues based on customer concerns. I've posted complaints about their service (lack of) on several online aggregates so, I'll refrain from hashing the same here. Since I'm diligent in maintaining my vehicles (oil checks, changes, etc.) I began to suspect that I was dealing with a legitimate problem. A little online research began to yield several results related to what I experienced:

http://www.planetfeedback.com/index.php?level2=blog_viewpost&topic_id=302548&reply_id=147612
http://www.my350z.com/forum/engine-and-drivetrain/232332-revup-oil-consumption-tsb-and-discussion.html
http://www.350zmotoring.com/forums/general-350z-discussions/36993-those-who-went-through-oil-consumption-test-read.html

With the knowledge acquired from the links above, I tried a new dealership, Falore Nissan in Sunnyvale. I spoke with Jerry, he provided the manufacturer guidelines. After near 3 months of driving, they finally confirmed that my oil consumption was below the normal wear and tear, as a result, I am now getting a new small block after 40,000 miles of driving.

The moral of the story?

1. Be persistent. You should always get a second opinion. Be bullheaded!
2. Do your homework! Knowing what you're dealing with, and explaining the issue to a service vendor in an educated matter will make a world of difference. Cut down to the chase.
3. Be persistent! Be tenacious, don't take no for an answer. If you have a vehicle warranty, use it! The manufacturer provides the warranty for such scenarios!

I need to note that Jerry and Bob from Falore were extremely cordial and very professional in the process. Bob's expert knowledge and enthusiasm were definitely a sigh of relief. I certainly don't get to see that nowadays...

Hopefully this will be of some help to other owners with the same issue

Once you have it downloaded, just run the following command:
v2xva.exe /verbose:LOW /config:"C:\[SOURCE]\[VM NAME].vmx" /output:C:\[DESTINATION]\

Enjoy!

Produced in 1900, making it, truly the album of the past century!

In most cases, users will notice that their PV's network connection will be slow, the SAN will not burst over 100Mbps, which is pathetic! To make matters worse, as your PV's receive more traffic, they'll begin to display network fatigue and randomly drop packets or just come to a near screeching halt! So far, Citrix has not yet released anything concrete for users to implement. In fact, they've denied, rather not discussed the issue in public. I'm sure they'll continue to do so, until they've determined the root cause of the issue. In the meantime, there are a few steps you can take to correct the issue. To start off, you'll want to disable the VIF/PIF checksums using the script below.

If you're using a Windows 2003 PV, then you can hack the registry and add "DisableTaskOffload" to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters:

1. Reinstall XenTools 5.5
2. On the Virtual Machines, Click Start, click Run, type regedit, and then click OK.
3. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
4. In the right pane, make sure that the DisableTaskOffload registry entry exists. If this entry does not exist, follow these steps to add the entry:
   a. On the Edit menu, point to New, and then click DWORD Value.
   b. Type DisableTaskOffload, and then press ENTER.
5. Click DisableTaskOffload.
6. On the Edit menu, click Modify.
7. Type 1 in the Value data box, and then press ENTER.
8. Exit Registry Editor.
9. Restart all Virtual Machines

Bash script to disable VIF/PIF checksum (proceed at your own risk):

#!/bin/bash
 
 
if_modes="rx tx sg tso ufo gso"
 
if [[ "$1" == "--local" || "$1" == "-l" ]]; then
    echo -n "disabling checksum offloading for local devices... "
    for iface in $(ifconfig | awk '$0 ~ /Ethernet/ { print $1 }'); do
        for if_mode in ${if_modes}; do
          ethtool -K $iface $if_mode off 2>/dev/null
        done
    done
    echo "done."
else
    echo -n "disabling checksum offloading in xapi settings... "
    for VIF in $(xe vif-list --minimal | sed -e 's/,/ /g')
    do
        ###xe vif-param-clear uuid=$VIF param-name=other-config
        for if_mode in ${if_modes}; do
            xe vif-param-set uuid=$VIF other-config:ethtool-${if_mode}="off"
        done
    done
    for PIF in $(xe pif-list --minimal | sed -e 's/,/ /g')
    do
        ###xe pif-param-clear uuid=$PIF param-name=other-config
        for if_mode in ${if_modes}; do
            xe pif-param-set uuid=$PIF other-config:ethtool-${if_mode}="off"
        done
    done
    echo "done."
fi
 

I am all for the multi-thousand dollar implementation that will guarantee 99.9999% uptime but what about the up and coming websites that aren't equipped with the budget to get this accomplished? In a world where cash is king, it seems that the potential of these websites is often ignored and put past recognition because they don't have the capital. Companies like Rackspace want you spend money for their services, rightfully so, but it would be nice if they could offer something that would get you started, right? Wrong! Unfortunately, these companies have grown beyond that point, and they've outgrown the need to cater to any of the individual and small business markets.

Right, so let's get on with my shoe string budget that won't break the bank! The first thing you have to recognize is that my definition of a "shoe string" budget differs in leaps and bounds by yours. The goal for this project, was to keep the monthly maintenance fee under $180 per month for my website.

1. VPS container running CentOS 64bit with MySQL (database server) - $10 - 30 per month
2. VPS container running CentOS 64bit with Apache * 2 - $10 - 30 per month
3. VPS container running CentOS 64bit with LiteSpeed Load-Balancer from LiteSpeed Technologies - $32.00 + $65.00 license lease from LiteSpeed Technologies.

There is a well documented tutorial to get you started with LSLB: http://www.wowtutorial.org/tutorial/80.html once you have the virtual servers above, you can deploy your environment successfully. The beauty of this implementation is that you can expand over several geographical locations. The downside is that you'll have a single point of failure, which is your LSLB server. However, you can still work around this with DNS round robin and a secondary LSLB server. You also have to set up a bash script to rsync  (or FTP sync for Windows) to replicate your website bits over to the other server, or you can do it manually by refreshing the bits on each server.

This is not the defacto for website availability. There are several more elegant ways to setup HA but, this would be a good start!

1. On the source host or pool, in xsconsole, select the Backup, Restore, and Update menu option, select the Backup Virtual Machine Metadata option, and then select the desired SR.
2. In XenCenter, select the source host or pool and shutdown all running VMs with VDIs on the SR to be moved.
3. In the tree view select the SR to be moved and select Storage > Detach Storage Repository. The Detach Storage Repository menu option will not be displayed if there are running VMs with VDIs on the selected SR. After being detached the SR will be displayed in a grayed-out state.
   Warning: Do not complete this step unless you have created a backup VDI in step 1.
4. Select Storage > Forget Storage Repository to remove the SR record from the host or pool.
5. Select the destination host in the tree view and select Storage > New Storage Repository.
6. Create a new SR with the appropriate parameters required to reconnect the existing SR to the destination host. In the case of moving a SR between pools or hosts within a site the parameters may be identical to the source pool.
7. Every time a new SR is created the storage is checked to see if it contains an existing SR. If so, an option is presented allowing re-attachment of the existing SR. If this option is not displayed the parameters specified during SR creation are not correct.
8. Select Reattach.
9. Select the new SR in the tree view and then select the Storage tab to view the existing VDIs present on the SR.
10. In xsconsole on the destination host, select the Backup, Restore, and Update menu option, select the Restore Virtual Machine Metadata option, and select the newly re-attached SR.
11. The VDIs on the selected SR are inspected to find the metadata VDI. Once found, select the metadata backup you want to use.
12. Select the Only VMs on this SR option to restore the VMs.
13. Note Use the All VM Metadata option when moving multiple SRs between hosts or pools, or when using tiered storage where VMs to be restored have VDIs on multiple SRs. When using this option ensure all required SRs have been reattached to the destination host prior running the restore.
14. The VMs are restored in the destination pool in a shutdown state and are available for use.

Note: You can't have the same SR attached in two different pools when using XenCenter. You'll have to disconnect from the old shared pool to use the new one.

Enjoy!

I've always been anti pop-up for several obvious reasons:

1. Calling multiple windows on the same website is annoying.
2. You don't want to give your customers the option of unblocking pop-up windows because it can be an inconvenience and could possibly lead to confusion on their end. No, I will not give them the benefit of doubt...
3. Pop-up windows are often blocked by today's modern web browsers, and the "safe list" management can be annoying.
4. Pop-up windows are so 1999! Get with the times!

The moral? Annoyance. Given the fact that most web visitors have an extremely short attention span, I came up with an elegant solution using Lytbox to work around this. This work around requires three small modifications to your WHMCS template files. Here is how you do it (copy & paste):

1. Make a backup copy of header.tpl and clientareaemails.tpl before you make any changes. This is where source safe is extremely useful!
2. Download the Lytbox bits, save them to your WHMCS template directory (or any other location).
3. Edit header.tpl and add the following lines to the source before </head>:<script type="text/javascript" src="[path]/lytebox.js"></script>
   <link rel="stylesheet" href="[path]/lytebox.css" type="text/css" media="screen" />
4. Edit clientareaemails.tpl and look for "{$email.subject}". Replace the {$email.subject} hyperlink  with the following:<a href="viewemail.php?id={$email.id}" rel="lyteframe" title="{$email.subject}"
   rev="width: 650px; height: 450px; scrolling: yes;">{$email.subject}</a>
5. You can adjust the windows width and height in the hyperlink above.
6. Save both files, then upload them to your server. At this point, you should be able to test it out by visiting a client's dashboard. The result  should look something like the image below.

Now you have an fancy presentation window. Enjoy!

• xe pif-param-set uuid=<UUID of PIF> other-config:ethtool-autoneg=”off”
• xe pif-param-set uuid=<UUID of PIF> other-config:ethtool-speed=1000
• xe pif-param-set uuid=<UUID of PIF> other-config:ethtool-duplex=”full”

Once you've issued the commands, make sure that you restart XAPI. The reason why you would want to do this is, to ensure that all hosts on the network fabric are communicating at a certain speed to eliminate the guess work. This is the same reason why I did this!

Note: If you want the network interface to be unmanaged, then you'll need to first run "xe pif-list" on the host, identify the NIC UUID, then run "xe pif-forget uuid=[id]"...

The assumption is that you know what you're doing. With that in mind, I issue the command from the PDSH  as root, save the file to the ~/.ssh/ directory, then cat and append it to an existing authorized_keys2. Once that takes place, the file is removed from the destination. This beats having to do the same task repetitively or use a bash script. In other words, Parallel computing rules!

pdsh -l root -a 'wget http://[REMOTE URL]/[FILE] -O ~/.ssh/[FILE]
&& cat ~/.ssh/[FILE] && ~/.ssh/authorized_keys2 &&
rm -rfv ~/.ssh/[FILE]'

SecRule REMOTE_ADDR "^74\.52\.50\.50$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^83\.170\.113\.102$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^95\.211\.87\.85$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^67\.205\.112\.79$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^78\.136\.27\.223$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^67\.192\.120\.134$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^174\.34\.156\.130$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^70\.32\.40\.2$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^207\.218\.231\.170$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^204\.152\.200\.42$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^74\.53\.193\.66$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^207\.97\.207\.200$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^174\.34\.162\.242$" phase:1,nolog,allow,ctl:ruleEngine=Off
SecRule REMOTE_ADDR "^85\.25\.176\.167$" phase:1,nolog,allow,ctl:ruleEngine=Off

Error: The property 'value' located at '/metaKey[@path='/lm/w3svc/12130']/metaKey[@path='ROOT']/metaProperty' is marked as secure. You must specify an encryption password to archive this property. Error count: 1.

It appears that you have to specify a password to create the archive, with that, I added the following to my command:

msdeploy.exe -verb:sync -source:metakey=lm/w3svc/12130 -dest:archivedir=c:\archive,encryptPassword=[pass] > wdeployarchive.log

Problem solved!

1. I started by making sure that the all hosts had xapi running on all hosts.
2. From there, I issued the following command "xe pool-emergency-transition-to-master".

Once I did this, the host synced with the master and the problem was resolved!

The solution boils down into two:

1. The XenServer time/date is out of sync. Check to make sure NTPD is up and running. Best practice is to use an NTP proxy server on the local net for your XenServer hosts, this is especially important when you are running XenServer Essentials with HA enabled. Always trust but, verify. Make sure the time on each server host is accurate.
2. Close XenCenter, and then remove the logs under "%AppData%\Citrix\XenCenterMain.exe*\".  Restart XenCenter and test.

Enjoy!

"This operation cannot be performed because HA would no longer be guaranteed for this pool.  To perform this operation anyway, you must disable or reconfigure HA."

Reason why this happened: When HA is enabled and a VM HA Protection level is set to Protected, in addition, the destination server must have the available memory needed to migrate the VM using XenMotion. The host server that is still holding the memory of the VM also must have that same amount of memory available (in reserve) to perform the migration. In other words, the host server must have available the same amount of memory that the VM is about to release.

Here is how to fix it the issue.

1. On the pool master host,  type: "xe pool-list" to obtain the pool UUID, in my case it is: cbfdcdfd-b7ad-2d22-3efb-6fb3945f2e92.
2. Run "xe pool-param-list uuid=[UUID]" to determine what the current setting for "ha-allow-overcommit" parameter is set to.
3. To change the overcommit setting run: "xe pool-param-set ha-allow-overcommit=true uuid=[UUID]".
4. Now run "xe pool-param-list uuid=[UUID]" and make sure that "ha-allow-overcommit ( RW): true" is set.

Now I'm able to migrate the VM from one server to the other. I live to learn more another day, Sweet!

Before:

After:

If that doesn't work, then start Outlook, go to Calendar, click on "View", then "Current View" and finally select "Recurring Appointments". Remove the item in question to get rid of the error!