Showing posts with label troubleshooting. Show all posts
Showing posts with label troubleshooting. Show all posts

Tuesday, September 6, 2011

How to ask a question in a technical forum

A friend of mine recently ran across this and forwarded it to me.

Personally, as a TechNet forum moderator, and frequent forum contributor, and as a person who handles a few forums for my employer; I find the information in this KB both lighthearted and highly useful at the same time.

http://support.microsoft.com/kb/555375

The title of the KB article:  “How to ask a question”

Please, check it out.

Thank you Daniel Petri!

Friday, April 8, 2011

Unable to ping Server 2008

I have blogged about this before and I will again as folks fall trap to this all of the time.

By default, ping response is disabled beginning with Server 2008 and continuing into newer revisions of Windows Server. 

FYI - With Server Core, ping is silent regardless of the state of the firewall.

Here is a great tip from Ben of the Hyper-V team:

The first thing I would do is to check the firewall configuration in your guest operating system, and make sure that it allows ICMP.

Here is a great article that steps you through how to do this:

“Nobody can ping my computer”

http://technet.microsoft.com/en-us/library/cc749323(WS.10).aspx

Friday, April 1, 2011

Getting Role Instance endpoint information from within an Azure VM

In a previous post I discussed the concepts of VM to VM communication in Azure.  The basics of how it works and where the knobs are to enable it.

Here is a little different focus.  It is the scenario that the endpoints have been defined, but your setup script that is installing or configuring your application needs to discover other roles and information about them because it needs to talk to them.

This is IPv4 traffic.  Most any application should know how to use this. 

I mentioned previously that name resolution is not available.  The other caveat is that I am not using Azure Connect (the Azure Virtual Network feature).  Connect gives name resolution, but it only gives me the IPv6 endpoint of the Connect VPN tunnel it does not give me the IP actual network IP addresses that my application wants.

So, PowerShell to the rescue.  To get you started I have this little PowerShell script that walks through my service, all Roles, and documents the endpoints that are enabled.

I run this on Instance A and I know where the open ports are configured on instance B.  I also use this to document my environment from within my environment by directing the output to a text file.

By the way, this is made possible by the Azure Service Runtime.  This is installed in VM Role VMs when the Windows Azure Integration Components are installed.  The hitch is that the VM must be in Azure for it to work, and you must be executing as Administrator.

<#
.SYNOPSIS
    A script to query the Azure Service Runtime and dump the endpoint configuration
    of all roles to a TXT file.
.DESCRIPTION
    This script is designed as a very simple troubleshooting tool for your VMs in Azure.
    It performs the very simple task of working through all Roles and Instances and
    writing the EndPoint configurations to a TXT file.
    This way when you are troubleshooting issues you have a quick document in the VM
    that you can reference to see what Internal EndPoints have been opened to
    facilitate VM to VM communication.
.LEGAL
    SCRIPT PROVIDED "AS IS" WITH NO WARRANTIES OR GUARANTEES OF ANY KIND, INCLUDING BUT NOT LIMITED TO
    MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.  ALL RISKS OF DAMAGE REMAINS WITH THE USER, EVEN IF THE AUTHOR,
    SUPPLIER OR DISTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF ANY SUCH DAMAGE.  IF YOUR STATE DOES NOT PERMIT THE COMPLETE
    LIMITATION OF LIABILITY, THEN DELETE THIS FILE SINCE YOU ARE NOW PROHIBITED TO HAVE IT.  TEST ON NON-PRODUCTION SERVERS.
.AUTHOR
    Brian Ehlert, Citrix Labs, Redmond, WA, USA
.REFERENCES
    Thank you TechNet. For examples.
#>

# declare the DumpInstance Function
function DumpInstance {
    param ($roleMem)
   
    foreach ($roleIn in $roleMem) {
    $i = ($roleIn.InstanceEndpoints.Count -  1)
    $roleIn.Role.Name + ", " + $roleIn.Id

    do {
    $keyName = $roleIn.InstanceEndpoints.Keys[$i]
    $endProtocol = $roleIn.InstanceEndpoints.Values[$i].Protocol
    $endPort = $roleIn.InstanceEndpoints.Values[$i].IPEndPoint.Port
    $endIp = $roleIn.InstanceEndpoints.Values[$i].IPEndPoint.Address.ToString()
    $endFamily = $roleIn.InstanceEndpoints.Values[$i].IPEndPoint.AddressFamily
   
    $endIp + ", " + $endPort + ", " + $keyName + ", " + $endProtocol + ", " + $endFamily
    --$i
    }
    until ($i -lt 0)
    ""
    }
}

# Add the Service Runtime snap-in to the standard Windows PowerShell command shell.
add-pssnapin microsoft.windowsazure.serviceruntime

# Get all Roles
$allRoles = Get-RoleInstance

foreach ($roleMem in $allRoles) {
    DumpInstance $roleMem
}

Tuesday, July 13, 2010

Is System Protection in a VM necessary?

I just happened to be working through the set-up of a new virtual environment and I was walking through my standard steps and it occurred to me that I always log in to my VMs and disable System Protection and delete any restore points.

I do this for a couple reasons.  One is to reduce the storage requirements of the VM, another is to just take that overhead out of the system.

I might be stilly for doing this, but it is one of the practices that I consider standard in my environments (as well as redundant and unnecessary). 

I mean, if I want to be able to restore my VM, don’t I use a snapshot (checkpoint)?  So, if I do that I have storage requirements, and then on top of that the OS in the VM is basically doing the same thing so it can roll itself back.

Actually, if i left it turned on it would give me the ability to pluck that patch back out when things go south and I forgot to take a snapshot.  It could be one of those stealth features that we don’t normally think about when managing VMs.  We always focus on what we can do at the hypervisor and forget what we can already do within the operating system of the VM.

Hmm..  Quite the puzzle.

I brought this up as it is something that just happened to pop into my head as being unusual, strange, not required, however strangely comforting.  You know, that whole ‘I do it my way’ type of thing for no right or wrong reason.

I would love to hear comments on this one.

Tuesday, December 22, 2009

Hypervisor virtualization basics a visual representation

For all of you that want a place to point folks to describe the basics of virtualization, I have put together a few videos to describe the hypervisor, CPU, and network concepts in a visual way.

The intent is to give a quick amount of conceptual information to those folks that suddenly are dealing with VMs, but might not have the experience to fully understand what they are looking at.

Hypervisor Basics:

The basics of what a full (type 1) hypervisor is.

 

The hypervisor pool of resources – the CPU:

The basics of CPU scheduling. It is far more complex than this and there are many methods.  It gets really messy when hyper-threading is introduced.

More CPU scheduling details are over at the Xen.org site (the Xen folks are more open in discussing the gritty details of all this):  http://wiki.xen.org/xenwiki/CreditScheduler

The hypervisor pool of resource – the network:

This is about virtual networks / virtual switches / bridging.  The concepts, as each vendor implementation offers different features.

Thursday, May 21, 2009

The layers to Linux on Hyper-V

Recently I have been seeing and getting many questions regarding the Linux Integration Components for Hyper-V virtual machines.

Through a bit of questioning, I have discovered a couple things, and distinct levels to running Linux VMs on Hyper-V.

Note: Since SuSE 10 SP2 is the ‘supported’ distribution, any instructions will be specific to it.

I am assuming that you have obtained the SuSE media and performed a ‘vanilla’ installation into a new Hyper-V virtual machine.

WARNING: Level One can lead to Level Two. And, always perform a backup / export / snapshot before proceeding. All usual disclaimers apply.

Level One – the beginning

This is a simple installation of just the Linux operating system within a Hyper-V virtual machine. The only caveat is that the VM needs a Legacy Network adapter for network connectivity.

In this case you will end up with a working Linux VM. It should auto detect an install an SMB (multi-processor) kernel and it should just work. The performance is not the best that it could be, but it should run.

Level Two – the path to enlightenment

This is the simple installation from above, with the addition of the Hyper-V Linux drivers.

This one is a bit more involved. However, the end result is that you are running the synthetic Network Adapter, and the optimized storage, and display (and other) drivers.

This optimizes drivers, but advanced integration features such as shutdown from the host (or SCVMM) is currently not available.

To obtain driver enlightenment:

a) Obtain the LinuxIC.iso

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ab7f4983-93c5-4a70-8c79-0642f0d59ec2#tm

b) obtain the inputvsc.iso for the mouse driver

http://www.xen.org/download/satori.html

c) add the kernel-source and gcc-c++ packages

YaST can be used for this, either GUI or command line

Note: if an ISO was previously attached, you may need to detach, pause, then attach the desired ISO for SuSE auto-mount to pick up the change.

If that does not work, make a mount point ( mkdir /media/CDROM ) and mount /dev/hdc /media/CDROM

d) Install the linuxic drivers

a. Open a Terminal

b. attach the downloaded LinuxIC.iso through the Hyper-V manager

c. Create a folder and copy the contents to the folder

d. mkdir /tmp/linuxic

e. cp –rp /media/CDROM/* /tmp/linuxic

f. cd /tmp/linuxic

g. ./setup.pl drivers

e) Install the mouse driver

a. Attach the inputvsc.iso through the Hyper-V manager

b. Create a folder and copy the contents.

c. mkdir /tmp/inputvsc

d. cp –rp /media/CDROM/* /tmp/inputvsc

Note: you may need to mount again: mount /dev/hdc /media/CDROM

e. cd /tmp/inputvsc

f. ./setup.pl

f) Power down the VM, remove the Legacy Network Adapter, add a Synthetic Network adapter, power on the VM (you could also do a shutdown now –hP)

g) Using YaST (or YaST2), configure the newly installed synthetic network adapter.

Wednesday, April 2, 2008

Networking under Hyper-V (who moved my network settings?)

There is a lot of discussion around networking and network changes on a Windows Server 2008 server after the Hyper-V role is installed.

Part of this issue goes back to what happens (what is done) to your WS08 server when the Hyper-V role is installed.

As I had mentioned in a previous post when the Hyper-V role is installed the WS08 server is fundamentally changed. As an administrator you login to a console and you see WS08 - it looks like nothing changed, however it has.

Ben Armstrong has a quick posting here that gives some basics.

Lets take a more architectural look at the server and what has happened / is happening..

During the process of adding the Hyper-V role the WS08 installation was turned into a virtual machine itself and it is running on top of the hypervisor as the parent partition. Unlike other hypervisors where you see a Linux based console, in this case you see your WS08 server - a nice, friendly GUI interface that really does not look any different than it did before.

Now, what does this have to do with the networking? It has to do with modifications that were made to the network interfaces of the WS08 server when the Hyper-V role was installed.

Quite honestly, the modifications that are made are no different than what happens when modifying any other Windows server in a similar way.

Most likely, if you set a manual IP address (any manual settings) they were lost.

If you look at Network Connections in the WS08 server you notice new Virtual Network Adapters and your original network connections were changed.

Noting back, your WS08 server was turned into a VM (its hardware was changed) - the original network connection (which you can still see) was turned into a virtual switch (the WS08 server no longer owns that NIC).

Your WS08 server (WS08 parent partition - that is what it is now) was given new virtual network card(s). And as with adding any new NIC to any Windows server it gets the default settings (DHCP for example).

Now, there is also talk about performance (the parent partition performance is terrible, but a VM runs great - or the other way around).

Now we have to begin looking at the NIC driver and driver configuration.

First of all, good old TCP Offloading, long a performance issue in many Windows environments might need to be turned off. Mind you, this issue seems to be environment specific.

The other is the NIC driver itself. You are pretty safe using the included WS08 drivers.

Some troubleshooting questions:
Did you install a non-Windows delivered driver?
Did you install a teaming driver?
Did you configure teaming?
Was there management software installed with the teaming driver or was only the driver installed? (some experience has shown that the driver itself might be fine but the management software causes problems - as it is trying to monitor a NIC that the parent partition no longer owns)

My goal with this post was to help an administrator understand what is going on, and with that where to look to solve his/her problems.