VMware View

A glimpse of things to come? … PCoIP at 30,000 feet

Feb 8th

Posted by Aaron Sweemer in VDI

View Comments

I’ve got to tell you, I’m pretty darn excited right now.  Why?  I’m typing this to you from 30,000 feet on a Delta flight from Cincinnati to Las Vegas (for VMware Partner Exchange).  And why is that so special?  Because, as the title suggests, I’m typing this on my VDI image which resides hundreds of miles away and thousands of feet below me.

Delta has a fairly new service from gogo called “gogo inflight … wi-fi with wings.”  This is my first time using the service because the past few flights I’ve taken, I’ve either not had the need to connect or the aircraft I happened to be on did not yet have the service.  But this time I have some work to do (i.e. my next “confessions” article for VSM), so I figured I’d give it a whirl.  And, being a gluten for punishment, I decided to see if I could push the limits of PCoIP.  After a quick sign up form (gogo isn’t free) and firing off a VPN connection back to my home office, I launched the View client and crossed my fingers.

And I can tell you that I am thoroughly impressed!  The Windows are snappy, flash is decent and low-end multimedia is adequate.  I was watching a youtube.com video with full sound and, while the picture was a little blurry and sound/video sync was slightly off, it was totally watchable.  And furthermore, it didn’t cripple my session.  Not bad, considering my latency is between 150ms and 250ms, with an estimated average about 200ms.

Is this a glimpse of things to come?  Right now it may seem pretty far fetched.  After all, the process to connect to my desktop image was fairly painful.  I had to …

  1. Boot into my local OS
  2. Connect to the gogo inflight wireless access point
  3. Launch my Firefox browser and walk through the gogo signup form
  4. Dig trough my briefcase for my wallet and pay for the service
  5. Fire off my OpenVPN client to my home VPN server
  6. Launch the VMware View Client

Not exactly what I’d call a seamless user experience.  And I believe that conquering this experience – that is, the mobile user – will be the coup de grace for traditional desktop infrastructure.  Until then, virtual desktop infrastructure will certainly happen in pockets, but massive, wide scale adoption will continue to elude us.  So what has to happen here?  In my mind, I see the following things need to happen …

True ubiquity of wireless Internet

This means two things.  First, the Internet has to be everywhere at all times.  I’m a true mobile user and I need to know that no matter where I am – whether it be on a puddle jumper, or in a remote country hotel – that when I power on my laptop, I will have access.

And second, this also means the connection to the Internet has to be completely integrated and transparent.  I don’t want to have to dig for my credit card every time.  But even more than that, I want the connection to happen for me automatically, in the background, as part of the boot processes.  My software client should auto detect the available wireless networks, connect, and debit my account.  Will I have a single unified account that works across all providers?  Or will I have multiple accounts that my software client will handle?  Or will it be a single, wireless / satellite provider that can reach me anytime, anywhere?  I don’t know and I don’t really care.  The point is, I don’t want to deal with it.  I want to press power and, after a short boot (maybe even zero boot?), have access.  Period.

A  purpose built Thin OS

Booting into a local OS just to launch a client and connect to a remote OS just isn’t going to cut it.  The boot process needs to be fast and do nothing more than present me with a login GUI.  If I’m remote, the VPN connection (and any necessary login parameters) need to be part of the login process.  There’s no need for a full blown local OS if our goal is to do little more than connect to our primary desktop environment.  Sure, us hardcore tech weenies will almost always want some sort of backdoor access to the local OS.  But for 99% of the users out there, they don’t care and just want a seamless desktop experience.  In fact, if done correctly, they shouldn’t even know there is a local OS and their desktop is actually running in a remote datacenter.

Does this actually exist yet?  Sort of.  ThinClients typically deliver this kind of user experience.  But for the most part, ThinClients aren’t mobile devices.  I’ve seen a ThinClient laptop model before, but I don’t know a single person actually using one.  I’ve actually seen for more cases of customers converting PCs and laptops to ThinClients.  Theron Conrey gives us a great example with his blog post VMware View Linux Live CD How-to.  And there are enterprise solutions for converting PCs to ThinClients from both Wyse and DevonIT.  So, we’re pretty darn close on this front, but still not 100%.

A rich user experience in low bandwidth, high latency environments

Like I stated earlier, my current PCoIP experience is pretty darn impressive.  It is, by far, the best experience I’ve witnessed to a remote desktop.  But, I’m not sure the average in-flight user would be ecstatic about it.  Sure, all things considered, you can’t beat it.  But I recognize all the variables working against me right now.  The typical user will not know or even care.  They just want it to work.  The good news is that PCoIP will continue to improve and brings the promise of delivering a rich user experience, whether at 30k feet of a single switch port away.

So, I ask again, is this a true glimpse of the not-too-distant future?  Ten years ago, I was the only one of my friends and family to have a cell phone.  Five years ago, mainstream virtualization in the datacenter was laughed at.  And a few short months ago, typing this blog post on my VMware View image was impossible.  So, you tell me.

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

,

A handy new addition to the Command Line Tool for View 4

Dec 8th

Posted by Aaron Sweemer in Managing Virtual Infrastructure

View Comments

First things first

Thanks to Scott Sauer (@ssauer) and John Blessing (@vTrooper) for holding down the fort here at Virtual Insanity while I’ve been finishing up some unfinished projects and preparing for the VCDX Design Exam (which I take later this month).  One of Scott’s posts actually won a vSphere blog contest.  Nice work Scott!  These two guys are becoming pretty good friends of mine here in the Cincinnati area, so hopefully I can convince them to keep the content flowin’.

An itch I couldn’t scratch

I’ve mentioned here on this blog, at least once or twice, that I “eat the dog food” and actually run my primary XP desktop as a VMware View image.  Since the conversion almost a year ago, everything has been running pretty well with only a few minor bumps along the way.  And with the recent addition of PCoIP, I can’t imaging ever going back.

But there was one little reoccurring problem I was having for which I couldn’t seem to find an answer.  It wasn’t a show stopper of an issue, but it was just an “itch I couldn’t scratch,” if you know what I mean.  And the problem went something like this …

  1. Inside my desktop VM I have a Cisco VPN client, necessary for a secure connection back to corporate HQ in Palo Alto, CA. 
  2. When connecting to my desktop with the VPN client inside the VM inactive, I had no issue.
  3. However, if I disconnect from my desktop while the VPN session was active, then I couldn’t reconnect to my desktop via VMware View. 

The reason?  The broker was sending me the new IP address of the Cisco VPN Adapter, which is an IP address on the VPN, and an IP address my local computer didn’t know about. 

Now, if I were to log off instead of disconnect from my desktop, this would terminate the VPN session and therefore wouldn’t be a problem.  But who wants to log off every time?  More often than not, I have things open on my desktop (e.g. half written emails, documents, browsers with many many open tabs, etc.) that I don’t want to bother saving and closing every time I step away from the computer.  And really the bigger issue is with unintentional disconnects that result from local power/network/OS issues.

I tried all sorts of things to fix this.  Among other thins, I tried …

  1. Reordering the NICs, hoping the broker was just grabbing the first NIC. 
  2. Poking around the broker and agent install files, hoping to find a way to force the IP address. 
  3. I even tried uninstalling and reinstalling the View agent and the Cisco client, hoping the order of installation might do the trick (admittedly, this was a random shot in the dark)

But nothing seemed to work.  So until recently, to reconnect I would have to connect directly to my desktop via RDP, or connect to the console via the VMware Infrastructure Client, then disconnect the Cisco VPN and then reconnect via the View client. 

See what I mean?  Not a show stopper, but man what a pain in the butt! 

The solution

Well I found a way around this with a handy new addition to the Command Line Tool in View4.  Check out page 12 of the Command Line Tool for View Manager titled “Override IP Address.”  On the broker from a DOS prompt, in the c:\Program Files\VMware\VMware View\Server\bin directory, execute the following …

vdmadmin.exe –A –d <desktop name> –m <machine name> –override –i hostname

The “desktop name” is the name of the VM in the broker.  The “machine name” is the name of the VM in vCenter.  It’s likely they’ll be the same, but they don’t have to be and in fact, in my case they weren’t the same.  The “hostname” can be either a FQDN or an IP address.  Oh, and I can tell you that all parameters must be present or the command won’t execute. 

But that was all there was too it.  Now I can disconnect and reconnect to my desktop, regardless of the state of my VPN client.

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

, , ,

A few of my favorite things from VMworld2009, so far

Sep 2nd

Posted by Aaron Sweemer in VMware

View Comments

I’ve been here at VMworld2009 in San Francisco since Sunday.  Monday was Partner Day and marked the unofficial first day of the event.  Yesterday, however, was the actual first day, open to all attendees.  There is much coverage of the event by numerous bloggers, so I won’t reinvent the wheel and bore you with duplicate content.  Instead, here are a few of my favorite things, so far (we’ve to two more days).  Oh, and this is by no means a complete list.  there are a LOT of cool things happening here and I don’t have the time and/or energy to write about all of them.

John Troyer Streaming Live from the Solutions Exchange

First, I often find myself watching John Troyer’s live coverage from the Solutions Exchange.  Which is weird because I could literally walk there in about 2 minutes.  But when I’m in my room in between meetings, it’s nice to have it on in the background so I can listen in on all the stuff I’m missing.  And John has been interviewing some very cool people.  

Check it out here … http://www.ustream.tv/channel/vmworld

 

vCloud Express

The vCloud Express is …

The VMware vCloud™ Express service delivers the ability to provision infrastructure on-demand, via credit card, and pay for use by the hour. As a VMware Virtualized ™ service, it ensures compatibility with other VMware environments both internally and with external services.

(Taken from http://www.boche.net/blog/index.php/2009/09/01/vmware-announces-vcloud-express/)

VMware actually demoed vCloud Express with Terramark, one of the service providers in the program.  It was pretty slick to see them simply add some user and credit card information and then spin up a VM quickly and easily on stage. 

Now that I’m having serious power problems in my house because of my home lab (hence the reason this blog keeps going up and down), I really think I’ll be using vCloud Express very soon.

 

SpringSource

VMware’s acquisition of SpringSource was actually announced weeks ago, but this was the first time there was really any lengthy discussion about it.  Frankly, the SpringSource acquisition is probably the thing that I am most excited about.  And I personally believe it will play a significant role in VMware’s future.  There is actually a lot of things I’d like to say about this, but will save it for a later post.

 

Running VMware View / RDP sessions on your iPhone with the Wyse Pocket Cloud client

Given the fact that I “eat the dog food” and actually run my VMware corporate desktop as a VMware View image, and I am also an iPhone user, I think this is super slick and something I know I will use …

 

A Shameless Plug

The folks over at Virtual Strategy Magazine have asked me to do a video blog of the event.  Our first recording was last night and I would guess they’ll have it posted sometime today.  When it’s up on their site, you can find it here … http://www.virtual-strategy.com/VMworld-2009.html

Also, if you’re here at VMworld and undecided about your Thursday schedule, why not come to my session?  :)   I’ll be presenting at 10AM in room 135.  The topic?  How to convert old PCs to thin clients using a Linux OS and the VMware View Open Client.  Hope to see you there!

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

, , , ,

Notes from VMware (aka, Mr. Michael White’s Newsletter)

Aug 26th

Posted by Aaron Sweemer in ESX

View Comments

I wish I could take credit for the following work, but everything below is brought to you by Michael White.  Michael is a co-worker of mine, an SE out of Canada who we often refer to as the “SRM King.”  He continually impresses me with his ability to crank out a weekly news letter loaded full of great content.  Well last night, he happened to mention I could republish his work on my blog.  Shoot, you don’t have ask me twice!

Keep in mind as you’re reading, everything is a direct cut and paste.  So anything written in the first person (e.g. “I have found …” or “I have decided”) would be referring to him, not me.  I certainly don’t want to take credit for all his hard work! :)  

If you have any questions or comments for Michael, feel free to leave a message for him.

 

Notes from VMware:

Cluster BP, FT and Issue, HA Issue, vDS Cheat Sheet, vDR Issue, YAPOTAV, vSphere Reference Card, View Design BP, SRM FAQ, and really a LOT more!

 

vSphere Cluster – ESX or ESXi or Mixed – suggestion / recommended best practice

We say that one day that ESX will not exist, and that ESX and ESXi are the same.  Or almost the same.  However, I have found in Host Profiles and FT there is very good reason to not mix ESX and ESXi in the same cluster.  As soon as VMworld is over, I am redoing my mixed cluster to all ESXi (instead of mixed).  First, we all know of the problem I reported some time ago that the 8/6/09 patches for vSphere would break FT in a mixed ESX / ESXi cluster.  There is no short term solution for that. The workaround is to have a cluster that is all ESX or all ESXi.  Second, host profiles have a problem dealing with service console / management network ports.  In theory you can manage that by using a reference server that is ESX and it will translate as necessary for ESXi.  It doesn’t do so well at that.  So using Host Profiles to do a push of a distributed virtual switch (only) ends up causing issues in ESXi consoles.  I ended up doing the ESXi hosts manually.  The real solution to the FT and HP type issues is to have a cluster all ESX or ESXi.  And I am voting for ESXi in my lab.  Make no mistake, if you don’t listen to this you will have some issues that are not pleasant.

 

Using ESXi and ESX and FT in same cluster?  And FT broke with the 8/6/09 patches?

The only solution to this at this time is to separate your ESXi and ESX servers into their own cluster, or upgrade one or the other to be the same as the other – meaning all ESXi or ESX and your problem should go away.  If you have not installed the 8/6/09 patches yet, and you are using FT, and you have ESXi and ESX in your cluster than either change your cluster to be all ESXi or ESX and than install the patches.  Not installing the patches until we fix this is NOT an option.  I have decided, and as mentioned somewhere else in here, to redo my cluster as all ESXi.  It won’t take much time.  Some background on this issue can be found at http://communities.vmware.com/message/1335428#1335428.

Update on odd issue with HA not working if the vSphere ESX console was using certain IP addresses

I hope everyone has already heard that the vSphere bug talked about in http://kb.vmware.com/kb/1013013 and something I mentioned, I think in my last newsletter now has a patch. This is the bug that when a very specific IP address scheme is in use on management ports / service console with no other IP schemes in use and a host crashed, the VM’s that should have been started by HA would in fact not be started at all.  I have not tested the fix, as I am wrestling with SRM and trying to get ready for VMworld.  To avoid this bug, only one of the addresses on your service console or management ports need to be using something outside of the ‘special’ scheme.

vDS Implementation Cheat Sheet

I worked with the distributed switches in the past in a lab sense, but recently. For my future SRM testing, I got it going for real in my lab.  And it was hard, confusing, and not intuitive at all.  So I wrote a cheat sheet so you would not have to suffer.  It is attached.  I have used it a few times and am happy with it so hopefully it will make things quicker and easier.  Let me know if you need improvements or changes in it.  http://www.virtualinsanity.com/wp-content/uploads/vDS-Implementation-Cheat-Sheet-b.pdf

Data Recovery Issue – which stops backups from happening

If you ever have an issue with writing to your destination when doing backups, you may see the restore point in red with a (Damaged) beside it.  This can cause your backup to not work again.   The events part of the Reports will show file access errors – 3902.  The solution to this is not in the documentation for vDR but it is here. Expand the display of restore points to be bigger than the default 5.  I used 25 when I had this issue.  Now click all of the restore points that show as damaged.  Then select the Mark for Deletion button in the top right of the screen.  Now change to the Configuration \ Destinations screen and select the destination that is associated with your backup, and use the Integrity Check option near the top right of the screen.  It will take a while.  Once it is complete with no errors – check the Events view of Reports – you need to restart the appliance.  Now your backups should work!

YAPOTAV – Yet another post on why to attend VMworld

Find this at http://blogs.vmware.com/vmtn/2009/08/yapowtav-yet-another-post-on-why-to-attend-vmworld.html.

New vSphere document reference card

Forbes Guthrie has done a wonderful job on a reference card for vSphere documentation stuff.  It pulls stuff out of the documentation and highlights it as a result.  Very handy and well done.  Find it at http://www.vreference.com/public/vsphere4-notes1.0.pdf

View Design Best Practices training

Would you like to learn more about designing a View infrastructure?  The more people you have that depend on it the more important training and experience becomes.  Get some ideas on design at http://mylearn.vmware.com/descriptions/EDU_DATASHEET_ViewDesignBestPractices_V3.pdf

SRM FAQ online now thanks to Duncan at Yellow-Bricks

This is from information I have shared with Duncan but it is great information and I appreciate him sharing with everyone.  Find it at http://www.yellow-bricks.com/srm-faq/.  Duncan’s web site is one of the few you should read frequently. He is a PSO guy in Europe and is very smart, and knows what to communicate – does it real well and I appreciate it.

 

vSphere and VM snapshots and block size

This is something else that Duncan has done.  There is a behavior difference between 3.5x and 4.0 that could catch someone.  Find out more from Duncan at http://www.yellow-bricks.com/2009/08/24/vsphere-vm-snapshots-and-block-size/.

VMware View Cheat Sheet

I have had some help to update my VMware View Cheat Sheet and it has gone very well.  Our next update of this will have a lot more but this is a good document to get you going with View.  www.virtualinsanity.com/wp-content/uploads/VMware-View-Cheat-Sheet-a.pdf

 

Important patch for Celerra when using NFS with VMware

You can find more information about this at Virtual Geek, but it is important to understand that you need to upgrade your Celerra DART OS before you enable NFS datastores with VMware.  Find out more at http://virtualgeek.typepad.com/virtual_geek/2009/08/important-patch-for-celerranfsvmware.html

Lab Manager 4 Upgrade issue

The installer during an upgrade of LM4 assumes all the default roles are present and unmodified.  If the customer removes or changes any the upgrade installer will fail.

FT – Architecture and Performance

Do you know how to determine how many FT enabled VM’s your vSphere server can support?  Do you know how to design your FT environment for the best performance?  In fact, do you know what the performance overhead for FT is?  All of this and more is answered in http://www.vmware.com/resources/techresources/10058.

How can I determine the exact build number for my ESX 4.0.x hosts?

You can find out the way to determine the build numbers for components of ESX 4.0 hosts at http://kb.vmware.com/kb/1012514

VMware Data Recovery Evaluator’s guide

This is a very nice document for someone who needs some guidance for testing VDR.  It is a quite way to get started.  http://www.vmware.com/resources/techresources/10055.  My preso on VDR at VMworld is a combination of install / config / best practices and it will be very useful.  Look for the session, or the preso after VMworld.  It will fit with this eval guide nicely and is known as BC2142.

 

AppSpeed and Maintenance Mode

Currently AppSpeed has no when to listen to the ESX host it is working on, so when the host tries to enter Maintenance mode it will not be able to since the AppSpeed sensor VM will not listen to it and it will not VMotion off the host.  This is a very high priority for us to fix. You will need to manually turn off this sensor before trying to do maintenance mode.
Need some help searching the VMware KB?  Find it at http://xtravirt.com/xd10112 – some interesting info.

NFS Storage Configuration Help

Do you need some help configuring NFS support for your ESX servers.  There is some help at
http://communities.vmware.com/docs/DOC-7900.  This link has only a little info but it does include some troubleshooting info.

VUM and Cisco – conflict message

I got a conflict message from VUM when I tried to patch recently.  It was a conflict with the Cisco Nexus stuff which I do not have installed.  It turns out that I could just ignore it but it was a little bothersome.  We are going to change that message in the near future to be more informative.  That way if you know you don’t have Cisco (or whatever) installed you can just install with no issues.  The issue is we download all the meta data or patches for ESX without any granularity. So the Cisco patches come done too.  More info can be found at http://kb.vmware.com/kb/1013068.

Suggested VMware Employee Sessions at VMworld

This is a list that one of my co-workers put together. It might give you some ideas of what to look for. 

  • Michael White – BC2142 – Data Recovery intro and best practices
  • Tiffany To – DV1790 – View TCO-ROI expert
  • Mahesh Ramachandran – VM1724 – Capacity IQ Tech Preview
  • Chris Rimer – EA2342 – Oracle sessions (especially around questions of Support and Licensing)
  • Richard McDougall – TA3438 – vSphere Performance Guru
  • Jacob Jensen – TA2103 – Virtual Networking guru (especially around the Cisco v1000)
  • Andy Banta – TA3264 – iSCSI Best Practices (THE iSCSI Engineer/Expert at VMware!)
  • Kaushik Banerjee – TA2942 – Performance Best Practices (This guys is a genius in performance and on the Perf. core team!)
  • Paul Manning – VM3566 – Storage Best Practices (Many of you have been on calls with Paul for storage related topics!)
  • Brian CS, Charu Charubal, and Rob Randell – VM2847, TA2544, DV2626, – Security Team extraordinaire
  • Mostafa Khalil – TA2509 – Storage Best Practices (Mostafa is one of the first VCDX members!)
  • Amir Sharif – TA3195, V13226 – ESXi PM – ESXi sessions
  • Monica Sharma – VM2408 – ConfigControl Tech Preview
  • Bill Call – VM2657 – LifeCycle Manager Uber-Guru!
  • Dean Flaming and Travis Sales – DV2478 – ThinApp (These are some of the best sessions I have ever seen historically from these guys!)
  • Gaetan Castelein – EA3605, EA 3606 – Virtualizing Tier 1 applications –
  • Srinivas Krishnamurti – VM2280 – Managing VI from your mobile phone! :)
  • Duncan Epping – TA2259 – Expert VI Design (Duncan runs the #1 Virtualization blog “Yellow-Bricks”)
  • Dean Yao – BC3369 – FT Real World design
  • Howie Xu – TA3521 – vNetwork Troubleshooting (Howie invented the vSwitch! – and wrote one of our TCP/IP stacks)
  • Banjot Chanana – BC3425 – High Availability Futures
  • Nicholas Jacques – PA4694 – AppSpeed PM
  • Eric Horschmann – TA3880 – vSphere vs Hyper-V/XenServer
  • Warren Ponder – DV2697 – View /VDI PM
  • Mike DiPetrillo – TA3326 – Cloud (Mike is another uber-rock star and talks all things Cloud!)
  • Rahul Ravulur- -VM4380 – vCenter PM covering future of vCenter
  • Naeem Malik – VM3609 – Capacity Planner expert
  • Aaron Sweemer – DV3567 – How to convert old PCs to Thin Clients using a thin Linux OS and VMware View Open Client.

**** Reminders ******

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

, , ,

The E.T.D.F. Series – Setting up the Network and Dedicated Remote Access (Part 3)

Jun 8th

Posted by Aaron Sweemer in Dynamic DNS

View Comments

    OK, we are *almost* done getting our network set up properly for VDI, but we’ve got a few more things to do.  Specifically, we need to address:

  1. Handling our external, Internet facing, dynamic IP address.
  2. DHCP and DNS
  3. External VPN access

Dynamic External IP

Most ISP’s (not all) provide a single, dynamic IP address for consumer grade service (i.e. home use).  But when we’re trying to connect to our virtual desktops from somewhere out on the public Internet, how do we know which IP address to connect to?

Generally speaking, connecting to an IP address is bad practice because it’s inflexible.  Instead, we should connect to a Fully Qualified Domain Name (FQDN).  OK fine, so we’ll set up a DNS entry and use a FQDN to connect to our desktops.  But what happens when our dynamic IP address changes and the DNS entry is still mapped to the old IP address?

What we need is an external Dynamic DNS (aka DDNS) service which will allow us to programmatically update our IP address whenever it changes.  There are a number of both free and paid-for DNS providers out there that can deliver DDNS services.  Personally, I use EditDNS (www.editdns.net).  They have a ton of functionality and they’ve been rock solid for the past few years I’ve been using their services, so I’m quite happy with them.

Now, many home use routers these days have the capability to update a DDNS provider.  But in my experience, the functionality is somewhat limited.  What if, for example, I want aaron.sweemer.com and desktop.sweemer.com to be dynamic entries and www.sweemer.com to be a static entry, pointing to my blog server hosted somewhere else?  In reality, I’ve got about 20 FQDN’s that I need to be dynamically updated and about 100 that I want static.  So instead, I created a script that will:

  1. Query my external IP address (check this out, a free tool from Whatismyip.com)
  2. Compare the result of the query with the IP obtained from the previous query
  3. If the IP is the same, or contains something other than an IP (e.g. HTTP error), the scirpt exits.
  4. If the IP is different, the script updates my DDNS entries via the EditDNS API, then updates a log file documenting the change, and finally adds the new IP to the last line of a file called previous_ips.

If you’d like to use the script I wrote, you’ll first need to do the following:

  1. If don’t already have one, set up an account with EditDNS and make sure you have properly configured the domain name(s) you own.
  2. Verify your linux distro has lynx (a command line, text only, www client)
  3. Verify your linux distro has curl (a tool to transfer data using HTTP)
  4. Create a directory (anywhere you have rwx access is fine) for the script and its files to live
  5. In this directory, create a text file called editdns.sh.  Paste the content (below) into it.
  6. Replace XXXXXXXX with your EditDNS password.
  7. Make editdns.sh executable (chmod +x /path/to/editdns/editdns.sh)
  8. Create another text file called records and, one per line, enter the FQDN’s of the DDNS entries you wanted updated (e.g. mydesktop.mydomain.com)
  9. Add the editdns.sh script to your crontab to run at regular intervals (e.g. mine runs every five minutes and the entry in cron looks like this:    */5 * * * * cd /usr/local/editdns; ./editdns.sh)
    And here’s a copy of the actual script …

#!/bin/bash

EDITDNSPASS=”XXXXXXXX”
LYNX=`which lynx`
TIME=`date`
CIP=`curl -s http://www.whatismyip.com/automation/n09230945.asp | awk –re-interval ‘$1 ~ /^([0-9]{1,3}\.){3}[0-9]{1,3}$/ {print}’`
PIP=`tail -1 ./previous_ips`

if [ "$CIP" != "$PIP" && –n "$CIP" ]; then
cat ./records | while read FQDN; do
$LYNX -source “http://DynDNS.EditDNS.net/api/dynLinux.php?p=$EDITDNSPASS&r=$FQDN”
done
echo “IP Change!  New IP is $CIP.  Editdns.net was updated at $TIME.” >> ./editdns.log
echo $CIP >> ./previous_ips
else
exit 0
fi

If you have any issues or questions, feel free to email me.  Also, keep in mind, this a quick and dirty script that accomplishes what I want it to accomplish.  Feel free to make it more robust (e.g. error handling or better logging) to suit your needs.

DNS and DHCP

It’s quite possible you’ll want to skip this section and opt for setting up DHCP and DNS via Microsoft’s built in DHCP and DNS services that come out of the box with their server products.  To properly set up VMware View, we’ll need to set up Active Directory anyway, and quite frankly, it’s far easier to set up a Microsoft server with DHCP and DNS than it is to set up a Linux server.  So feel free to skip this section and leverage Microsoft for these services.  If, however, you’re a gluten for punishment then by all means, read on.

Let’s first start with DNS.  Here too we need Dynamic DNS because as we’re handing out IP addresses via DHCP, we want our DNS server to properly reflect current information as IP addresses change.  So, if you don’t already have bind9 (the DNS server), go ahead and install it (sudo apt-get install bind9 should work on Ubuntu / Debian distros).

The default configuration for bind9 is to act as a caching server, so the first thing we need to do is configure our DNS to forward all unknown DNS requests to another DNS server.  These should be provided to you from your ISP.  Edit the forwarders {} section of your named.conf.options file (usually located in /etc/bind/) to look like this …

asweemer@cincylab-rtr1:/etc/bind$ more named.conf.options
options {
directory “/var/cache/bind”;

forwarders {
1.2.3.4;
5.6.7.8;
};

auth-nxdomain no;    # conform to RFC1035
listen-on-v6 { any; };
};

Obviously, you’ll need to change 1.2.3.4 and 5.6.7.8 to the IP addresses given to you by your ISP.

Next, we need to modify our master named.conf to allow dynamic updates to DNS.  Add the following entry to the bottom of your named.conf file.

controls {
inet 127.0.0.1 allow {127.0.0.1; 192.168.9.25; 10.10.7.1; 10.10.7.2; } keys {“rndc-key”;};
};

This tells the DNS server to allow updates from the IP address located between the {}.  Notice the first three IP addresses are local IP addresses.  The fourth IP address is a slave DNS server, which I have yet to set up.  The rndc-key is the default key generated during installation of bind9 and it’s used to authorize the updating of DNS records.  If you’re using Ubuntu, then you’ll likely find the key in the file /etc/bind/rndc.key …

asweemer@cincylab-rtr1:/etc/bind$ sudo cat rndc.key
key “rndc-key” {
algorithm hmac-md5;
secret “QZ5jOmcr/OW3nzksR5q0Hw==”;
};
asweemer@cincylab-rtr1:/etc/bind$

Note the file is a text file named rndc.key, and the actual key is called rndc-key located within the text file.

OK, next we need to define our zones in the named.conf.local file.  For each domain you’re using (probably just one), you’ll need two entries:  one for the domain and one for the reverse lookup of the domain.  I have two domains I’ll be updating, so my named.conf.local file looks like this …

asweemer@cincylab-rtr1:/etc/bind$ cat named.conf.local
//
// Do any local configuration here
//

include “/etc/bind/rndc.key”;

zone “mydomain.com” {
type master;
file “/etc/bind/zones/mydomain.com.db”;
allow-update { key “rndc-key”; };
allow-transfer {10.10.7/24; };
};

zone “7.10.10.in-addr.arpa” {
type master;
file “/etc/bind/zones/rev.7.10.10.in-addr.arpa”;
allow-update { key “rndc-key”; };
allow-transfer {10.10.7/24; };
};

zone “dmz.mydomain.com” {
type master;
file “/etc/bind/zones/dmz.mydomain.com.db”;
allow-update { key “rndc-key”; };
allow-transfer {192.168.9/24; };
};

zone “9.168.192.in-addr.arpa” {
type master;
file “/etc/bind/zones/rev.9.168.192.in-addr.arpa”;
allow-update { key “rndc-key”; };
allow-transfer {192.168.9/24; };
};

A couple points to note here:

  • I created a subdirectory called “zones” under /etc/bind/ where I put all my zone files.  This isn’t the default location, and in addition, this isn’t necessary as the zone files can be located anywhere you’d like.  But be aware the configuration file above reflects the location of my files.
  • Notice the include “/etc/bind/rndc.key” on the first line and the all-update directive within each zone definition?  This should be self explanatory at this point.
  • The allow-transfer directive within each zone definition explicitly limits zone transfers (copy) to the IP(s) defined.  This is an important security feature since, by default, DNS allows transfers to anyone, and the info contained within a DNS zone file can really give hackers visibility into your network.

Now we need to create the zone files we just defined above, which will contain our actual DNS records.  Here is the zone file for our dmz.mydomain.com …

asweemer@cincylab-rtr1:/etc/bind/zones$ cat dmz.mydomain.com.db
$TTL 3600       ; 1 hour
dmz.mydomain.com             IN SOA  master.dmz.mydomain.com. root.master.dmz.mydomain.com. (
2009060514 ; serial
86400      ; refresh (1 day)
86400      ; retry (1 day)
2419200    ; expire (4 weeks)
3600       ; minimum (1 hour)
)
NS      master.dmz.mydomain.com.
NS      slave.dmz.mydomain.com.
A       192.168.9.25
MX      10 mail.dmz.mydomain.com.
MX      20 mail-spool.dmz.mydomain.com.
computer-1              A       192.168.9.247
TXT     “317bf41a2c5b70fd9ca4e283d364dcddd5″
computer-2              A       192.168.9.250
TXT     “00cf6242f693ebbf1d545159548e44ab81″
computer-3              A       192.168.9.243
TXT     “31a0cb7e096a96c63dc998d2db3be6e450″
mail                    A       192.168.9.25
mail-spool              A       192.168.9.26
master                  A       192.168.9.25
www                     CNAME   master

A couple important things to point out here:

  • The entries for computer-1, 2 and 3 are dynamic entries there were generated by the DHCP server.  The TXT record that follows these entries is a unique identifier which is also generated by the DHCP server and is used to ensure it won’t overwrite existing DNS records that were generated by another process/server.
  • You’ll obviously need to change the domain names and IP addresses to match your environment.
  • If you haven’t worked with bind9 before, this file probably looks pretty cryptic to you.  If so, I would recommend taking a look at http://www.zytrax.com/books/dns/ch8/soa.html, which gives a pretty good overview of the SOA (defined in the first part of the file).  The balance of the file (i.e. the record definitions) is pretty straight forward.

The reverse zone should look like this …

asweemer@cincylab-rtr1:/etc/bind/zones$ more rev.9.168.192.in-addr.arpa
$ORIGIN 9.168.192.IN-ADDR.ARPA.
$TTL    1h;
IN      SOA     master.dmz.mydomain.com. root.master.dmz.mydomain.com. (
2009060501      ;
1d              ;
1d              ;
4w              ;
1h              ;
)
IN      NS      master.dmz.mydomain.com.
 IN      NS      slave.dmz.mydomain.com.
25      IN      PTR     master.dmz.mydomain.com.
26      IN      PTR     slave.dmz.mydomain.com.

I mixed it up just a bit in this file to point out a few different ways to configure a zone file.  In this file, notice the following differences:

  • The $ORIGIN directive sets the domain name to be appended to any unqualified records.  If the $ORIGIN directive doesn’t exist (as it doesn’t in the first config file), then it is implicitly defined by the zone name.
  • The time variables can be defined with d (day), w (week), h (hour), etc.

That’s about it for DNS.  Once you’ve got your bind9 server configured, restart your bind9 server (sudo /etc/init.d/bind9 restart).  And of course, be sure to test your configurations by using the standard DNS tools (e.g. dig, nslookup).  If you get errors, pay careful attention to your local syslog file (probably located at /var/log/syslog) as that’s where DNS and DHCP errors typically write their error messages.

OK, next up is configuring our DHCP server.  And once again, this post is starting to get way to long, so it looks like I’ll need a fourth and (hopefully) final post to this section.

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

, , , , , ,

View 3.1 HID Filtering

Jun 5th

Posted by Rick Westrate in VMware

View Comments

With the release of View 3.1 we received some more flexibility with presenting/hiding Human Interface Devices  (think foot pedals for a transcriptionist, some type of bardcode scanners, etc).

HID devices are filtered out by default as it would be a bad thing if your local mouse was redirected for example.  So to enable a specific device to be passed through we need to do a few things:

1:  First we need to determine the VID/PID of the HID device.  There are two ways to determine this:

a:  Debug Logs:  Go to C:\Documents and Settings\All Users\Application Data\Vmware\VDM\logs.  Search through the log for “Devices”  This will contain the information of all the devices available before filtering takes place

b:  Windows Device Manager:  Open Windows Device Manager and find the HID device you are interested in.  If you right-click–>Properties on the object and go to the Details tab you will see a drop down.  Choose Device Instance ID from the drop-down.  The VID/PID value will be displayed.  Usually this looks something like USB\VID_xxxx&PID_xxxx\…

2:  Now that we know the VID/PID we can go to the client and create the appropriate registry keys to tell the View Client to pass that particular HID device through:

a:  Go to HKLM\Software\VMware, Inc.\VMware VDM\USB\

b:  Create a new Multi-String Value named AllowHardwareIDs

c:  Set the value data to the VID_xxxx&PID_xxxx you documented earlier

d:  Restart the client and things should work upon the next connection

Special Thanks to Pete Barber for this info!

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

, ,

The E.T.D.F. Series — Setting up the Network and Dedicated Remote Access (Part 2)

Jun 2nd

Posted by Aaron Sweemer in E.T.D.F. Series

View Comments

I got up early to get some work done before driving down to KY to work with a customer on their VDI pilot.  As I was preparing for the meeting, I thought to myself, “wow with my studies for the VCDX admin exam, and the recently launch of vSphere, I haven’t done a whole lot of VDI recently.”  And then BAM!  It hit me like a ton of bricks.  I haven’t completed the E.T.D.F series I started almost 6 months ago!  If this blog has done anything for me, it has made me painfully aware of my numerous character flaws. <sniffle><tear><sniffle>

Anyway, not that anyone is following along anymore, and purely in the interest of self improvement, I’m determined to finish what I’ve started (both for this series and my VCDX study notes series).  So without further delay, here is the second part of the networking section (here is part one).  And for your convenience, here again is the Visio diagram of my lab.

Router / Firewall (cincylab-rtr1)

In my environment, the vast majority of all relevant network configurations are on cincylab-rtr1, which is really an old Gateway PC that I had lying around with a single 2.2GHz processor and 1Gig of RAM and a single 100Mbps NIC.  I installed Ubuntu server 8.04.1 (kernel 2.6.24-19-server) on it and made it the gateway between my lab and the DMZ (aka, my home network).

The first thing I needed to do was get the basic networking on the server set up.  I have three networks in my house …

  1. An external DMZ, VLAN 192 (aka, my home network)
  2. An internal “production” network, VLAN 10.  I put the word production in bunny ears because nothing is *really* production … it’s all just a lab.  But I try to protect this network a little more than the next.
  3. An internal “lab” network.  This is where I can really have fun!

Configuring the Interface(s)
The server only has one NIC and I was too lazy (and cheap) to go buy a new one.  But it’s a 1GigE card, which is plenty for my environment.  And it’s a snap to configure …

root@cincylab-rtr1:/etc/network# more interfaces

auto lo
iface lo inet loopback

auto vlan10
auto vlan192
auto vlan10:1

iface vlan192 inet static
address 192.168.9.25
netmask 255.255.255.0
gateway 192.168.9.1
mtu 1500
vlan_raw_device eth1

iface vlan10 inet static
address 10.10.7.1
netmask 255.255.255.0
broadcast 10.10.7.255
network 10.10.7.0
mtu 1500
vlan_raw_device eth1

iface vlan10:1 inet static
address 10.0.1.1
netmask 255.255.255.0
broadcast 10.0.1.255
network 10.0.1.0
mtu 1500
vlan_raw_device eth1
root@cincylab-rtr1:/etc/network#

Turn on Routing

Now that the interfaces are configured, we need to turn on routing.  In Linux, this can be accomplished a couple different ways.  The easies, IMHO, is to simply edit the /etc/sysctl.conf file and set net.ipv4.ip_forward=1.  You could also add echo 1 > /proc/sys/net/ipv4/ip_forward to your /etc/rc.local file.  Either way should turn on IPv4 routing on your server.

Configure NAT and PAT (Port Address Translation)

Once routing is turned on, we need to set up Network Address translation and Port Address Translation.  This needs to be done for two reasons.

  1. My lab networks need outside access to the Internet and they have private IP addresses.
  2. My server has a single IP address in the DMZ, which needs to serve as the gateway IP for multiple internal IP’s and TCP/UDP ports.  As an example, I want all traffic arriving on 192.168.9.25, TCP port 8080 to be forwarded to the internal IP 10.10.8.51 port 80.  And more specifically, here’s what I want available to the outside world …
    • 192.168.9.25:8080 –> 10.10.7.51:80
    • 192.168.9.25:8181 –> 10.10.7.51:443
    • 192.168.9.25:8282 –> 10.10.7.50:80
    • 192.168.9.25:8383 –> 10.10.7.50:443

    3. OK, so how do we do this?   We need configure iptables.  An iptables tutorial is out of scope for this post, but if you’d like to learn more about Linux IP tables, I personally like this one:  http://www.yolinux.com/TUTORIALS/LinuxTutorialIptablesNetworkGateway.html.

To set up iptables, I’ve created a file called fw_rules in /usr/local/bin and made it executable (chmod +x /usr/local/bin/fw_rules).  Here is what the file looks like.

root@cincylab-rtr1:/usr/local/bin# cat fw_rules
#!/bin/bash
iptables -t nat -F
iptables -t filter -F

iptables -t nat -A PREROUTING -p tcp -i vlan192 -d 192.168.9.25 –dport 8080 -j DNAT –to 10.10.7.51:80
iptables -t nat -A PREROUTING -p tcp -i vlan192 -d 192.168.9.25 –dport 8181 -j DNAT –to 10.10.7.51:443
iptables -t nat -A PREROUTING -p tcp -i vlan192 -d 192.168.9.25 –dport 8282 -j DNAT –to 10.10.7.50:80
iptables -t nat -A PREROUTING -p tcp -i vlan192 -d 192.168.9.25 –dport 8383 -j DNAT –to 10.10.7.50:443

iptables -t filter -P INPUT ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT

root@cincylab-rtr1:/usr/local/bin#

To make these changes persistent across reboots, you’ll need to add /usr/local/bin/fw_rules to your /etc/rc.local file.

Now, for all you linux experts out there looking at this file, you’re probably saying “uh, that’s a pretty insecure firewall you got there!.”  And you’d be right :)   Remember, this is merely an internal firewall/router which is protected by a much more secure, Internet facing, Cisco ASA (thanks again to the local Cisco team!!).  It’s also this Cisco that forwards outside connections on specific ports (not 8080, 8181, and 8282, for additional security) to IP 192.168.9.25.  And because of this, my goal for this server isn’t to protect, but to separate my lab networks from my home network, and proxy the connections between them.

What’s Next?
We’ve configured our networks, turned on routing and configured NAT / PAT on our server.  What next?  Three things:

  1. Because my external IP is dynamic, we need to set up a script that will periodically check to see if our external IP has changed and, if so, update our dynamic DNS service.
  2. Configure DHCP and DNS.
  3. Set up external VPN access.

Step three is actually optional because when we’re done, we’ll be able to tunnel via SSL to our desktop.  And from our desktop, we’ll have full access to the local LAN.  But sometimes full remote access via VPN is nice without being forced to first “hop” to another desktop.  So, I’ll include my VPN configuration as well.

But for now, it looks like I’m going to need have a part three of this “setting up the network and dedicated remote access” section, because I need to get on the road down to KY.  But if you’re interested, look for part three later today.  I’m almost done with it and will try to finish it during my lunch break.

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

, , , , ,

View 3.1 USB Redirection Improvements

May 28th

Posted by Rick Westrate in USB Over IP

View Comments

As you probably have seen, View 3.1 GA’d yesterday.  One of the improvements listed in the release notes was:

  • USB Improvements – View 3.1 offers more reliable and broader device support with reduced bandwidth consumption. A separate TCP/IP stream is used.

From what I understand in talking to some people is that a lot of time was spent on the USB redirection stack to further optimize and tune it.

ALSO, USB redirection traffic is now split out onto it’s own traffic stream.  USB redirection traffic will now communicate from the client to the host vm on TCP port 32111.  I imagine this opens up a few new opportunities to do some USB specific traffic prioritization/trottling.  Very interesting!   In previous versions, the USB traffic was inside of the RDP stream (virtual channel).  This prevented us from ever REALLY seeing the USB specific traffic or having any control over it.  Simply put, now we do.  Gotta love progress!

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

, , ,

The E.T.D.F. Series — Setting up the Network and Dedicated Remote Access (Part 1)

Mar 17th

Posted by Aaron Sweemer in E.T.D.F. Series

View Comments


Wow!  I can’t believe it’s been almost two months since my last post!  Sorry for my extended absence.  I’ve been super busy with VMware events, customer presentations and meetings … oh yeah, and there was a nice ski trip to Vail too.  Time flies when you’re having fun :)

Over the past few weeks, with the little spare time I had, I actually completed my conversion to a virtual desktop.  So now, my corporate VMware desktop is 100% in a VM, always on and "lives" on the virtual infrastructure in my home lab.  And with my shiny new AT&T 3G wireless laptop card, I can access it anytime, anywhere (though admittedly, this is a last resort).

You might have guessed by the title, for this post I’ll focus on my network setup.  I stress the word “my” because when I first started to write this section almost a month ago, I had a lot of trouble trying to address all possible network configurations (or at least, a good majority of them).  Finally I gave up, realizing this was an impossible task.  There are just way too many options.  So, I’m simply going to document my network.  If you have VDI network configuration questions that aren’t answered in this section, email me directly (aaron at sweemer dot com) and I’ll be happy to help out.

I think the best place to start would be showing you a high level diagram of my network (click the graphic to see the full image). 

 

cincylab_public 

As you’re reviewing the diagram, here are a couple things to keep in mind:

  • All IP addresses have been changed and domain names have been removed for security purposes.  Hostnames, however, remain unchanged.
  • You do not need to have a similar setup.  In fact, you can have as little as a single physical server with local storage.  You might not be able to get the full benefits that a fully loaded virtual infrastructure can provide (e.g. VMotion, DRS, HA).  But if you’re just looking to test out virtual desktops with VMware View, you can certainly go with a slimmed down environment.  
  • The configuration of the physical servers (cincylab-esx1, 2 and 3) as well as the iSCSI SAN (cincylab-ts1) will be addressed in the next section.
  • The ISP router is a fairly unintelligent device which I’ve configured to simply forward all network traffic to cincylab-rtr1.  As such, I won’t address the configuration here.

I love Visio diagrams, they make everything look so pretty and shiny!  What does this actually look like?  Here’s a photo of my lab …

cincylab_photo

 

Notice the PC on the right (cincylab-rtr1)?  That’s an old Gateway I had lying around, which has a single 2.2GHz processor, 1Gig of RAM and a single 100Mbps NIC.  I installed Ubuntu server 8.04.1 (kernel 2.6.24-19-server) on it and made it the gateway between my lab and the DMZ (aka, my home network).  It’s on this PC that I route between VLANs, terminate external VPN connections and run my DHCP server.  Additionally, it’s where I run scripts that continually scan for changes to my public IP address and when necessary, automatically updates my dynamic DNS provider.

Since this post is getting long, I decided to break this section into two parts.  In part two, I’ll walk through the all the configurations of cincylab-rtr1 and cincylab-sw1.  And before you say anything … no, it won’t be another two months before I post part two :)

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

, , , ,

VMware View Open Client

Feb 3rd

Posted by Rick Westrate in VDI

View Comments

So…that crazy, proprietary company, VMware, today released the first open-source VDI client! (Just a small jab) :-) It’s actually a very exciting event in terms of the possibilities it opens up. Already out of the gates, VMware has announced in the press release a bunch of different partners that are leveraging this View Open client in their own solutions (ChipPC, Novell, HP, Sun…). http://vmware.com/company/news/releases/view_open_client.html

The new View Open Client includes all the major components needed for someone to take the software, adapt it to their needs and package up a rich, customized solution. This should really assist all the players in the eco-system to reduce their time to market on solutions. I’m hoping this results in some new and innovative ways to deliver virtual desktops!

Another great use case that I hope we soon see more of are commercially supported (by the vendor and VMware), turn-key solution for turning your fat PC into a dumb, highly managed “thin client’. There are some solutions out there today, but I would think that this new View Open Client would allow someone to put together a package to do this easily with out-of-the-box View integration. The great part is, that a solution someone in the eco-system puts together using the View Open Client can be submitted to VMware for formal certification and support!

If you have some good ideas on how to apply this, have at it: http://code.google.com/p/vmware-view-open-client/

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

, , , ,
« Older Entries