Monthly Archives: November 2012
It’s a real pleasure to see great initiative like these from the CLOUD Giant VMware, it’s a good opportunity to learn the new product features, test through online. For those who don’t have a vSphere lab this will be a great relief.
I have registered and successfully completed one of the labs, I am just sharing my experience and a Quick, how to Guide to interact and use this LAB facility.
Once you have registered for the HOL lab as per my previous blog https://pibytes.wordpress.com/2012/11/23/free-vmware-hands-on-lab-hurry-up/
You can start now !!
Refer the below links for more details and lab manuals
1, Log in to the portal https://www.projectnee.com/HOL
2, Click the “Cloud Infrastructure” > and Click the corresponding labs which you want to do and click “ENROLL”
3, Once Enrolled click the “My Enrollments” and you can see your enrolled courses. Now click the “START THE LAB” Option
4, Once you started the lab the LAB console will open
5, Once loaded you will see the below, and the menus are self explanatory
6, Use full screen mode in the LAB, and you can see the LAB manual
7, The user name to login is “Administrator” and password is “VMware1!”
8, Once login you will get the below window
9, Now open the Internet Explorer browser, for accessing the vCenter web console.
10, Now Click the Side Button “Manual” for the LAB steps and Table of contents and ENJOY !!
11, When you TIERD, you can pause the LAB session and resume after some time
12, After a CUP of TEA/COFFE you can resume the LAB
13, Once you completed the LAB by following the steps mentioned in the MANUAL, you can END the LAB
14, Once completed you ROCKS !!
15, Now go the Home page, and click the Transcript and you can see the result !!!!
It is very nice and great initiative from VMware to provide these facilities to study and experience the new features of vSphere and vCloud suite.
The VMware Hands-on Labs Online Public Beta is now open!
At VMworld 2012 VMware announced that the Hands-on Labs experience will soon be available online. I am excited to let you know that registration is now open and you may add your name to the interest list here:
Just click the above link and register with your email id and complete the survey that’s it. You will get an email acknowledgement from VMware, saying that an account has been created. If not, or just to speed up the process – just shoot an email to firstname.lastname@example.org I got all the access in 30 min !!
You will get the user name and password from the VMware.
After registering on the interest list, be sure to participate in the HOL Communities site at http://www.vmware.com/go/hol
The HOL overview and lab manuals are listed at http://communities.vmware.com/docs/DOC-20212
Once done you will see like below…. and start the labs
VMware Workstation provides several ways you can configure a virtual machine for virtual networking.
If you select the Typical setup path in the New Virtual Machine Wizard when you create a virtual machine, the wizard sets up bridged networking for the virtual machine. You can choose any of the common configurations — bridged networking, network address translation (NAT) and host-only networking — by selecting the Custom setup path. The wizard then connects the virtual machine to the appropriate virtual network.
You can set up more specialized configurations by choosing the appropriate settings in the virtual machine settings editor, in the virtual network editor (on Windows hosts) and on your host computer.
On a Windows host, the software needed for all networking configurations is installed when you install VMware Workstation. On a Linux host, when you install Workstation, you can choose whether to have bridged and host-only networking available to your virtual machines: you must choose both options during the Workstation installation to make all networking configurations available for your virtual machines.
Bridged networking connects a virtual machine to a network using the host computer’s Ethernet adapter.
Bridged networking is set up automatically if you select Use bridged networking in the New Virtual Machine Wizard or if you select the Typical setup path. This selection is available on a Linux host only if you enable the bridged networking option when you install VMware Workstation.
If your host computer is on an Ethernet network, this is often the easiest way to give your virtual machine access to that network. Linux and Windows hosts can use bridged networking to connect to both wired and wireless networks.
If you use bridged networking, your virtual machine needs to have its own identity on the network. For example, on a TCP/IP network, the virtual machine needs its own IP address. Your network administrator can tell you whether IP addresses are available for your virtual machine and what networking settings you should use in the guest operating system. Generally, your guest operating system may acquire an IP address and other network details automatically from a DHCP server, or you may need to set the IP address and other details manually in the guest operating system.
If you use bridged networking, the virtual machine is a full participant in the network. It has access to other machines on the network and can be contacted by other machines on the network as if it were a physical computer on the network.
Be aware that if the host computer is set up to boot multiple operating systems and you run one or more of them in virtual machines, you need to configure each operating system with a unique network address. People who boot multiple operating systems often assign all systems the same address, since they assume only one operating system will be running at a time. If you use one or more of the operating systems in a virtual machine, this assumption is no longer true.
If you make some other selection in the New Virtual Machine Wizard and later decide you want to use bridged networking, you can make that change in the virtual machine settings editor (VM > Settings).
The VM-1 can communicate to the HOST operating system, and connect to the outside LAN/INTERNET, but cannot communicate to the NAT and HostOnly networks.
Host-only networking creates a network that is completely contained within the host computer.
A host-only network is set up automatically if you select Use Host-only Networking in the New Virtual Machine Wizard. On Linux hosts, this selection is available only if you enabled the host-only networking option when you installed VMware Workstation.
Host-only networking provides a network connection between the virtual machine and the host computer, using a virtual Ethernet adapter that is visible to the host operating system. This approach can be useful if you need to set up an isolated virtual network.
If you use host-only networking, your virtual machine and the host virtual adapter are connected to a private Ethernet network. Addresses on this network are provided by the VMware DHCP server.
If you make some other selection in the New Virtual Machine Wizard and later decide you want to use host-only networking, you can make that change in the virtual machine settings editor (VM > Settings).
The VM-5 and VM-4 can communicate to each other, and cannot communicate to the HOST operating system and other VM’s in the HostOnly network.
The VM-6 and VM-7 cannot communicate each other, Bridged and to the HOST network also.
Network Address Translation (NAT)
NAT gives a virtual machine access to network resources using the host computer’s IP address.
A network address translation connection is set up automatically if you follow the Custom path in the New Virtual Machine Wizard and select Use network address translation.
If you want to connect to the Internet or other TCP/IP network using the host computer’s dial-up networking or broadband connection and you are not able to give your virtual machine an IP address on the external network, NAT is often the easiest way to give your virtual machine access to that network.
NAT also allows you to connect to a TCP/IP network using a Token Ring adapter on the host computer.
If you use NAT, your virtual machine does not have its own IP address on the external network. Instead, a separate private network is set up on the host computer. Your virtual machine gets an address on that network from the VMware virtual DHCP server. The VMware NAT device passes network data between one or more virtual machines and the external network. It identifies incoming data packets intended for each virtual machine and sends them to the correct destination.
If you select NAT, the virtual machine can use many standard TCP/IP protocols to connect to other machines on the external network. For example, you can use HTTP to browse Web sites, FTP to transfer files and Telnet to log on to other computers. In the default configuration, computers on the external network cannot initiate connections to the virtual machine. That means, for example, that the default configuration does not let you use the virtual machine as a Web server to send Web pages to computers on the external network.
If you make some other selection in the New Virtual Machine Wizard and later decide you want to use NAT, you can make that change in the virtual machine settings editor (VM > Settings).
In the above diagram, the VM-2 & VM-3 can communicate to each other and other VM’s in the NAT network, and also to the HOST operating system
If we looked in to the host services, we can see the below main services for the Virtual networking.
The DHCP (dynamic host configuration protocol) server provides IP network addresses to virtual machines in configurations that are not bridged to an external network — for example, host-only and NAT configurations.
The NAT (network address translation) device allows you to connect your virtual machines to an external network when you have only one IP network address on the physical network, and that address is used by the host computer. You can, for example, use NAT to connect your virtual machines to the Internet through a dial-up connection on the host computer, through the host computer’s Ethernet adapter, or through a wireless Ethernet adapter.
The NAT device is set up automatically when you install VMware Workstation. (On a Linux host, you must choose to make NAT available to your virtual machines.)
Last week I faced a very critical issue with our Oracle RAC cluster in vSphere 5, for the ESXi maintenance we have performed a VMotion on the Oracle nodes – then the FUN began !!
We have 2 node oracle RAC cluster running on Vsphere5
For the Oracle RAC cluster we are using VMFS5 file system, I mean VMDK only (no RDM)
Oracle nodes are using windows 2008 R2 SP1 and oracle 184.108.40.206
The clusters are running on HP Blade center C7000 with ProLiant BL680c G7 blades
The ORACLE private and public network are using vDS (VMware distributed switch)
Storage, we are using HP 3PAR FC SAN for the vsphere5
We performed a VMotion on Oracle RAC cluster nodes one by one, after that we got a BSOD for both nodes and the VM’s crashed completely.
I spent some time in researching the stop code that was in the BSOD: STOP 0x0000FFFE
It appears that it is not a normal blue screen, as the above stop code is not given from Microsoft. It is actually a forced blue screen from Oracle. Unfortunately, I am unable to find specific information regarding it from Oracle’s website, but I did find the following blog article (this information may not be completely reliable as it is just a blog article):
“OraFence has a built-in mechanism to check it was scheduled in time. If it is not scheduled within 5 seconds it will also reboot the note. In this way, OraFence is designed to fence and reboot a node if it perceives that a given node is ‘hung’ once its own timeout has been reached. Note that the default timeout for the OraFence driver is a (very low) 0x05 (5 seconds). What this means is that if the OraFence driver detects what it perceives to be a hang for example at the operating system level and that hang persists beyond 5 seconds, it’s possible that the OraFence driver – of its own accord – will fence and evict the node.” —
RCA for the ISSUE :
The above article suggests that a simple timeout could cause an Oracle driver to BSOD the machine with the stop code 0x0000FFFE. This would be something that could occur during a vMotion simply because, during the VMotion the operating system is quiesced, and depending upon the VM RAM and VMotion configuration it will take around 16 seconds to complete the VMotion (we have configured MultiNic VMotion in the HP Blades)
Oracle uses fencing mechanism for the RAC cluster, just like the SCSI fencing in the REDHAT CLUSTER to reboot the nodes. Because of the VMotion quiescence process and with default timeout for the OraFence driver 5 seconds, because the VMotion quiescence took more than 5 seconds and this caused the BSOD.
The above blog article recommends increasing the timeout from 5 seconds because that is very aggressive.I would recommend contacting Oracle Support with the details, as they would probably have a more complete picture of how their product forces a BSOD and how to avoid it in the future.
Increase the default timeout for the OraFence driver, so the BSOD should not occur again due to a quiesced operating system (during VMotion or in DRS/HA environment)
While designing the Oracle RAC cluster in vSphere, taking this consideration will avoid such crashes. Also if you are running the RAC nodes in the VMware HA/DRS environment, this should be considered.
Recently I faced a big issue with my client, we are migrating VM’s from old HP Proliant servers to HP Bladecenter, we are using
vSphere5, HP BL680c G7 Blades (Full-height, double-wide blade – 512GB RAM, Quad socket), HP 3PAR V400 FC SAN
The VM’s are very huge in VMDK level, some of them are 10TB and most of the others are in the range 2 to 3 TB VMDK. We have moved around 140 VM’s (35 per ESXi host).
After that we are not able to do VMotion, DRS, SVMotion and we are not able to create new VM’s.
I believe those who are are going/planning to achieve more consolidation ratio in their datacenter with vSphere, will definitely face this issue. Now a days the HP/IBM Bladecenters/ IBM PureFlex etc dominates the big Datacenters and also the Specs of the Rack servers, RAM size etc are huge. So while doing the new vSphere implementation or Design, this factor has to be considered well in advance.The errors we got are;
During SVmotion –
Relocate virtual machine lf0hrap01p.xxxx A general system error occurred: Storage VMotion failed to copy one or more of the VM ‘s disks. Please consult the VM’s log for more details, looking for lines starting with “SVMotion”.
During VMotion –
Migrate virtual machine wfowsus1p.xxxx A general system error occurred: Source detected that destination failed to resume.
During HA –
After virtual machines are failed over by vSphere HA from one host to another due to a host failover, the virtual machines fail to power on with the error:
vSphere HA unsuccessfully failed over this virtual machine. vSphere HA will retry if the maximum number of attempts has not been exceeded. Reason: Cannot allocate memory.
During manual VM migration –
When you try to manually power on a migrated virtual machine, you may see the error:
The VM failed to resume on the destination during early power on.
Reason: 0 (Cannot allocate memory).
Cannot open the disk ‘<<Location of the .vmdk>>’ or one of the snapshot disks it depends on.
You see warnings in /var/log/messages or /var/log/vmkernel.log similar to:
vmkernel: cpu2:1410)WARNING: Heap: 1370: Heap_Align(vmfs3, 4096/4096 bytes, 4 align) failed. caller: 0x8fdbd0
vmkernel: cpu2:1410)WARNING: Heap: 1266: Heap vmfs3: Maximum allowed growth (24) too small for size (8192)
cpu4:1959755)WARNING:Heap: 2525: Heap vmfs3 already at its maximum size. Cannot expand.
cpu4:1959755)WARNING: Heap: 2900: Heap_Align(vmfs3, 2099200/2099200 bytes, 8 align) failed. caller: 0x418009533c50
cpu7:5134)Config: 346: “SIOControlFlag2” = 0, Old Value: 1, (Status: 0x0)
The reason for this issue is, with the default installation/configuration of ESXi host, there is a limitation in the VMkernel, to handle the Opened VMDK files in the VMFS file system.
The default heap size in ESXi/ESX 3.5/4.0 for VMFS-3 is set to 16 MB. This allows for a maximum of 4 TB of open VMDK capacity on a single ESX host.
The default heap size has been increased in ESXi/ESX 4.1 and ESXi 5.x to 80 MB, which allows for 8 TB of open virtual disk capacity on a single ESX host.
From the VMware KB article 1004424 it is explained and the steps to resolve this issue.
We need to change the VMFS heap size of the ESXi host to 256 MB, and reboot the host.
– In the article it is mentioned VMFS3 and in the ESXi5 host advance configuration also you only see the VMFS3, but this applies to VMFS5 also. We confirmed from the VMware technical support.
– The VMFS Heap is a part of the kernel memory, so increasing this will increase memory consumption of the kernel which results in shortage of memory for other VM’s on the system.