rbeam's Posts

Prior versions ... ... can't be found anywhere! Go search for "vmrc". Everything will be v10.0.3, no matter when it's claimed to have been released. (saw one reference of 2014) Even if it's... See more...
Prior versions ... ... can't be found anywhere! Go search for "vmrc". Everything will be v10.0.3, no matter when it's claimed to have been released. (saw one reference of 2014) Even if it's not "supported", there are plenty of reasons to keep old stuff around. For starters, a lot of the old s**t actually works. HTML5 UI? "Feature Complete"?!? Bull. Half the things I need to do every day CAN NOT be done from H5 -- or flash for that matter. One still needs to install wads of native applications to do things the fat client nver had a problem doing. I just spent all day beating my head against the wall trying to deploy an ova under 6.7u1. (working with a 30+GB image, I want to kill some people more than once for this crap. v5.5 C# client, that just works.)
there will be change in device name of /storage/seat (/dev/sdh) Actually, that won't make any difference. They use LVM, so the actual device holding the volume is irrelevant. (only sda matters... See more...
there will be change in device name of /storage/seat (/dev/sdh) Actually, that won't make any difference. They use LVM, so the actual device holding the volume is irrelevant. (only sda matters as that's the boot/root volume) But it's easy enough to put the new disk back at the same place. I would say, just mark it "thin" and vmotion it. It won't actually use 1.4T.
VCSA is a just another VM. While it is a pig (vESXi won't be?) there's no problems running more than one VCSA VM in an environment -- I run many. If you don't take steps to link them, they won't ... See more...
VCSA is a just another VM. While it is a pig (vESXi won't be?) there's no problems running more than one VCSA VM in an environment -- I run many. If you don't take steps to link them, they won't even know the others exist.
(Smells like a bug. Using 6.7.0U1, the layout changes between the two.  [ /mob/?moid=vm-72&doPath=layout ] As a VM : configFile string[] "New Virtual Machine Template.vmsd" di... See more...
(Smells like a bug. Using 6.7.0U1, the layout changes between the two.  [ /mob/?moid=vm-72&doPath=layout ] As a VM : configFile string[] "New Virtual Machine Template.vmsd" disk VirtualMachineFileLayoutDiskLayout[] disk[2000] VirtualMachineFileLayoutDiskLayout logFile string[] Unset snapshot VirtualMachineFileLayoutSnapshotLayout[] snapshot["snapshot-73"] VirtualMachineFileLayoutSnapshotLayout snapshot["snapshot-74"] VirtualMachineFileLayoutSnapshotLayout snapshot["snapshot-87"] VirtualMachineFileLayoutSnapshotLayout snapshot["snapshot-90"] VirtualMachineFileLayoutSnapshotLayout swapFile string Unset As a template: configFile string[] "New Virtual Machine Template.vmsd" disk VirtualMachineFileLayoutDiskLayout[] disk[2000] VirtualMachineFileLayoutDiskLayout logFile string[] Unset snapshot VirtualMachineFileLayoutSnapshotLayout[] Unset swapFile string Unset [Update: 6.5.0-9451637 does not clear the snapshot from layout]
I was just looking for the same answer... Sadly, it looks as though the only answer to any VUM problem is re-install... uninstall (erase), and start over.  I see nothing in the GUI to reverse ... See more...
I was just looking for the same answer... Sadly, it looks as though the only answer to any VUM problem is re-install... uninstall (erase), and start over.  I see nothing in the GUI to reverse an import, remove a patch from the database, or even get the stupid thing to download patches it's missed (something that happens every d*** time I go to install patches.) The only other option is to mess with the database directly.  That's obviously the next to last resort -- backup the db, or be prepared to reinstall.
I looked into it deeper... vSphere (ESX 4.0 BETA) label esx4 kernel vSphere/vmlinuz append initrd=vSphere/initrd.img nofb vmkopts=debugLogToSerial:1 mem=512M text root=/dev/ra... See more...
I looked into it deeper... vSphere (ESX 4.0 BETA) label esx4 kernel vSphere/vmlinuz append initrd=vSphere/initrd.img nofb vmkopts=debugLogToSerial:1 mem=512M text root=/dev/ram netdevice=vmnic0 url=nfs://server/exports/installer/esx-4.0.0-140815 label esx4-ks kernel vSphere/vmlinuz append initrd=vSphere/initrd.img nofb vmkopts=debugLogToSerial:1 mem=512M text root=/dev/ram netdevice=vmnic0 ks=nfs://server/ks-esx4.cfg It still looks for a CD, but doesn't care that it's not there.
Simple answer, the RC/Beta (140815) wasn't intended to be net installed. (at least from my 30s of dealing with it.) The anaconda 'method=nfs' is meaningless. My quick and dirty solution has be... See more...
Simple answer, the RC/Beta (140815) wasn't intended to be net installed. (at least from my 30s of dealing with it.) The anaconda 'method=nfs' is meaningless. My quick and dirty solution has been to change the cd mount script (/etc/vmware/init/init.d/11.85...) to a) return immediately if the media is already mounted, and b) load the nfs modules and mount the nfs volume otherwise. Since I'm just playing with ESX4 on a few machines, I've not bothered to dig any deeper or edit the initrd -- instead I just fix the script on every boot. If I were installing more than 2 machines, the initrd would be altered.