VMware vSphere Perl SDK

Potřeboval jsem si zprovoznit VMware API a šáhnul jsem po jednom z několika nástrojů, které VMware má k dispozici. Tyto nástroje hodlám použít pro monitorovani ESXi hypervisorů např. dle tohoto návodu na Zabbix fóru.

vSphere Perl SDK jsem si instaloval na třech různých OS. FreeBSD, CentOS a Ubuntu Desktop. Toto SDK má v sobě nejen Perlovské knihovny, ale i připravené CLI příkazy též postavené na Perlu, které umí poměrně hodně věcí. Již dříve jsem si CLI instaloval. Většina API nástrojů je integrována ve virtuálce vMA. Osobně jsem se rozhodl Perl SDK instalovat na své systémy.

FreeBSD 8.x i 9.x

Existuje port, který je momentálně ve verzi 5.0.0. Instalace všech závislostí je velmi snadná.

fetch http://nekde/VMware-vSphere-Perl-SDK-5.0.0-422456.i386.tar.gz
mv VMware-vSphere-Perl-SDK-5.0.0-422456.i386.tar.gz /usr/ports/distfiles/

cd /usr/ports/net/vmware-vsphere-cli && make install

Po instalaci je dobré zohlednit postinstalační zprávu.

========================================================================
Please note that, by default, an underlying Perl module does certificate
verification when communicating with vSphere hosts.

You must create a file that contains the public keys of all of your
vSphere hosts and then configure your Perl scripts to have the following
line:
$ENV{HTTPS_CA_FILE} = "/path/to/file";

If you want to disable this important security feature, you may set the
following variable to 0:
$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME}
========================================================================

Balíček se jmenuje přesně takto.

vmware-vsphere-cli-5.0.0 VMware vSphere SDK for Perl with CLI tools

Jakou verzi používáme zjistíme následovně.

perl -MVMware::VIRuntime -e 'print $VMware::VIRuntime::VERSION'
5.0

Pro programování v perlu jsou důležité tyto Perlovské moduly.

VMware::VIM25Runtime
VMware::VIM2Stub
VMware::VIM2Runtime
VMware::VICommon
VMware::VILib
VMware::VIM25Stub

Nutno dodat, že port neobsahuje binárky esxcli!

CentOS 6.3 x86_64

Instalace na této distribuci odvozené od RHEL je poněkud komplikovanější. Je to kombinace tří zdrojů. Některé baličky jsou z oficiálního repositáře. Dále je nutný EPEL a jeden Perl modul jsem musel instalovat ručně.

Instalaci jsem konfrontoval s oficiální dokumentací vsphere-esxi-vcenter-server-51-sdk-for-perl-installation-guide.pdf, kde není instalace kompletní. Sice se část nainstaluje dle návodu, ale spoustu Perl modulů - balíčků musíme instalovat sami. Já si své instalované moduly poznamenám.

Instalace dle návodu k RHEL

yum install openssl-devel libxml2-dev e2fsprogs-dev

Nastavení proxy bylo vyžadováno ...

export ftp_proxy=http://192.168.42.7:8080
export http_proxy=http://192.168.42.7:8080

Stáhneme si instalační soubor.

VMware-vSphere-Perl-SDK-5.1.0-780721.x86_64.tar.gz

tar xvzf VMware-vSphere-Perl-SDK-5.1.0-780721.x86_64.tar.gz
cd vmware-vsphere-cli-distrib && ./vmware-install.pl

Instalátor si žádá následující balíčky o kterých dokumentace píše obecně. Názvy uváděny nejsou.

yum install perl-Archive-Zip perl-Compress-Zlib perl-Crypt-SSLeay perl-Class-MethodMaker perl-HTML-Parser perl-SOAP-Lite perl-XML-SAX perl-ExtUtils-CBuilder perl-libxml-perl perl-XML-LibXML-Common

Né vše je v oficiálním repo.

rpm -i http://ftp.fi.muni.cz/pub/linux/fedora/epel/6/i386/epel-release-6-7.noarch.rpm
yum update
zum install uuid-perl perl-Data-Dump

Instalátor si žádá verzi UUID 0.03 or newer, která není ani v jednom repo.

Doinstalujeme si nástroje pro build.

yum install make gcc libuuid-devel

Na stránce  http://search.cpan.org/~jnh/UUID/UUID.pm si najdeme odkaz ke stažení src.

wget http://search.cpan.org/CPAN/authors/id/J/JN/JNH/UUID-0.04.tar.gz
tar xvzf UUID-0.04.tar.gz && cd UUID-0.04
perl Makefile.PL
make install clean

Instalace již doběhla s varováním, které zatím ignoruji. Co jsem od SDK potřeboval fungovalo.

The following Perl modules were found on the system but may be too old to work
with vSphere CLI:

Compress::Zlib 2.037 or newer
Compress::Raw::Zlib 2.037 or newer
version 0.78 or newer
IO::Compress::Base 2.037 or newer
IO::Compress::Zlib::Constants 2.037 or newer
LWP::Protocol::https 5.805 or newer

Enjoy,

--the VMware team

Ubuntu 12.04 LTS Desktop

Naposledy jsem si instaloval VMware vSphere Perl SDK na notebook. Instalace je opět pro Ubuntu 10.04 popisována v dokumentaci. Taktéž je doporučeno instalovat jen něco.

32 bit
sudo apt-get install build-essential gcc uuid uuid-dev perl libssl-dev perl-doc liburi-perl libxml-libxml-perl libcrypt-ssleay-perl
64 bit
sudo apt-get install ia32-libs build-essential gcc uuid uuid-dev perl libssl-dev perl-doc liburi-perl libxml-libxml-perl libcrypt-ssleay-perl

Doinstalovávám tyto deb balíky

libarchive-zip-perl
libcrypt-ssleay-perl
libclass-methodmaker-perl
libdata-dump-perl
libsoap-lite-perl

tar xvzf VMware-vSphere-Perl-SDK-5.1.0-780721.x86_64.tar.gz
cd vmware-vsphere-cli-distrib

Test verze Perl SDK.

perl -MVMware::VIRuntime -e 'print $VMware::VIRuntime::VERSION'
5.1.0

Test spojeni s ESXi pomocí připravených ukázkových scriptů.

cd /usr/lib/vmware-vcli/apps/general/
./connect.pl --url https://192.168.42.13/sdk/webService --username root --password ***
Connection Successful
Server Time : 2012-09-19T12:31:19.505723Z

Pokud se nám objevuje chybová hláška začínající ...

Server version unavailable at ...

Slevíme z bezpečnosti a nastavíme si danou proměnnou na zero.

export PERL_LWP_SSL_VERIFY_HOSTNAME=0

Teď už jen zažít programovat :-) Jinak mnoho zajímavých informací je na blogu vmware http://blogs.vmware.com/vsphere/tag/vsphere-api

Zabbix

Pro otestování Perl SDK je možno užít a mírně modifikovat tento script

time ./zabbix_perl_api_vmware.pl 192.168.42.13 ahKaer5a root
0

real    0m27.655s
user    0m19.087s
sys    0m0.253s

Tento script do /tmp/vmware_api_IP.txt vytvoří soubor s informacema o běhu ESXi.

Array_0.Queue_Command_Latency.average:    0
Uptime:    2251653
Array_0.Disk_Write_Requests.summation:    2768
Array_0.Disk_Read_Requests.summation:    1872
CpuUsed:    800000000
MEM_consumed:    5467086848
Array_0.Physical_Device_Write_Latency.average:    0
vmnic1.duplex:    0
Array_0.Disk_Command_Latency.average:    3
MEM_shared:    337231872
vmnic1.state:    0
MEM_swapused:    0
Array_0.Disk_Commands_Issued.summation:    4641
Volume.Capacity_datastore1:    744371519488
MEM_heapfree:    8821760
MEM_overhead:    329478144
Array_0.Disk_Command_Aborts.summation:    0
vmnic0.Network_Packets_Received.summation:    926
MEM_unreserved:    7255425024
vmnic1.speed:    0
Array_0.Queue_Read_Latency.average:    0
Volume.Free_NFSDATA:    5556114989056
MEM_zero:    188387328
vmnic0.Network_Data_Receive_Rate.average:    65536
Array_0.Disk_Bus_Resets.summation:    0
Volume.Capacity_NFSDATA:    5902284800000
MEM_swapout:    0
MEM_vmmemctl:    0
MaintenanceMode:    0
MEM_sysUsage:    382578688
Array_0.Queue_Write_Latency.average:    0
MEM_reservedCapacity:    321536
Array_0.Disk_Read_Rate.average:    1150976
MEM_swapin:    0
MEM_usage:    6522880
Array_0.Kernel_Disk_Command_Latency.average:    0
Array_0.Disk_Write_Rate.average:    2843648
vmnic0.state:    1
Array_0.Physical_Device_Read_Latency.average:    7
Array_0.Kernel_Disk_Read_Latency.average:    0
Array_0.Disk_Read_Latency.average:    7
MEM_state:    0
MEM_granted:    5213470720
Volume.Free_datastore1:    158921129984
vmnic0.duplex:    1
Array_0.Disk_Write_Latency.average:    1
MemSize:    8582520832
Array_0.Physical_Device_Command_Latency.average:    3
vmnic0.speed:    1048576000
Array_0.Kernel_Disk_Write_Latency.average:    1
MemUsage:    5465178112
MEM_active:    647704576
MEM_sharedcommon:    132751360
CpuTotal:    11304000000
vmnic0.Network_Data_Transmit_Rate.average:    565248
vmnic0.Network_Packets_Transmitted.summation:    886

VMWare Converter

V novém zaměstnání jsem obdržel dočasný NTB Dell Latitude D630, stará vrána a na něm Win7. Asi 14 dni jsem s daným HW musel vydržel. V momentě, kdy jsem si byl vyfasovat nový výkonný ntb, řešil jsem jak částečné vyladěný systém přenést do Linuxu, který hodlám používat spolu s VMware Workstation 8.0.2.

Řešením bylo do Win7 nainstalovat VMware-converter-all-5.0.0-470252.exe. S tímto SW jsem pak nechal fyzický OS konvertovat do formátu Workstation. Kvůli nedostatku místa na lokále jsem připojil externí disk přez USB. A na něj nechal uložit nově vzniklou virtuálku. Daný adresář s Win7.vmdk diskem a souborem definujícím virtualku Win7.vmx (#!/usr/bin/vmware
) jsem zkopíroval do prostoru Linux Ubuntu 12.04 LTS (beta2). Ve workstation jsem si už jen danou virtuálku pustil. Po zpuštění jsem jen odinstaloval nVidia divery a doinstaloval VMware Tools a přenesený systém je tam kde jsem jej chtěl mit.

VMware Workstation 7.1.4 na LMDE

Instalace samotného komerčního produktu VMware Workstation 7.1.4 projde bezproblémově, vše ala widle, klikací vizárd. Při prvním puštění se ovšem kompiluje patřičný modul jádra, což si VMW od jisté verze zajišťuje sama. Error log moc nenapoví, kontroloval jsem existenci kernel headeru atd. ale vše bylo v pořádku.

Chybu se spuštěním po instalci, jsem pozoroval jak u LMDE tak u Ubuntu 11.10. Problém je v tom, že kernel 3.0.x není v VMW 7.1.x zřejmě podporován. Moc jsem problém podrobně neanalyzoval. Našel jsem jeden blog, kde je k mání patch vmware2.6.39patchv3.tar.bz2 se scriptem, který udělá vše za Vás. Pozmění se zdrojáky a provede se kompilace modulu.

S aktuální sedmičkovou verzí VMware Workstation 7.1.5 patch nefunguje, ale to je asi jen kosmetický problém.

UPDATE: Úpravou patch scriptu je možno instalovat i 7.1.5. Jen je třeba smazat soubor .patched, ale na to každý příjde sam.

Tento neduh jsem řešil s jedním kolegou v HK a přičítal jsem jej LMDE, ale totéž jsem řešil včera s Ubuntu 11.10, kde je též kernel verze 3.x.

ESXi 5.0 + FreeBSD 8.2 + VMware Tools 8.6.0 build-425873

Kolega v práci instaloval nedávno zveřejněný ESXi 5.0 A tak jsem hnedle koukal jaká verze FreeBSD je podporovaná. Potěšilo mě, že je podporováno aktualní FreeBSD 8.2. Rychle jsem nainstaloval amd64 port.

Doposud FreeBSD a vmware tools provozuji s portem open-vm-tools, přesněji tento port. Nyní jsem chtěl vyzkoušet vmware tools, které jsou součástí ESXi 5.0.

Pro funkčně fungujjící instalacní script bylo třeba doinstalovat perl a compat6x, což ukazuje na poněkud postarší binárky.

cd /usr/ports/lang/perl5.12/
make install clean

cd /usr/ports/misc/compat6x
make install clean

mount /cdrom
cp /cdrom/vmware-freebsd-tools.tar.gz /usr/tmp/

tar xvyf vmware-freebsd-tools.tar.gz
cd vmware-tools-distrib
./vmware-install.pl -d

...
Making sure services for VMware Tools are stopped.

Stopping VMware Tools services in the virtual machine:
Guest operating system daemon: done


No X install found.

Starting VMware Tools services in the virtual machine:
Switching to guest configuration: done
Guest memory manager: done
Guest operating system daemon: done
The configuration of VMware Tools 8.6.0 build-425873 for FreeBSD for this
running kernel completed successfully.

You must restart your X session before any mouse or graphics changes take
effect.

You can now run VMware Tools by invoking "/usr/local/bin/vmware-toolbox-cmd"
from the command line or by invoking "/usr/local/bin/vmware-toolbox" from the
command line during an X server session.

Please remember to configure your network by adding:
ifconfig_vxn0="dhcp"
to the /etc/rc.conf file and start the network with:
/etc/netstart
to use the vmxnet interface using DHCP.

Enjoy,

--the VMware team

Found VMware Tools CDROM mounted at /cdrom. Ejecting device /dev/acd0 ...

Již dříve jsem si poznamenal něco málo o status VMWare. S tím, že open-vm-tools vytváří status Unmanaged. Moc jsem toho o těchto stavech nedohledal.

Dnes jsem si ověřil, instalci vmware tools, které jsou součástí ESXi 5.0. A ty mají tento stav Running (Current) což je zase novinka.

Dle mého soudu je vhodnější používat port open-vm-tools-nox11, protože systém o daném SW ví a je možno jej snadno aktualizovat např. pomocí portupgrade.

pfSense CARP Cluster

V práci jsem dostal za úkol otestovat funkcionalitu firewalu pfSense verze 1.2.3 a zejména jeho Hardware Redundancy (CARP) a to ještě IPSec tunnel mezi router A a B. Tento firewal hojně používám, ale CARP jsem ještě nekonfiguroval. Stanovil jsem si cíl a tím bylo postavit za pomoci virtualizace celkem 4 routery, vždy dva a dva, které jsem umístil do jednotlivých DMZ rozsahů s veřejnými IP adresami.

Nejprve poznamenám, co že je to ten CARP. Ze zakoupené knihy jsem vyčel historii protokolu CARP - Common Address Redundancy Protocol, který vznikl jako svobodné řešení failover, jež vzniklo díky projektu OpenBSD. Společnost Cisco má svůj protokol VRRP a HSRP. Bohužel patenty znemožňují jejích implementaci ve svobodných otevřený systémech. CARP je tedy znám hlavně v *BSD systémech.



Mé kroky k zprovoznění pfSense Hardware Redundancy (CARP) vedly logicky na dokumentaci projektu pfSense. Zde je stručný popis failover firewallu. Dále je tu klikací tutorial, který objasní dané řešení. Zprovoznil jsem již zmíněné routery v ESXi 4.1, ktré vyžaduji 3 IP od ISP (veřejné adresy), dále pak potřebujeme 3 IP z LAN. Vždy dvě IP jsou přiřazeny jednotlivým routerům a jedna IP tvoří onen CARP interface, který zajišťuje přehození provozu z MASTER na BACKUP a případně naopak. Jednou z důležitých součástí tohoto řešení je pfsync, kterým si firewaly předávají informace jako FW Rule, NAT, IPSec, Virtual IP atd. Vše je patrné v tutorialu. Po zprovoznění funkční synchronizace, vytvoříme CARP interface, které přiřadíme do oddělených VHID Group. Na konzoli firewalu se nám objeví carpX device.

# ifconfig carp0
carp0: flags=49 metric 0 mtu 1500
inet 80.250.16.10 netmask 0xffffff80
carp: MASTER vhid 1 advbase 1 advskew 0
# ifconfig carp1
carp1: flags=49 metric 0 mtu 1500
inet 192.168.0.1 netmask 0xffffff00
carp: MASTER vhid 2 advbase 1 advskew 0

Po vytvoření CARP device na FW A se do pár sekund konfigurace přenese na FW B. Vše zajiťuje pfsync mechanizmus. Popisovat jednotlivé kroky není třeba, vše je jasně vidět v tutoriálu.

Dalším úkolem bylo nastavení IPSec tunelu mezi dvěma faiover firewall clustery (úžasná věta). Nastavením VPN / IPSec se nám zapne podpora IPSec, tím mám hlavně na mysli aktivace programu Racoon, který je soužástí ditribuce pfSense. Podpora IPSec je v *BSD díky implementaci KAME.net. Racoon zajišťuje výměnu klíčů mezi routery pomocí protokolu ISAKMP.

Nastavení VPN IPSec politik se opět přenese na druhý firewall v clusteru. Obdobná konfigurace proběhne i na druhé straně tunelu. A ejhle již např. ping ICMP jde z LAN A do DMZ A, kde se zabalí do ESP a předá na druhou stranu tunelu, kde se opět ESP otevře a vydá svůj poklad z LAN A na druhém konci tunelu.

Ohledně ESXi bylo nutno vytvořit a povolit v port groups nastavení, dle doporučení. Pozor, je to jistý bezpežnostní ústupek.

Pro otestování průchodů tunelu jsem si zprovoznil dva Ubuntu servery, které jsem posadil do LAN za failover routery. Mám oblíbený nástroj nesoucí jméno TTCP, který změří rychlost přenosu tunelem.

nasloucháme:

ubu-a:root:~> ttcp -v -r -s -f M -l 25600
ttcp-r: buflen=25600, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: socket
ttcp-r: accept from 192.168.2.10
ttcp-r: 52428800 bytes in 68.72 real seconds = 0.73 MB/sec +++
ttcp-r: 52428800 bytes in 0.57 CPU seconds = 87.72 MB/cpu sec
ttcp-r: 8981 I/O calls, msec/call = 7.84, calls/sec = 130.68
ttcp-r: 0.0user 0.5sys 1:08real 0% 0i+0d 416maxrss 0+6pf 8662+13csw
ttcp-r: buffer address 0xd94000

spojíme se s nasluchačem:

ubu-b:root:~> ttcp -v -t -s -f m -l 25600 192.168.1.10
ttcp-t: buflen=25600, nbuf=2048, align=16384/0, port=5001 tcp -> 192.168.10.100
ttcp-t: socket
ttcp-t: connect
ttcp-t: 52428800 bytes in 68.45 real seconds = 5.84 Mbit/sec +++
ttcp-t: 52428800 bytes in 0.03 CPU seconds = 13333.33 Mbit/cpu sec
ttcp-t: 2048 I/O calls, msec/call = 34.22, calls/sec = 29.92
ttcp-t: 0.0user 0.0sys 1:08real 0% 0i+0d 414maxrss 0+8pf 455+0csw
ttcp-t: buffer address 0x2468000

na routeru pfhaA je možno sledovat ESP šifrovaný provoz:

tcpdump -i em1 host 80.250.16.10 and host 193.179.144.106
13:11:04.453352 IP 193.179.144.106 > 80.250.16.10: ESP(spi=0x07d761dc,seq=0x1aaf8), length 116
13:11:04.453696 IP 80.250.16.10 > 193.179.144.106: ESP(spi=0x06061ce4,seq=0xd580), length 116
13:11:04.468895 IP 193.179.144.106 > 80.250.16.10: ESP(spi=0x07d761dc,seq=0x1aaf9), length 116
13:11:04.469151 IP 80.250.16.10 > 193.179.144.106: ESP(spi=0x06061ce4,seq=0xd581), length 116

Zde je právě probíhající vyměna klíčů o kterou se stará Racoon

13:12:31.622854 IP 193.179.144.106.isakmp > 80.250.16.10.isakmp: isakmp: phase 1 I agg
13:12:31.638247 IP 80.250.16.10.isakmp > 193.179.144.106.isakmp: isakmp: phase 1 R agg
13:12:40.712942 IP 193.179.144.106.isakmp > 80.250.16.10.isakmp: isakmp: phase 1 I agg
13:12:40.713083 IP 80.250.16.10.isakmp > 193.179.144.106.isakmp: isakmp: phase 1 R agg

ESXi 4.1 status Unmanaged

Na serveru s VMware ESXi 4.1.0, 260247 provozuji podporovaný OS FreeBSD-7.3-RELEASE. Mám instalované tooly z portů open-vm-tools-nox11. V vSphere klientovi vidím
status toolů Unmanaged. Pátral jsem po tom čím to a proč tento nový status.

open-vm-tools-nox11-313025_1 Open VMware tools for FreeBSD VMware guests

Zde je odpověď:
http://communities.vmware.com/thread/281949

Stávající mnou známé statusy:

OK
Not instaled
Not running
Out of date
Unmanaged
Running (Current)

vSphere Command-Line Interface

Na adrese http://communities.vmware.com/community/developer se náchází spousta vývojářských nástrojů pro práci s VMware produkty. Již delší dobu jsem si chtěl zprovoznit Command-Line Interface Díky tomuto nástroji se dá spousta věcí zautomatizovat. Potřebné balíky do Ubuntu pro instalaci.

sudo apt-get install libssl-dev perl-doc liburi-perl libxml-libxml-perl libcrypt-ssleay-perl

tar -zxvf VMware-vSphere-CLI-4.1.0-254719.x86_64.tar.gz
cd vmware-vsphere-cli-distrib/
sudo ./vmware-install.pl
...
version 0.78 or newer
UUID 0.03 or newer

Pár ukázek:

esxcfg-nas -l --server esxi.domena.cz --username root
Enter password:
VMNFS is /data from 192.168.10.42 mounted

esxcfg-cfgbackup --save --encoding utf8 --server esxi.domena.cz --username root esxi.cfg
Enter password:
Saving firmware configuration to esxi.cfg ...

esxcli --encoding utf8 --server esxi.domena.cz --username root vms vm list
Enter password:
TestFBSD81
World ID: 123002
Process ID: 0
VMX Cartel ID: 123001
UUID: 56 4d fc 69 14 5f 06 16-00 e6 09 ee 47 5e b9 9b
Display Name: TestFBSD81
Config File: /vmfs/volumes/4cdbbaaa-3d6f9e43-6d05-0030483274d9/TestFBSD81/TestFBSD81.vmx

vicfg-hostops --server esxi.domena.cz --username root -password "*****" --operation info

Host Name : esxi.domena.cz
Manufacturer : Supermicro
Model : X7DB8
Processor Type : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz
CPU Cores : 4 CPUs x 2999 GHz
Memory Capacity : 8190.71484375 MB
VMotion Enabled : no
In Maintenance Mode : yes
Last Boot Time : 2010-11-22T11:31:51.737555Z

resxtop --server esxi.domena.cz --username root -a

esxcli --server esxi.domena.cz --username root network connection list
esxcli --server esxi.domena.cz --username root network neighbor list
esxcli --server esxi.domena.cz --username root nmp device list

Např. zde je velmi pěkná ukázka využití CLI pro instalaci driveru. Doporučuji nastudovat tento dokument vsp4_41_vcli_inst_script.pdf

VMware Workstation upgrade z 7.0.1 na 7.1

Jsem aktivním uživatelem produktu VMware Workstation a užívám jej na Linux Ubuntu 10.04 LTS a to legálně :-) Firma nedávno zakoupila upgrade z 6.x na 7.x.

Po upgradu, který skoro vše pořešil sám. Tím mám na mysli odinstalování starší verze a instalaci nové.

sudo sh VMware-Workstation-Full-7.1.0-261024.x86_64.bundle

Po instalaci pouštím WinXP virtualku a ta nesíťuje. Kolega mi poradil a tak unončuji Workstation a pouštím příkaz.

sudo vmware-modconfig --console --install-all

Ten zkompilovat síťové drivery a asi i jiné věci a po startu XP vše funguje.

Problem s VMwareTools-3.5.0-213532

Tak už půl dne hledam zakopaného psa. Na testovacím serveru s Ubuntu 8.04.4 jsem aktualizoval systémové balíčky včetně kernelu a kernel-headers, pustil jsem se do instalace VMwareTools build 213532. Instalace proběhla bez chyb. Ovladač vmxnet se jeví jako natažený, daný interface je UP, síť funguje, ale jen s použitím IP. V celém systému se odmlčelo jakékoliv použití jmenných služeb DNS. Podotýkam, že změny v resolve.conf nenastaly a DNS server je funkční a odpovídá na dotazy.

Našel jsem zatím jen toto:
http://communities.vmware.com/thread/250159

Jestli je chyba v toolech nebo v Ubuntu, to se snad dozvím časem. Jako funkční řešení zatím doporučuji instalovat vmware-tools build 207095.

dočasné řešení problému:
odinstalovani vmware-tools build 213532

/etc/vmware-tools/installer.sh uninstall
update-initramfs -u
reboot

Dle hlášky je vše odtinstalováno, není tomu tak. Samotný vmxnet ovladač je ještě v initramfs, odkud se zavede do kernelu. Pro kompletní odstranění je třeba aktualizovat initramfs.



Dále už jen oživíme síť a někde seženeme starší verzi toolů a provedeme kompilaci a instalaci.

login to console as root
modprobe pcnet32

scp backup@old-tools:VMwareTools-3.5.0-207095.tar.gz ./
tar xvzf VMwareTools-3.5.0-207095.tar.gz
cd vmware-tools-distrib
./vmware-install.pl -d #(default install no question's)

dodatečné informace:
Driver vmxnet 0.9.0.2 se nějak nepovedl.

root@ubuntu:~# ethtool -i eth0
driver: vmxnet
version: 0.9.0.2
firmware-version: N/A
bus-info: 0000:00:11.0

root@ubuntu:~# uname -r
2.6.24-27-virtual

vmware-cmd v praxi na ESX

Nikdy bych si nemyslel, že budu potřebovat nastartovat nějakou virtualku (VM) pomocí příkazové řádky. Popisovat proč se tak stalo není nutné. Hlavní je, že to jde. Patřičné informace jsem dohledal zde.

Pomocí parametru -l si vypíšeme všechny vmx soubory (VM), pomocí kterých se


[root@esx root]# vmware-cmd -l
/vmfs/volumes/4774eb54-fcd75bd7-f878-221a64c6f89a/Ubuntu/Ubuntu.vmx
/vmfs/volumes/4774eb54-fcd75bd7-f878-221a64c6f89a/FreeBSD/FreeBSD.vmx

stop VM
[root@esx root]# vmware-cmd /vmfs/volumes/4774eb54-fcd75bd7-f878-221a64c6f89a/Ubuntu/Ubuntu.vmx stop trysoft
stop(trysoft) = 1

start VM
[root@esx root]# vmware-cmd /vmfs/volumes/4774eb54-fcd75bd7-f878-221a64c6f89a/Ubuntu/Ubuntu.vmx start
start() = 1

status VM
[root@esx root]# vmware-cmd /vmfs/volumes/4774eb54-fcd75bd7-f878-221a64c6f89a/Ubuntu/Ubuntu.vmx getstate
getstate() = on

Podrobná tabulka s popisem je na http://www.esxguide.com.

Resize VMFS disku na ESX 3.5.0 serveru

Pokud provozujeme na ESX serveru nějaký virtuální server a po nějaké době provozu se jeden z např. datových disků zaplní, máme dvě možnosti vytvořit disk nový a data překopírovat nebo ten stávající pomocí patřičného nástroje zvětšit. U druhé varianty jsem narazil na takový problém a tím je nemožnost navýšeni velikosti disku ve Virtual Infrastructure klientu (VI) v patřičném grafickém klikacím nástroji. Řešením je použít příkaz vmkfstools na ESX serveru.

1. vytvoříme si kopii dat disku, který budeme nafukovat!
   
2. vymažeme existující Snapshoty a vypneme VM
3. přihlásíme se na esx server pomoci ssh
4. cd /vmfs/volumes/VMFS_LUN0/UbuntuVMserver/ # nastavíme se do adresáře
   
5. podle VI GUI identifikujeme disk pro změnu
6. vmkfstools -X 20G UbuntuVMserver_1.vmdk # provedeme změnu velikosti VMFS disku
   
7. boot např. do LiveCD SystemRescueCD; startx; GParted
8. změníme velikost Ext3 file systému
9. nastartujeme VM

Pro lepší identifikaci, který soubor reprezentuje je dobré použít příkaz file.

[root@esx ]# file UbuntuVMserver_1*
UbuntuVMserver_1-flat.vmdk: x86 boot sector, extended partition table
UbuntuVMserver_1.vmdk: ASCII English text

Pozor, tento postup je funkční, jen za předpokladu, že u VM nemáte žádný Snapshot. Před touto akcí je nutno všechny vymazat.

Je hodně zarážející, že GUI klient nefunguje jak má a nutí adminy laborovat se samotnými daty Viruálního serveru, což může být destruktivní efekt.

FreeBSD make.conf / OPTIONS YES

Pokud se ve FreeBSD kompiluje nějaký port, máme možnost nastavovat některé kompilační volby. Né každý port má tuto možnost. Pokud ovšem např. chceme pustit kompilaci meta-portu Xorg nebo Gnome2 přez noc a nechceme dané volby ENTERovat (hrozné slovo) můžeme patřičnou volbu nastavit v make.conf. Vámi nastavené volby jsou uloženy v systémové databázi /var/db/ports/. Do daných souboru nezasahovat dané změny provádět v adresáři patřičného portu příkame make config a posléze můžeme port znovu zkompilovat např. pomoci portupgrade -f mc.

joe /etc/make.conf
BATCH=y

Tato volba není vhodná pro trvalé nastavení, protože jednotlivé porty se časem mění a zdokonalují a tato volba by použila defaultní nastavení a to né vždy chceme.

Pokud chceme nastavit některé volby opět můžeme v make.conf.

.if ${.CURDIR} == "/usr/ports/net/mtr"
WITHOUT_X11=yes
.endif

.if ${.CURDIR} == "/usr/ports/databases/mysql50-server"
WITH_OPENSSL=yes
WITH_XCHARSET=all
WITH_CHARSET=cp1250
WITH_COLLATION=cp1250_czech_cs
.endif

.if ${.CURDIR} == "/usr/ports/emulators/open-vm-tools"
WITHOUT_X11=yes
.endif

Díky Miku ...

Jak ověřím používání vmxnet driveru

Při instalaci VMWare Tools jsem narazil na takový malý problém a tím je užítí preferovaného sítového ovladače vmxnet. Stalo se mi, že se po manuální kompilaci toolů i nadále používa pcnet32 a ne doporučovaný vmxnet.

Jak zjistím, který síťový ovladač se používá, když mi lsmod vypíše dva drivery, které jsou nahrané v kernelu?

root@ubuntu:~# ethtool -i eth0
driver: vmxnet
version: 0.9.0.1
firmware-version: N/A
bus-info: 0000:00:11.0

root@ubuntu:~# ethtool -i eth0
driver: pcnet32
version: 1.34
firmware-version:
bus-info: 0000:00:11.0

Konkrétně se jedná o VMwareTools-3.5.0-153875.tar.gz (ESX 3.5.0 U4)

Nedoporučuje se mít v kernelu přítomné oba drivery. Né že by to nefungovalo, ale pokud se se nepoužíva, je vhodné jej dát na blacklist. Dík za radu Vladane ...

lsmod | grep pcnet32

joe /etc/modprobe.d/blacklist
blacklist pcnet32

update-initramfs -u

LiveAndroid - VMware Workstation

LiveAndroid - VMware Workstation
Originally uploaded by SmEjDiL

Dnes jsem si s radostí vyzkoušel OS Android, který je k dispozici v LiveCD verzi. Pustil jsem si jej virtuálně a časem se budu těšit na to až se mi do ruky dostane telefon, na kterém bude fungovat.

SSH na ESX 3.5i - stačí jen povolit

Čistě náhodou jsem nalezl na jednom Dánském serveru velmi jednoduchý návod, jak na ESXi povolit SSH. Ted už jen vyzkoušet v praxi.

How to enable SSH on ESX 3.5i Update 2/3

Jak Window$XP nainstalovat na ESXi 3.5

Včera jsem řešil tento problém s instalací Widlí. Instalační medium Window$XP Profesional bohužel neobsahuje ovladač SCSI BusLogic, který ESXi používá ve virtuální mašině. Návod na řešení problému jsem poměrně rychle vyGooglil. Zde si jej poznamenám až to zase zapomenu.

1. Stáhneme si obraz diskety s ovladačem BusLogic http://download3.vmware.com/software/vmscsi-1.2.0.4.flp
2. Daný soubor si pomoci Infrastructure Clienta nahrajeme na úložiště ESXi
3. V již vytvořené Virtualní mašině připojíme k zařízení diskety danou image obdobně jako se to běžně dělá i obrazem CD pro instalaci.
4. Pustíme VM a rozběhne se instalace, která již pevný disk nalezne.

Obdobný návod je např. zde.

FreeBSD 7.2 RELEASE

Hnedle po vydání testuji nové FreeBSD ve VMWare Workstation. V rámci vzděláváni testuji Apache22, mod_jk a Tomcat6, taktéž i Open Vm Tools.

Jakou verzi ESX používám?

VMWare Tools obsahuje jeden program vmware-checkvm, který nám neřekne verzi ESX, ale jen VMware software version 6 (good). Pokud pravidelně aktualizujeme tooly máme možnost zjistit verzi následovně.

server:root:~> cat /usr/bin/vmware-config-tools.pl | grep buildNr
my $buildNr;
$buildNr = '3.5.0 build-153875';
return remove_whitespaces($buildNr);

Tímto způsobem zjistíme verzi vmware tools, které jsou v hostovaném systému nainstaovány. Pokud používáme starší VMware Tools na novějším ESX, VI Client nás na to upozorní. Hostovaným OS je Ubuntu 8.04.2.

VMWare tools pro Ubuntu 8.04.2 (JeOS)

Instalace vmware tools je nutná pro komunikaci hostovaného OS s virtualizačním serverem např. ESX. Ubuntu má podporu, ale např. ovladač vmxnet se prozatím musí kompilovat, pomocí perlového instalačního scriptu. Popis, jak na to je zde:

https://help.ubuntu.com/community/JeOS

VMWare uvolnil vmware tools. Tak se snad již brzy dočkáme jednodužšího způsobu instalace toolsů. Vzniklý projekt open vm tools by mohl do budoucna umožnit existenci potřebných balíčků s drivery atd. Open vm tools jsem již testoval na FreeBSD, kde existuje funkční port, popřípadě serverová verze bez X-Windows.

Zprávička na rootu ohlasila 20. 12. 2008 23:20
http://www.root.cz/zpravicky/oficialni-repositare-s-vmware-tools/

Bohužel balíčky nejsou moc aktuální, koukal jsem na tuto adresu http://packages.vmware.com/tools/ Snad se dočkáme toho že toolsy budou součásti ESX stejně jako tomu je u rpm balíčku.

Ubuntu JeOS pod ESX tuhne 2xCPU

Tak jsem byl poněkud nešťastný z toho že mi tuhne VM pod velkou zátěží. Naštěstí je Ubuntu 8.04.2 LTS podporovaným OS alespoň ve verzi VMware ESX 3.5.0 U3 build 123630

VMWare vydal své KB kde je problém popsán a řešen.

http://kb.vmware.com/kb/1007020

SMP virtual machines running Linux using the TSC clocksource stop responding or stall

Zde je popsáno jak problém řešit.
http://kb.vmware.com/kb/1004384

joe /boot/grub/menu.lst
U kernel přidat na konec toto
clocksource=acpi_pm
reboot

v dmesg se objeví dané záznamy
[ 0.000000] Kernel command line: root=UUID=0f7.... ro quiet splash clocksource=acpi_pm
[ 6.042048] Time: acpi_pm clocksource has been installed.

Ten kdo provozuje nějaký UNIX pod VMWare je velmi vhodné sledovat pravidelně aktualizovaný dokument Guest Operating System Installation Guide.