It has been a very busy summer so far. Besides my day job, very busy family life, and volunteer work, I’ve been actively engaged in the virtualization community; however, as a result, my blog posts have suffered. This is not simply an excuse, but an acknowledgement of my own limitations and a big kudos to all those who are able to continue posting regular updates in the #vCommunity despite external obligations. :)
we have, in effect, all become advertisers of ourselves - self-evangelists ... what example are we setting?
Yesterday morning, my wife shared a video with me which had been shared with her through her Facebook community. It was the complete opposite - being the social media butterfly that she is - that I expected her to be watching, and it inspired me to reflect on my own use of electronic tools, social media, and why I resisted joining social media for so long.
Knowledge is like money: to be of value it must circulate, and in circulating it can increase in quantity and, hopefully, in value. - Louis L’Amour
The virtualization community, like many others, exibits a very generous spirit of giving. The knowledge that we each possess, perhaps acquired through our own experiences, evolves as we circulate it with others.
After being virtually off the social grid for the past month, I decided to resume my activity by sharing some installation ‘gotchas’ that I encountered while deploying vCenter and Site Recovery Manager 5.5.
Please note: these solutions are all based on VMware KBs (noted below) and were tested against vCenter Server and Site Recovery Manager 5.5 running on Windows Server 2012, with SQL Server 2012 SP1 supporting databases.
Although relatively minor issues, I hope that you may found this useful and may avoid some of the same headaches that I encountered.
The concept here is to forward VPN traffic received on the public interface of the Internet router (via incoming TCP port 1194) to the OpenVPN server's interface. The VPN server authenticates the connection, and regulates forwarding traffic to and from various destinations on your private network, based on a defined set of rules. This could include forwarding traffic to your desktop to enable a remote sharing via VNC, RDP, SSH, or other protocol.
I believe that it really depends on your perspective, or in this case the vCenter Server's. I would suggest that a file is orphaned (at least from the perception of a given vCenter) when it (the vCenter) is not aware of what purpose the VMDK file serves; or, to which virtual machine it belongs. This does not always hold true, but that's my general explanation.
Yes, it has been five months now since I began this journey as a newbie blogger with my site empiricvirtualization.com - wow, how the time has flown by! I chose the word empiric because it aptly describes my mission to share some of my hands-on knowledge and experiences. I’ve had the privilege to share some fairly unique posts with you (i.e. the hunt for the elusive dvSwitch config, and my virtualized OpenVPN server), and also become more active in the virtualization and tech communities.
I’d like to say a big THANK YOU to my readers and followers; because, it really is you that motivates me to keep blogging, even though the time required can be rather elusive. It is my intention to continue to deliver unique and educational content, and to start new conversations.
Have you enjoyed these posts? Is there a topic that you would like me to write about? I’d love to hear your feedback.
Here is a sneak peak at some upcoming posts:
Keep on virtualizing!
Have you ever tried working with vCenter Site Recovery Manager’s built-in alarms? How about recovery point objective (RPO) violations? I have, and I quickly grew frustrated by the number of e-mails - essentially, false alarms - that I was receiving. When an RPO was exceeded - even by one minute - an alert would be triggered. While the alarms were technically valid, when you are protecting multiple VMs, and brief RPO violations occur frequently in SRM … well, you get the picture. Overwhelmed by these seemingly non-important alerts - "the boy who cried wolf" - they quickly became ignored. I needed a way to adjust, and fine-tune the RPO violation alerts so that I wouldn't miss something important.
In this post, I'd like to share my most recent home lab project - a nested OpenVPN server. I refer to it as nested, because it is running completely within my desktop computer. See the illustration below.
The idea for this project came along when I working on setting up a VPN with my older Linksys router. Basically, I wanted to come up with a way to run a home lab VPN server without requiring any additional hardware, and I wanted to incorporate virtualization into this project. In addition, running it as a VM allows for fairly safe and controlled experimentation, without running the risk of bricking one's router with non-standard firmware.
