brian's questions

I've currently got a pair of vSphere5 standard servers (physical, not VAs) managing about a hundred ESX 4.1 and 5 hosts in two different physical and logical datacenters. With our last purchase, we bought another vSphere license for the new vS server. I unmanaged all the ESX servers in one datacenter and added them to new vSphere server.

Our previous single-vS-server layout used to be:

-vSphere1
--Datacenter1 (where the physical ESX host was located)
---Folder
----ESX server1
--Datacenter2
---Folder
----ESX server2

Now it looks like

-vSphere1
--Datacenter1
---Folder
----ESX server1
-vSphere2 (new vSphere server)
--Datacenter2
---Folder
----ESX server2

ESX server2 was removed from vSphere1's inventory and added to vSphere2's, so it is now managed by vSphere2.

This is nice and all, as no vSphere <--> ESX management traffic leaves the physical datacenter, except for one huge oversight: when I go to clone a VM, the opposite vSphere server (and thus other datacenter) does not show up in the list on the first page of the wizard.

Is this a bug, a license limitation, or is it just simply not possible to clone a VM from an ESX box managed by one vS server to another ESX box managed by a /different/ vS server?

Situation: I've got some machines with Dell iDRAC6 Enterprises that I need to kickstart remotely.

Usually, I'd go to the datacenter, jam the CD and floppy (with ks.cfg) in the machine, and be on my way. The last build I did, I "burnt" the ISO onto a flash drive with UNetBootin, jammed all the kickstarts on the root of the same flash drive, and was able to boot with "linux ks=hd:sdb1:/hostname-ks.cfg." Problem is, I'm doing everything remotely now.

I've loaded up the DRAC interface and mounted both the floppy with ks.cfg and RHEL netboot CD mounted. It boots off the CD, but when I do

linux ks=floppy

The kickstart can't be located and it proceeds into the regular non-automated installation.

I've also tried "linux ks=fd0:/ks.cfg," "linux ks=hd:fd0:/ks.cfg," and a few other permutations, to no avail.

I think if I could figure out what the device names for the virtual CD and floppy that the DRAC presents to the system are, I'd be in good shape.

Situation:

I've got a bunch of blades, all with same amount of memory and cores in each. Some have local storage, some do not and rely on the SAN.

I've also got a ton of VMs that I need to build and drop on these blades. There are about 7 or 8 different instance types, each which has the same spec. For example, instanceA has 2 GB RAM/2 cores/100 GB SAN storage. InstanceB has 4 GB RAM/8 cores/60 GB blade-local storage. InstanceC has 16GB RAM/4 cores/100 GB blade-local storage. Etc.

Is there some sort of tool somewhere that I can run/get/etc that I can punch in each blade and instance spec, and said tool will automatically propose which blades to put instances on, while leaving a bit of room for overhead? Even an Excel template or something would work.

List of VMs and hosts goes in, locations of VMs on guests comes out. VMware with vSphere.

Any input is appreciated

I'm in the process of deploying a bunch of Win2K8R2 VMs via vSphere's deployment template stuff, and in the deploy specification it allows you to punch a list of commands to run. Aside from activating Windows (which it doesn't do), it works pretty well.

Does anyone know the command-line equivalent of going into a network adapter's properties and unchecking the IPv6 box? If I had that I could put that in the spec and not have to manually uncheck the IPv6 box.

I'm looking for something that runs on either Windows or Linux that will automatically query devices on my network (specifically the HP and Dell servers), determine their serial number, look that serial up against the manufacturer's site to determine warranty expiration status, and have it generate reports.

I tried out Spiceworks, and while nice, it doesn't quite fit my needs. Something fully automated would be best due to the amount of machines I need to check warranty expiration on.

Anything free would be preferred, but pay software would work as well, provided it has an evaluation.

Here's a weird one I've been fighting for a while. I've got a old out-of-warranty Dell PowerEdge 6650 server with a PERC 3/DC RAID controller controlling four newer (maybe a year old) Fujitsu 136GB U320 SCSI disks in a RAID5 array.

Maybe once a month or so one of these disks will randomly "fail." By fail, that means the PERC decides that they've failed and it starts beeping and blasting alerts. All I have to do to resolve the issue is remove and reseat the "failed" disk and it starts resyncing the array. Once the resync is complete, the bezel light on the front of the machine goes back to blue from orange and the beeping stop.

My main question is what is causing these disks to "fail," when in fact they're perfectly fine. At first I thought it might be a firmware issue, so I reflashed every flashable component in the system. BIOS, PERC firmware, disk firmware, everything.

There doesn't seem to be a cause or event that triggers one of the non-failures, it just happens at random.

It's not exactly a huge issue, but it's definitely something I'd like to resolve. Dell won't provide support since the machine is out of warranty, and their website/forums are useless as always.