I believe the Next Generation Computing is Software Defined Infrastructure on top of the robust physical infrastructure. You can ask me anything about enterprise infrastructure (virtualization, compute, storage, network) and we can discuss it deeply on this blog. Don't hesitate to contact me.
Thursday, July 24, 2008
VirusTotal
Tuesday, July 08, 2008
Wednesday, June 25, 2008
Understanding and fixing VMware ESX problems without pulling the plug
Understanding and fixing VMware ESX problems without pulling the plug
Eric Siebert, Contributor
06.24.2008
LINK TO ARTICLE
Wednesday, June 04, 2008
VMware: configuring a static MAC address in a VM
Sometimes it can be necessary to configure a static MAC address in a VM. A typical issue during P2V is an application that has its licensing based on the MAC address.
VMware has defined that VirtualCenter does not use the following range: 00:50:56:00:00:00 to 00:50:56:3F:FF:FF where 00:50:56 is the OUI.
The steps:
1. Power off & remove the server from the VirtualCenter inventory. This is a necessary step, because VC will overwrite your settings during Power On!
2. Edit the .vmx file and locate the following generated MAC address:
Ethernet0.addressType =
and
Ethernet0.generatedAddress =
3. Change the value for ethernet0.addressType from “vpx” to “static”
4. Change ethernet0.GeneratedAddress to ethernet0.Address
5. Change the current MAC to a MAC address in the following range:
00:50:56:00:00:00-00:50:56:3F:FF:FF
6. In VirtualCenter, select an ESX host and go to storage
7. Browse the data store & locate your VM
8. Right-click on the .vmx file, and select Add to inventory
9. Power On the server. Issue the command ipconfig /all and locate the VMware NIC. Your manually assigned MAC address should be there.
I know you can set your MAC address inside Windows, but I would avoid this.
Tuesday, June 03, 2008
Monday, June 02, 2008
DELL Professional Services aneb GICS
http://davidpasek.blogspot.com/2006/06/dell-jak-ho-mon-neznte.html
Presne 15.5.2008 jsem se stal clenem byvaleho DPS - DELL Professional Services, ktere se dnes jmenuje GICS - Global Infrastructure Consulting Services. Moje zamereni je primarne na serverovou konsolidaci a virtualizaci, nicmene jelikoz jsem zatim prvni Solution Architect DELLu v Ceske Republice, tak mam na starosti i enterprise storage a networking.
Wednesday, April 16, 2008
Friday, March 21, 2008
ESX Server, NIC Teaming, and VLAN Trunking
...
There are actually two different pieces described in this article. The first is NIC teaming, in which we logically bind together multiple physical NICs for increased throughput and increased fault tolerance. The second is VLAN trunking, in which we configure the physical switch to pass VLAN traffic directly to ESX Server, which will then distribute the traffic according to the port groups and VLAN IDs configured on the server. I wrote about ESX and VLAN trunking a long time ago and ran into some issues then; here I’ll describe how to work around the issues I ran into at that time.
...
Full article:
http://blog.scottlowe.org/2006/12/04/esx-server-nic-teaming-and-vlan-trunking
Other useful technical paper about VLAN on ESX is at
http://www.vmware.com/resources/techresources/412
Monday, March 17, 2008
Friday, March 14, 2008
How to Set up VNC on Debian GNU/Linux
Installation and usage
You've just installed Debian, but your wife wants her monitor back. That's OK, you were planning on running it headless, anyway. But, wouldn't it be nice to check out some of those groovy GUI apps? Don't fret, VNC will let you interact with a desktop environment from just about any platform available.
Install vncserver (as root): apt-get install vncserver
Choose your desired window size and color depth, then, as an ordinary user, open a terminal and type:vncserver -geometry 1024x768 -depth 24
orvncserver -geometry 1024x768 -depth 24 -pixelformat rgb565
This will prompt you to create a password:
You will require a password to access your desktops.
Password:
Verify
The server will start and tell you where to access it:
New 'X' desktop is foobar:1
Starting applications specified in /etc/X11/Xsession
Log file is /home/jorey/.vnc/foobar:1.log
Open the VNC viewer on your remote machine, enter the hostname:screen and password (use a hostname or IP that your client machine understands), and your Linux desktop will open in a window! Network speed and processor power will affect performance, but it's amazing how many apps will run fine under VNC. You might not be able to play Frozen Bubble, but you can use productivity applications without any trouble.
To kill the server enter a command similar to this, using the appropriate settings:vncserver -kill :1
The reason for killing the session is that you may need to edit the default configuration file that vncserver creates for you, for example to get the vncserver to run the K desktop environment instead of twm, you may want to edit the $HOME/.vnc/xstartup file to replace the line:
twm &
with this line is you use KDE:
startkde &
and with this line if you use GNOME:
gnome-session &
before launching the vncserver again using:
vncserver :1 -geometry 1024x768 -depth 16 -pixelformat rgb565
VNC over OpenSSH
The following is just a summary of the full explanation. To use VNC over OpenSSH, first you need to run an
ssh session on the machine where you will be running the vncviewer, to request that ssh listen on a particular port on your local machine, and forward communication on that port down the secure connection to a port on the machine running the vncserver.
For example:
ssh -L x:localhost:y vncserver_machine
means "Start an SSH connection to the vncserver_machine, and also listen on port x on my machine, and forward any connections there to port y on the vncserver_machine."
Now, the VNC protocol normally uses port 59xx, where xx is the display number of the server. So a VNC server on a Windows machine, which normally uses display number 0, will listen on port 5900. The first VNC server on linux will probably use display number 1, and subsequent servers would use 2, 3, etc. and so the vncservers on linux will be listening on ports 5901, 5902 and so forth. By forwarding these ports to a remote machine running vncserver, you can make the remote VNC server appear to be a server running on your local machine. So, imagine you had a VNC server running as display :1 on vncserver_machine, and you wanted a secure connection to it from your local machine. You could start the ssh session using:
ssh -CL 5902:localhost:5901 vncserver_machine
After that, starting up the vncviewer as follows on your local machine: vncviewer -encodings "copyrect hextile" localhost:2 would actually connect to display :1 on the vncserver_machine.
Note that the above OpenSSH command-line is deliberately meant to accept incoming connections only from the local machine. This means that to use the ssh connection that we have just set up, we must connect to it from the same machine, using the special name localhost, rather than using the local machine's own unique name.
This article is compiled from following resources:
http://www.joreybump.com/code/howto/debian/vnc.html
http://www.penlug.org/twiki/bin/view/Main/TightVNC
X Window Servers
http://mediakey.dk/~cc/x11-for-windows-xp-and-vista/
X Ming "X Server"
http://www.straightrunning.com/XmingNotes/
"X Server" for Mac OS X
http://www.apple.com/downloads/macosx/apple/
macosx_updates/x11formacosx.html
Tuesday, February 26, 2008
@@VMWARE@@ UTS_RELEASE
Paolo Conti wrote how to hack VMware tools to work on linux kernels 2.6.18
[CITATION FROM http://www.atlink.it/~conti/2007/12/19/vmware-uts_release/]Well, VMWare tools sometimes fails to install into a Linux guest with recent kernel.
The error is something like this: The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match your running kernel (version 2.6.18.2-34-default). Even if the module were to compile successfully, it would not load into the running kernel.
With this bug you cannot sync the time with your hosting server, automate shutdown tasks, etc… This problem exist because the kernel source code structure is changed in recent kernels (I guess > 2.6.18). The VMWare tools installation script is looking for the string “#define UTS_RELEASE $kernel_number” into /usr/src/kernels/$(uname -r)*/include/linux/version.h but the UTS_RELEASE variable is now into the file utsrelease.h.
To fix this, you can patch the VMWare tools installation script or just add the content of utsrelease.h to version.h. I suppose the second solution is the fastest one
To do this:
cd /usr/src/kernels/$(uname -r)*/include/linux
cat utsrelease.h >> version.h
Happy virtualization folks!
Saturday, February 23, 2008
Eth0 disappears after cloning
Sunday, January 06, 2008
System Management & Monitoring server - ZENOSS
Monday, December 24, 2007
Thursday, December 20, 2007
Very interesting blog about DB & STORAGE performance
Sunday, December 09, 2007
Sunday, December 02, 2007
VMWare appliances with pre-installed Operating Systems
Wednesday, November 28, 2007
Internet FailOver script for FreeBSD written in Perl
#!/usr/bin/perl
use Net::Frame::Device;
use Net::Ping;
$uplink1_interface="sis0";
$uplink2_interface="sis1";
$lan_interface="sis2";
$primary_gateway="10.0.3.1";
$secondary_gateway="10.10.1.1";
# print current date and time
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime(time);
$year=$year+1900;
print "GMT Time: $year-$mon-$mday $hour:$min:$sec\n";
my $device_uplink1 = Net::Frame::Device->new(dev => $uplink1_interface);
my $device_uplink2 = Net::Frame::Device->new(dev => $uplink2_interface);
my $device_lan = Net::Frame::Device->new(dev => $lan_interface);
print "Current default gateway:", $device_lan->gatewayIp, "\n";
print "Primary default gateway:", $primary_gateway, "\n";
print "Secondary gateway:", $secondary_gateway, "\n";
print "Checking primary internet uplink ...\n";
if (check_uplink($primary_gateway)) {
if ($device_lan->gatewayIp ne $primary_gateway) {
# set default route to $primary_gateway
`route delete default`;
`route add default $primary_gateway`;
# Change uplink interface to uplink1_interface
change_nat_interface($uplink1_interface);
# restart IPFW and NATD daemon
`/etc/rc.d/ipfw restart`;
print "Default gateway has been changed to $primary_gateway via interface $uplink1_interface\n";
} else {
print "Current default gateway is set to primary gateway and is ok\n";
}
} elsif (check_uplink($secondary_gateway)) {
if ($device_lan->gatewayIp ne $secondary_gateway) {
# set default route to $secondary_gateway
`route delete default`;
`route add default $secondary_gateway`;
# Change uplink interface to uplink2_interface
change_nat_interface($uplink2_interface);
# restart IPFW and NATD daemon
`/etc/rc.d/ipfw restart`;
print "Default gateway has been changed to $secondary_gateway via interface $uplink2_interface\n";
} else {
print "Current default gateway is set to secondary gateway and is ok\n";
}
} else {
print "Any uplink is up and working\n";
}
print "----\n";
######################################################
# Ping IP address and decide if it's reachable or not
# 1.parameter: IP
######################################################
sub check_uplink {
my ($ip) = @_;
my $p = Net::Ping->new("icmp");
my $ok = $p->ping($ip);
$p->close();
return $ok; # 0 - false; 1 - true
}
######################################################
# Change NATD interface file
# 1.parameter: network interface
######################################################
sub change_nat_interface {
my ($nat_if) = @_;
$filename="/tmp/natd_iface";
if (open(F, "> $filename")) {
print "change_nat_iface: writing $nat_if to $filename\n";
print F $nat_if;
close F;
} else {
print "change_nat_iface: Cannot write to $filename\n";
return 0;
}
return 1; # 0 - false; 1 - true
}