Relevant mostly to OS X admins
The power supply in my FIL’s old XP box recently failed, so I offered to help him use the harddrive to become a virtual machine (Via Fusion 5) on his Macbook Pro. It wasn’t as easy as I thought: here’s a number of ways that don’t work:
Plug the IDE drive into a USB adapter and use VMware vCenter Converter Standalone to convert that drive to a VM. vCenter won’t acknowledge a USB drive, in either a VM (as I first tried), or on a physical machine.
Clone the drive (via the IDE to USB converter) to a VMDK destination using Clonezilla, in a VM. The Clonezilla output was true and perfect, but I ran into a classic XP problem: the drivers for the system that it came from aren’t appropriate for the VM: result was a VM that would BSOD a few seconds after boot with a warning re BusLogic SCSI drivers. If I had the right source media on hand think I could have done a repair on XP, using a documented method from VMWare. Unfortunately, source was XP Home, and I only had XP Pro media.
What finally worked was the fortune that I had an old PC with a IDE port. I was able to plug the drive there, boot from the daily use XP drive (booting from his drive would BSOD, just like in a VM), and run vCenter from there, converting only the non-C: volume, and including VMWare Tools, which inserted the needed drivers. vCenter complained that it wasn’t a System drive, but the end result was a bootable VM.
In order to update the firmware on my stack of Dell 5548P switches, I needed to set up a TFTP server, and serve up some files 80’s style. A quick Google search told me that OpenTFTP Server appeared to be a fine choice, so I grabbed it, and put it on a Windows 2K8R2 server. It took me a little exploring to realize that everything I really needed to learn about configuring and launching it was living in the OpenTFTPServerMT.ini file. Digging through that .ini I answered my initial question of “what directory are you serving from?” and found all the other configuration options adequately documented within. I ran the OpenTFTPMTInstallService.exe file, saw I had a new service running, and tried to connect via TFTP on my ML laptop.
Oh yes… the server level firewall. TFTP runs on port 69, UDP protocol. Open that up, and hurray, we can talk.
Next, let’s move a file. There’s no directory listing in TFTP, you have to know your filenames, and the Dell firmware and boot code are relatively long, so I create a 2 line test.text file, and ask my ML laptop to GET it:
tftp> get test.txt sent RRQ <file=test.txt, mode=netascii> received DATA <block=1, 54 bytes> Received 54 bytes in 0.1 seconds
Perfect! The Hello World test passes, now onto the real stuff.
tftp> get powerconnect_55xx-4108.ros sent RRQ <file=powerconnect_55xx-4108.ros, mode=netascii> received DATA <block=1, 512 bytes> sent ACK <block=1> received DATA <block=2, 96 bytes> Received 608 bytes in 0.1 seconds
No… the file isn’t 608 bytes. I test a quick test.zip file: also ends much before it should. I experimented with a few options (blksize, getting more feedback via verbose and tsize) before it occurred to me: in TFTP, one must treat ascii and binary files differently, and set the appropriate mode:
Oh, yes. That changes everything. Since the real use case here is for moving the files to the switch stack, I’m going to guess that binary is its default condition. There’s no mention of needing to select that in the documentation.
I have to wonder if low level switch management will ever leave serial ports, 9600,8,N,1 and TFTP behind…
After the deployment of my stack of 3 Dell 5548P switches recently, and the purchase of 4 Ruckus 7372 APs (and the ZoneDirector controller), I started working on deploying the Ruckus APs. Naturally, with a back end of PoE switches, that’s the desired route to power them. However, as I started placing them, I found that sometimes the APs would come up as expected, and in other ports they wouldn’t.
I audited the switch configuration, looking for any form of “no power for you!” defined on the trouble ports: no, power is available to all. I took 2 APs directly to the switches themselves, and plugged into ports, to bypass any potential issues with the building cabling. Here I found ports where the APs would come up, and other ports where they wouldn’t, with no visible pattern of success vs fail emerging.
In my troubleshooting research, I found a thread in a Cisco support forum documenting similar behavior, where Ruckus APs can’t always be powered via Ethernet as expected. I asked @DellCaresPro on twitter if they were familiar with any issues between their switches and Ruckus gear, but they replied that they hadn’t documented any such issues. Dell’s advice was to upgrade the switch firmware, which led to it’s own adventures in setting up a TFTP server, which I may document next.
This entry doesn’t contain a solution to the problem yet- I’m throwing it out there so that perhaps if someone Googles the right terms, they might learn they’re not alone. Once I can do the firmware upgrade, I’ll see if I can get the expected behavior of plug into any port, get power.