Posts

vmnic0: Link is Down

Honest to goodness. Mar 25 07:12:26 osh-esx-1 vmkernel: 9:12:00:32.092 cpu1:4210) 0000:01:00.0: vmnic0: Link is Down I'm at a loss with this system. At the same time my iSCSI box powered itself off, and it gives me the most informative: The operating system started at system time ‎2010‎-‎03‎-‎25T11:15:02.484375000Z. Lovely. Once I'm back from my vacation (starting tomorrow morning for a week), I'm nuking everything and starting fresh - it is a lab, after all. If I continue to get errors, I'm replacing the RAID card - my faux PERC5i - with a PERC6i. At that point I'm also going to reconsider my storage infrastructure. I may give Windows another shot, and hope it indeed was the RAID card. Or, if I can find a storage filer that does iSCSI and MPIO, I'll give that a shot. I'm truly constrained by the gigabit network - when doing VM deployments it maxes out at 50% on the line, either one or two VM deployments. Of course, this is all silly...I don't nee...

ESX vmkernel errors - solved!

Let's start with the errors I was seeing in: /var/log/vmkernel Everything was fine until this showed up: Mar 10 22:09:13 osh-esx-1 vmkernel: 0:00:06:47.624 cpu0:4096) e1000: vmnic2: e1000_clean_tx_irq: Detected Tx Unit Hang Mar 10 22:09:13 osh-esx-1 vmkernel: Tx Queue Mar 10 22:09:13 osh-esx-1 vmkernel: TDH Mar 10 22:09:13 osh-esx-1 vmkernel: TDT Mar 10 22:09:13 osh-esx-1 vmkernel: next_to_use Mar 10 22:09:13 osh-esx-1 vmkernel: next_to_clean Mar 10 22:09:13 osh-esx-1 vmkernel: buffer_info[next_to_clean] Mar 10 22:09:13 osh-esx-1 vmkernel: t Mar 10 22:09:15 osh-esx-1 vmkernel: 0:00:06:49.377 cpu7:4256)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic: vmhba34:CH:0 T:1 CN:0: Failed to receive data: Connection reset by peer Mar 10 22:09:15 osh-esx-1 vmkernel: 0:00:06:49.377 cpu7:4256)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic: Sess [ISID: 00023d000001 TARGET: workstation-disks TPGT: 1 TSIH: 0] Mar 10 22:09:15 osh-esx-1 vmkernel: 0:00:06:49.377 cpu7:4256)WARNING: iscsi_vmk: iscsivmk_...

Few notes on the home ESX box

I'm now running ESX within Workstation. It connects via a separate Gb NIC to the iSCSI switch on to Starwind 2TB imagefile. On the other Gb NIC is the LAN/Service console. Note if you want to use NFS to host your ISOs on the iSCSI server: Completely doable, but if you find yourself getting 'NFS Error: Unable to Mount filesystem', it's probably because you either don't have the NFS Client firewall rule enabled, or you haven't added a VMkernel to your LAN vSwitch. I just added one with an IP address on the LAN's subnet. Did that, works like a charm now! Oh yeah, you need root access enabled in the NFS properties on the server that is hosting your NFS share. I also had the NUMA CPU error on booting up ESX4 inside Workstation 7. The following link fixed it: http://communities.vmware.com/thread/244537 (the post by dmadden) I've since installed ESXi since this will be a permanent install (also got the NUMA CPU error). Oddly enough, NFS works fine, but iSCSI r...

On servers and racks and stuff...

For goodness sake order a DVD-ROM in the least. We have several 2950s and 2850s that have CD-ROM drives and are utterly useless for ESX installs. I'm now praying the DRAC card's ISO mount works. If not, big trouble!! Also, a few other points off the top of my head: Order less DIMMs, but higher capacity, even if you have no plans to expand. It will happen, and you will throw out a ton of 512MB/1GB/2GB sticks of FB-DIMMs that nobody else wants for this very reason. Order a ILO/DRAC/etc card. Just do it. It will save your bottom later. Only use an x64 OS if you're doing a native install, otherwise use ESX or something similar. Just doesn't make sense to have single-purpose servers in this day and age unless you're talking about an absolute monster of a SQL server or something similar. Strongly consider an expansion NIC card (dual port at least) if you do not have Intel NICs on-board. Just a good redundancy strategy. Don't skimp on PDUs in your server rack -...

ESXi storage migration

Figured I'd post something useful about this experience. Really, it's all about planning. Not just having a plan, or even having a plan that covers the basics, but having a plan that allows for practical things, like time off, shipping errors, configuration oversights, and just plain bad luck. We've had all of the above and then some on this latest project. No matter how hard we tried to make our deadlines, we either forgot a key point (ESXi doesn't do storage migration on its own), or were given misinformation or not enough information (ET RS-16 IP-4 doesn't handle jumbo frames including/past 8000), or just plain bad luck abounded (the crux of the project lay across a perfect storm of not one but three long weekends (Christmas, Boxing day, New Years) compounded by different locations having different ideas about which days to take off. I've spent my New Years Eve (well, 95% of it) on one task: Migrate the storage of all the VMs on our NY site's ESXi box fro...

MOSS on a fresh 2008 R2 sever - error on install

Trying to install MOSS on an 2008 R2 server, fresh installs each. Got a "This program is blocked due to compatibility issues" with references to KB article 962935. Here's the fix, courtesy of Thibault B. Slipstreaming SharePoint SP2 into SharePoint 2007 Server with SP1 does the job when trying to install on a fresh Windows Server 2008 R2. Basically all you have to do is the following: Extract OfficeServerwithSP1.exe by executing "OfficeServerwithSP1.exe /extract:C:\yourpathsp1\" Extract officeserver2007sp2-kb953334-x64-fullfile-en-us by executing "officeserver2007sp2-kb953334-x64-fullfile-en-us /extract:C:\yourpathsp2\" Copying all files from "C:\yourpathsp2\" to "C:\yourpathsp1\Updates\"It worked like a charm for me :) From here: http://social.technet.microsoft.com/Forums/en/sharepointgeneral/thread/c7091bda-867e-49a1-9bc8-c2ef847c92e7

Neat trick when making outside IP changes

The guy I'm working with for our router changes has a neat trick for insurance against a bad IP change. Run this command prior to making the IP change on your internet-side interface: reload -n XX (where XX is the amount of time to hold the reload) Then run your IP change commands. If you make a mistake, or have bad info, the router reboots itself after XX time, clearing the bad commands! Clever use of the reload command - there's something you wouldn't learn in school!