pazzer

Forum Replies Created

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • in reply to: HowTo: vmware-tools in ZeroShell #50102

    pazzer
    Member

    Hi Xmas/all

    Thank you for this fantastic documentation of how it’s done!

    For any of those out there who may benefit, I thought I’d comment on my experience on installing VMtools into ZS;

    – My ZS(s) runs off VMware VMDK disks on ESX 4.1

    – Initial ZS install was just extracting the USB/SATA img to a 2Gb disk with DD (this was the quickest / cleanest method I came across for a VM)

    – I’ve partitioned the spare 1Gb (left over from the imaging process) and formatted as ext3

    – During the process documented above, I found that upon installing modules into the target directory (/Database) that the script would halt with a ‘no space remaining warning’ – I cleaned up the filesystem as best I could, still no joy. The image on disk occupies close to 700/800Mb I think. Anyway, moving on…

    – I mounted the spare 1Gb partition and used that to copy/build upon

    – The ‘run.sh’ script mentioned needed to be placed elsewhere, so I chose the /Database dir, gave it some ‘chmod +x’

    – Added the mkdir and mount commands for the 1gb partition to run.sh, so that the partition with the vmtools on was accessible, before the daemon is started

    Success!
    I’ll come back for this one, and get the vmxnet3 nailed. Not sure that I need to memory-balloon my ZS router/NAT/VPN/DNS though!!
    Thanks for the info Xmas, and thank you ZS!

    in reply to: VMWare/Zeroshell and HP VLANs #51313

    pazzer
    Member

    guys..

    I know it’s a late post but I think it’s beneficial to put this straight for anyone else reading this..

    “As far as I know this is red hat linux based, correct?”
    — No. ESX (early 2.X and 3.X versions) were somewhat based on RHEL, and used a number of RHEL components in addition to the proprietary VMware ‘vmkernel’ – but things have changed, and ESX 4 and above (especially 4.1 and above) do NOT include RHEL components. In fact, the existing ‘Service Console’ – taken from RHEL – has now been replaced with busybox in 4.1.

    With regards to dropping into the ESX shell to ‘tinker’ – be very careful. You’ll void support warranties with most companies by doing this, because ESX is an ‘appliance’ more than it is an OS. Don’t install 3rd party tools unless you’re really linux-savvy, and know how to get yourself back out. I’m not even confident that the build tools are even on the newer releases, so you’ve probably a severe lack of compilers etc..

    ESX 4 does bring many options for 3rd party plugins (Storage, Networking, Systems Mgmt etc) but these typically run in CIM memory space.

    If you are to type any CLI commands (via local terminal, remote SSH, or VMware Remote CLI) then they should be VMware commands;
    esxcfg-vswitch -l
    esxcfg-nics -l
    some other commands (tcpdump for example) are there – but aren’t always the standard binaries.

    Some notes on VLANS and ‘NICs’ – which are actually ‘uplinks’ in ESX;

    – vSwitches themselves don’t have any properties for VLANs. They carry anything.

    – VM Port Groups allow you to specify a VLAN – so any traffic from VM hosts will come into the Port Group, and will be tagged (802.1Q) as they hit the vSwitch data plane.

    – If VM hosts specify VLAN at the NIC driver stage (possible) then the tagged packets will come down through the port group and onto the vSwitch, then onto Uplink adapters to physical switch(es) – I think that the PortGroup will need VLAN 4095 specifying for this to work (4095 is catch-all, all VLANs allowed)

    – Physical switch ports should be configured as trunks, able to carry multiple VLANs. You can use an access port (eg: VLAN2) but that will tag everything coming in as VLAN2, which isn’t always what you want.

    – Physical NICs on an ESX host don’t have an IP, they are simply a copper pass-through to the physical connections outside the ESX server

    – If any changes are to be made to a NIC, it’s usually knocking off features like TSO etc, which is a CLI job. In general, no tweaking is required – you just need to design the aggregation / failover policies depending upon… well… more than I care to detail right here 😛

Viewing 2 posts - 1 through 2 (of 2 total)