Eon Networks - build your network intelligently

Firewall, Why?

2009-09-23T17:43:00.000+05:30

Firewalls are usually seen as a requirement if you are going to attach your network to other networks, especially the Internet. Unfortunately, some network administrators and managers do not understand the strengths a firewall can offer, resulting in poor product choice, deployment, configuration and management. Like any security technology, firewalls are only effective if the implementation is done properly and there is proper maintenance and response to security events.

Additionally, with the proper deployment of firewalls other security strategies are often much easier to integrate, such as VPNs and IDS systems. So what makes firewalls good, and what can you do to ensure they are used properly?

Perimeter Defence

One of firewalls' weaknesses is also one of their strengths. Firewalls are typically deployed as a perimeter defence, usually intersecting network links that connect your network to others. If the firewall is properly deployed on all paths into your network, you can control what enters and leaves your network.

Of course, as with any form of perimeter defence, if an attack is launched from inside, firewalls are not too effective. However, this deployment on your network perimeter allows you to prevent certain kinds of data from entering your network, such as scans and probes, or even malicious attacks against services you run.

Conversely, it allows you to restrict outbound information. It would be nearly impossible to configure every workstation to disallow IRC, but blocking ports 6667-7000 (the most common IRC ports) is relatively easy on your perimeter firewalls.

While you can employ access control lists on servers internally, this still allows attackers to scan them, and possibly talk to the network portion of the OS on the server — making a number of attacks possible. This perimeter also allows you to deploy IDS systems much more easily, since "chokepoints" will have already been created, and you can monitor all data coming in or leaving.

VPN deployment also becomes easy. Instead of loading up VPN software on every desktop that might need it, you can simply employ VPN servers at those network access points, either as separate servers or directly on your firewall, which is becoming increasingly popular.

Concentrated Security

Controlling one, or even multiple firewalls is a much easier job than maintaining access control lists on numerous separate internal servers that are probably not all running the same operating system or services. With firewalls you can simply block all inbound mail access except for the official mail server. If someone forgets to disable email server software on a newly installed server, you do not need to worry about an external attacker connecting to it and exploiting any flaws.

Most modern firewall products are administered from a central console. You get an overall view of your network and can block or allow services as needed very quickly and efficiently.

With VPN-capable firewalls you can easily specify that access to certain networks must be done via encrypted tunnels, or otherwise blocked. With VPN software on each client, you would have more to worry about with misconfiguration or user interference. This results in sensitive data being accidentally sent out unencrypted. If your firewall is set up to block all but a few specific outbound services, then no matter what a user does - even to bring in their own laptop - they will probably not be able to access the blocked services. Enforcing this without firewalls and instead on each client machine is nearly impossible.

Enforcement of Security Policies

You may have a set of corporate guidelines for network usage that include such items as:

Chat clients such as IRC, AIM, and Yahoo IM are strictly forbidden, as they can transfer files.
Accessing external mail servers is forbidden (antivirus policy); only use the internal server to send or receive.
Network games, such as Doom or Quake, are forbidden, except between 8 a.m. and 6 p.m. all weekdays for members of management.
Websites such as playboy.com are forbidden for legal reasons.

Enforcing the first policy without a firewall would be possible, but difficult. In theory, if you managed to secure every single desktop machine and prevent users from installing software, it would be possible. Then you would need to prevent people from attaching "rogue" laptops and so forth to the internal LAN with software preinstalled. While possible, this is a Herculean task compared to configuring a dozen rules (or even a hundred rules) on your firewalls to prevent access to the ports and servers that IRC, AIM and the rest use.

The second policy would be very difficult to enforce without a firewall. You would need to do the above steps to prevent people from installing their own email software or using rogue machines such as laptops with it preinstalled. Moreover, any email software you do use (such as Outlook or Eudora) would need to be configured so that users could not modify any preferences, add new accounts and so on. This is not possible in almost all email clients.

The third policy is virtually impossible to enforce without a firewall. You would need to take the above steps to prevent any user except for management installing the software. One possibility would be to place the software on a network share and only make it available from 6 p.m. to 8 a.m., and on weekends to users of the management group. However, many network games would not function properly, and you would have to prevent the software from being copied off, etc.

Even with all this, the software may still continue to function after 8 a.m. if it is running on the client machine (or it might crash horribly). In any event, this is much easier to enforce with a firewall such as FW-1: enable user authentication, then define a policy that allows users of the management group access to the ports used by these games at the appropriate times.

Enforcing policy number four is basically impossible as well without a firewall. While some Web clients do allow you to list sites that are off limits, keeping the browsers on multiple workstations up to date would be a virtually impossible task. Compare that with configuring the firewall to force WWW access through an application-level.

A Secure Network Is a Healthy Network

Generally speaking, any security implementation done in a network will help with its overall health. Cataloguing systems and software versions to decide what needs upgrading first, implementing automated software upgrade procedures, and so on all helps with the overall health of your network and its systems.

A network configuration that creates chokepoints for firewall deployment also means you can easily implement a DMZ, a zone with servers to handle inbound and outbound information with the public. These servers can typically run a hardened and stripped down OS and application software. A proxy email server, for example, only needs to be able to accept and send email. There is no need for user accounts, POP or IMAP services, or GroupWare software integration.

Usually the simpler a system is, the easier it is to secure, and hence the harder it is for an attacker to break into. Securing a messy network is almost impossible. You must find out what you have, which versions, where the servers are deployed, what network links exist, and so on

Secure Socket Tunneling Protocol

2009-09-23T17:09:00.004+05:30

SSTP (Secure Socket Tunnelling Protocol) and the VPN capabilities it will offer in future

The article will give a clear understanding of SSTP and compare standard VPN vs SSTP VPN. The article will also cover the advantages of utilizing both SSTP and VPN simultaneously and what the benefits of using SSTP will be.

VPN

Virtual private network, also referred to as VPN, is a network that is constructed with the use of public wires to join nodes, enabling the user to create networks for the transfer of data. The systems use encryption and various other security measures to ensure that the data is not intercepted by unauthorized users. For years VPN has been used successfully but has recently become problematic due to the increase in the number of organizations encouraging roaming user access. Alternative measures have been looked at to enable this type of access. Many organizations have begun to utilize IPSec and SSL VPN as an alternative. The other new alternative being SSTP, also referred to as ‘Microsoft’s SSL VPN’.

Problems with typical VPN

VPNs typically use an encrypted tunnel that keeps the tunneled data confidential. By doing this when the tunnel routes through typical NATed paths the VPN tunnel stops working. VPNs typically connect a node to an endpoint. It may happen that both the node and the endpoint have the same internal LAN address and, if NAT is involved, all sorts of complications can arise.

SSL VPN

Secure Socket Layer, also referred to as SSL, uses a cryptographic system that uses two keys to encrypt data, the public and private key. The public key is known to everyone and the private only to the recipient. Through this SSL a secure connection between a client and a server is created. SSL VPN allows users to establish secure remote-access from virtually any internet connected web browser, unlike with VPN. The hurdle of unstable connectivity is removed. With SSL VPN an entire session is secured, whereas with only SSL this is not accomplished.

SSTP

Secure socket tunneling protocol, also referred to as SSTP, is by definition an application-layer protocol. It is designed to employ a synchronous communication in a back and forth motion between two programs. It allows many application endpoints over one network connection, between peer nodes, thereby enabling efficient usage of the communication resources that are available to that network.

SSTP protocol is based on SSL instead of PPTP or IPSec and uses TCP Port 443 for relaying SSTP traffic. Although it is closely related to SSL, a direct comparison can not be made between SSL and SSTP as SSTP is only a tunneling protocol unlike SSL. Many reasons exist for choosing SSL and not IPSec as the basis for SSTP. IPSec is directed at supporting site- to-site VPN connectivity and thus SSL was a better base for SSTP development, as it supports roaming. Other reasons for not basing it on IPSec are:

It does not force strong authentication,
User clients are a must have,
Differences exist in the quality and coding of user clients from vendor to vendor,
Non-IP protocols are not supported by default,
Because IPSec was developed for site to site secure connections, it is likely to present problems for remote users attempting to connect from a location with a limited number of IP addresses.

SSL VPN proved to be a more compatible basis for the development of SSTP

SSL VPN addresses these issues and more. Unlike basic SSL, SSL VPN secures an entire session. No static IPs are required, and a client is unnecessary in most cases. Since connections are made via a browser over the Internet, the default connection protocol is TCP/IP. Clients connecting via SSL VPN can be presented with a desktop for accessing network resources. Transparent to the user, traffic from their laptop can be restricted to specific resources based on business defined criteria.

SSTP - an extension of VPN

The development of SSTP was brought about by the lack of capability of VPN. The main shortcoming of VPN is its unstable connectivity. This is a consequence of its insufficient coverage areas. SSTP increases the coverage area of VPN connection ubiquitously, rendering this problem no more. SSTP establishes a connection over secure HTTPS; this allows clients to securely access networks behind NAT routers, firewalls and web proxies, without the concern for typical port blocking issues.

SSTP is not designed for site to site VPN connections but is intended to be used for client to site VPN connections.

The success of SSTP can be found in the following features:

SSTP uses HTTPS to establish a secure connection
The SSTP (VPN) tunnel will function over Secure-HTTP. The problems with VPN connections based on the Point-to-Point Tunneling Protocol (PPTP) or Layer 2 Tunneling Protocol (L2TP) will be eliminated. Web proxies, firewalls and Network Address Translation (NAT) routers located on the path between clients and servers will no longer block VPN connections.
Typical port blocking is decreased
Blocking issues involving connections in relation to PPTP GRE port blocking or L2TP ESP port blocking via a firewall or NAT router preventing the client from reaching the server will no longer be a problem as ubiquitous connectivity is achieved. Clients will be able to connect from anywhere on the internet.
SSTP will be built into Longhorn server
SSTP Client will be built into Windows Vista SP1
SSTP won't require retraining issues as the end-user VPN controls remain unchanged. The SSTP based VPN tunnel plugs directly into current interfaces for Microsoft VPN client and server software.
Full support for IPv6. SSTP VPN tunnel can be established across IPv6 internet.
It uses integrated network access protection support for client health-check.
Strong integration into MS RRAS client and server, with two factor authentication capabilities.
Increases the VPN coverage from just a few points to almost any internet connection.
SSL encapsulation for traversal over port 443.
Can be controlled and managed using application layer firewalls like ISA server.
Full network VPN solution, not just an application tunnel for one application.
Integration in NAP.
Policy integration and configuration possible to help with client health checks.
Single session created for the SSL tunnel.
Application independent.
Stronger forced authentication than IPSec
Support for non IP protocols, this is a major improvement over IPSec.
No need to buy expensive, hard to configure hardware firewalls that do not support Active directory integration and integrated two factor authentication.

How SSTP based VPN connection works in seven steps

The SSTP client needs internet connectivity. Once this internet connectivity is verified by the protocol, a TCP connection is established to the server on port 443.
SSL negotiation now takes place on top of the already established TCP connection whereby the server certificate is validated. If the certificate is valid, the connection is established, if not the connection is torn down.
The client sends an HTTPS request on top of the encrypted SSL session to the server.
The client now sends SSTP control packets within the HTTPS session. This in turn establishes the SSTP state machine on both sides for control purposes, both sides now intiate the PPP layer communication.
PP negotiation using SSTP over HTTPS now takes place at both ends. The client is now required to authenticate to the server.
The session now binds to the IP interface on both sides and an IP address assigned for routing of traffic.
Traffic can now traverse the connection being either IP traffic or otherwise.

Microsoft is confident that this protocol will help alleviate VPN connection issues, The RRAS team are now readying RRAS for SSTP integration and the protocol will be part of the solution going forward. The only prerequisite at present is that the client runs Vista and Longhorn server. The feature set provided by this little protocol is both rich and flexible and the protocol will enhance the user and administrator experience. I predict that devices will start to incorporate this protocol into the stack for secure communication and the headaches of NAT will soon be forgotten as we move into a 443/SSL incorporated solution.

Conclusion

SSTP is a great addition to the VPN toolkit to enable users to remotely and securely connect to the corporate network. Blocking of remote access and NAT issues seem to be forgotten when using this protocol and the technology is stable, well documented and working. This is a great product and it is very welcome in this time of remote access.

Green Computing - The Future

2009-09-23T16:58:00.000+05:30

What is Green Computing?

Global warming and environmental change have become big issues with governments, corporations and your average Joe alike all seeking out new ways to green up their daily activities. Computers certainly make up a large part of many people lives and traditionally are extremely damaging to the environment, which begs the question: What is Green Computing?

Green Computing is the study and practice of minimising the environmental impact of computers through efficient: manufacturing, use, and disposal.

Problems of Electronic Waste

Electronic waste is an increasing problem globally due to the quick obsolescence of electronics, which make up a staggering 70% of all hazardous waste. Computer waste is high in many toxic materials such as heavy metals and flame-retardant plastics, which easily leach into ground water and bio-accumulate. In addition, chip manufacturing uses some of the deadliest gases and chemicals known to man and requires huge amounts of resources.

In an average year 24 million computers in the United States become obsolete. Only about 14% (or 3.3 million) of these will be recycled or donated. The rest - more than 20 million computers in the U.S. -- will be dumped, incinerated, shipped as waste exports or put into temporary storage to be dealt with later. We never stop to consider what happens when our laptop dies and we toss it. The reality is that it either rots in a landfill or children in developing countries end up wrestling its components apart by hand, melting toxic bits to recover traces of valuable metals like gold.

Wasting Electricity

The manufacturing of a computer consumes 1818 kw/h of electricity before it even gets turned on and when running, a typical computer uses 120 watts. Research shows that most PC’s are left idle all day, and many of them are left on continuously. Every time we leave computers on we waste electricity without considering where that electricity comes from. The majority of the world’s electricity is generated by burning fossil fuels which emit pollutants such as sulphur, and carbon dioxide into the air. These emissions can cause respiratory disease, smog, acid rain and global climate change.

The Future of Green Computing

A Canadian company, Userful Inc. (www.userful.com) have come up with a solution that turns 1 computer into 10 - DiscoverStation. Quickly becoming the standard for green computing worldwide, DiscoverStation leverages the unused computing power of modern PC’s to create an environmentally efficient alternative to traditional desktop computing. Multiple users can work on a single computer by simply attaching up to 10 monitors, mice and keyboards. This makes it possible to reduce CO2 emissions by up to 15 tons per year per system and reduce electronic waste by up to 80%. Userful has recently stated that in the last year their software has saved over 13,250* tons of CO2 emissions, the equivalent of taking 2,300 cars off the road. (More info at: http://userful.com/greenpc)

The European Union

The European Union is tackling the problem twofold. Companies are now required to produce computers free of the worst toxic materials and are responsible for taking back their old products. Faced with disassembling parts and cycling them back into the fabrication process, companies are making more careful decisions about how those parts are assembled in the first place. In 2002 NEC came out with the first computer to use lead-free solder, a fully recyclable plastic case, and which contained no toxic flame-retardants. Since then many computer companies worldwide have started selling lead-free PCs and it is becoming common practice for companies to offer their customers free recycling of their old computers.

Go Green

Here are some suggestions that will help you reduce your computer energy

Don't use screen savers. They waste energy, not save it.
By computers & monitors labelled “energy star” which can be programmed to automatically “power-down” or “sleep” when not in use.
If you are using more than 1 PC, Userful's 10 to 1 advantage can save electricity and your wallet.
Turn your computer and peripherals off when not in use. This will not harm the equipment.
Use flat panel monitors, which use about half of the electricity of a cathode-ray tube (CRT) display.
Buy ink jet printers, not laser printers. Ink jet printers use 80 to 90 percent less energy than laser printers and print quality can be excellent.

If all of us did this every day, we could make a small difference. We only have one earth; let's treat it right.

Can Terminal Services be considered Virtualization?

2009-09-22T11:59:00.002+05:30

Virtualization is a hot topic and at the moment very hyped up. Manufacturers would like to use that hype to boost their products by linking it to the virtualization market. In this craze Terminal Services was also labeled as a “Virtualization product”. In this article let’s look at the facts and I’ll also give my opinion about this virtualization label.

Introduction

Although virtualization techniques were mentioned a long time ago (around 1960), within the ICT market the launch of VMWare caused the big success of the virtualization market. Their server virtualization product, which made it possible to run multiple servers on one physical system, started the virtualization space. After server virtualization other virtualization products and fields followed quickly like application virtualization, operating system virtualization and desktop virtualization. Products which were already available before the virtualization market want to hitch a ride on the virtualization craze. I was a bit surprised when both Microsoft and Citrix determined that Terminal Services and Citrix Presentation Server are virtualization products.

What is…?

Before we can start determining whether Terminal Services can be labeled as a virtualization product, we need to first find out what the definitions of virtualization and terminal services are.

Virtualization: Virtualization is a broad term that refers to the abstraction of computer resources. Virtualization hides the physical characteristics of computing resources from their users, be they applications, or end users. This includes making a single physical resource (such as a server, an operating system, an application, or storage device) appear to function as multiple virtual resources; it can also include making multiple physical resources (such as storage devices or servers) appear as a single virtual resource.

Terminal Services: Terminal Services is one of the components of Microsoft Windows (both server and client versions) that allows a user to access applications and data on a remote computer over any type of network, although normally best used when dealing with either a Wide Area Network (WAN) or Local Area Network (LAN), as ease and compatibility with other types of networks may differ. Terminal Services is Microsoft's implementation of thin-client terminal server computing, where Windows applications, or even the entire desktop of the computer running terminal services, are made accessible to a remote client machine.

Terminal Services Virtualization?

Both Microsoft and Citrix are using the virtualization space to position their Terminal Services/Citrix Presentation Server/XenApp product features. Microsoft calls it presentation virtualization, while Citrix used the term session virtualization. Microsoft also describes Terminal Service virtualization as follows:

Microsoft Terminal Services virtualizes the presentation of entire desktops or specific applications, enabling your customers to consolidate applications and data in the data center while providing broad access to local and remote users. It lets an ordinary Windows desktop application run on a shared server machine yet present its user interface on a remote system, such as a desktop computer or thin client.

If we go a bit deeper, Microsoft is describing their interpretation of presentation virtualization as follows: Presentation virtualization isolates processing from the graphics and I/O, making it possible to run an application in one location but have it controlled in another. It creates virtual sessions, in which the executing applications project their user interfaces remotely. Each session might run only a single application, or it might present its user with a complete desktop offering multiple applications. In either case, several virtual sessions can use the same installed copy of an application.

Ok, now we have the definitions of virtualization, terminal services and the way Microsoft explains why terminal services are a virtualization technique, it is time to determine if Microsoft is right with their assumption.

Terminal Services is virtualization!

Reading the explanation of virtualization, two important definitions are mentioned: abstraction and hiding the physical characteristics.

From the user perspective the application is not available on his workstation/thin client, but is running somewhere else. Using the definition of hiding physical characteristics, Terminal Services can be seen, from a user perspective, as virtualization. Because the application is not installed locally the user does not have any physical identification with the application.

With the IT perspective in mind Terminal Service can also be seen as virtualization based on the definition that (physical) resources can function as multiple virtual resources. Traditionally, installed applications on a local workstation can be started by one user at a time. By installing the application on a Terminal Server (in combination with a third party SBC add-on) applications can be used by more users at the same time. Although an application cannot be seen as a 100% physical resource, you can see Terminal Services as a way of offering a single resource that will be shown as multiple virtual resources.

In summary, Terminal Services can be seen as virtualization because the application is abstracted from the local workstation and the application appears to function as multiple virtual resources.

Terminal Services is not virtualization!

However, let’s take a closer look at the physical resources. Hardware virtualization, application virtualization and OS virtualization really do separate from the physical resource. With application virtualization the application is not physically available on the system, OS virtualization does not need a hard disk to operate, and with hardware virtualization the virtual machine does not communicate (directly) with real hardware. However Terminal Services, from an IT perspective, still needs physical resources. Terminal Services is not really virtualizing anything, only the location where the application/session is started and the methodology of displaying the application to the user are different. In other words, as Microsoft describes in their explanation, Terminal Services isolates processing from the graphics and I/O, but this is still done using another device without an additional layer in between.

Conclusion

Back to the main question: is Terminal Services virtualization? And the answer is …… it depends. It depends how you look at the concept of virtualization and your point of view on Terminal Services. Terminal Service can be seen as virtualization if you check it from the user perspective view (the application is not running physically on the workstation or thin client) or the view that a single application/session can be used at once by more than one user. If you look at how other virtualization techniques work, Terminal Services does not function the same way and physically nothing is running in a separate layer.

So there is no clear answer and the answer is subjective depending on how you look at virtualization and Terminal Services. My personal opinion is that Terminal Services cannot be labeled as virtualization, because it is not comparable with other virtualization techniques. Through my eyes Terminal Services is not adding an additional (virtualization) layer, but is only dividing the processes between two systems. I think both Microsoft and Citrix are using the “virtualization” term to gain advantages through the current boom of the virtualization market, but both know that if you look at the IT techniques it is not “real” virtualization.

Can Terminal Services be considered Virtualization?

2009-09-22T11:59:00.000+05:30

Introduction

What is…?

Before we can start determining whether Terminal Services can be labeled as a virtualization product, we need to first find out what the definitions of virtualization and terminal services are.

Terminal Services Virtualization?

Terminal Services is virtualization!

Reading the explanation of virtualization, two important definitions are mentioned: abstraction and hiding the physical characteristics.

In summary, Terminal Services can be seen as virtualization because the application is abstracted from the local workstation and the application appears to function as multiple virtual resources.

Terminal Services is not virtualization!

Conclusion

High Availability and Disaster Recovery for Virtual Environments

2009-09-22T11:57:00.000+05:30

Introduction

Virtual servers are used to reduce operational costs and to improve system efficiency. The growth in virtual servers has created challenges for IT departments regarding high availability and data protection. It is not enough to protect physical servers but also virtual servers as they contain business critical data and information. Virtual servers offer the flexibility, but at the same time if a single physical server containing multiple virtual servers fails, then the impact of data loss is enormous.

Virtualization Benefits

Companies are adopting virtualization at a rapid speed because of the tremendous benefit it offers and some of them include:

Server Consolidation: Virtualization helps to consolidate multiple servers into one single physical server thus offering improved operational performance.
Reduced Hardware Costs: As the number of physical servers goes down, the cost of servers and associated costs like IT infrastructure, space, etc. will also decrease.
Improved Application Security: By having a separate application in each virtual machine, any vulnerability is segregated and it does not affect other applications.
Reduced Maintenance: Since virtual servers can easily be relocated and migrated, maintenance of hardware and software can be done with minimal downtime.
Enhanced Scalability – The ease with which virtual servers can be deployed will result in improved scalability of IT implementation.

File or Block Level Replication

Different kinds of replication techniques can be used to replicate data between two servers both locally and remotely. In block level, replication is performed by the storage controllers or by mirroring the software. In file-system level (replication of file system changes), the host software performs the replication. In both block and file level replication, it does not matter what type of applications are getting replicated. They are basically application agnostic, but some vendors do offer solutions with some kind of application specificity. But these solutions cannot provide the automation, granularity and other advantages that come with application-specific solution. Also, one needs to be concerned about the following:

Replicated server is always in a passive mode - cannot be accessed for reporting/monitoring purposes.
Possibility of virus/corruption getting propagated from production server to replicated server.

Application Specific Replication Approach

In this approach, the replication is done at a mailbox or database level and it is very application specific. One can pick and choose the mailboxes or databases that need to be replicated. In the case of Exchange Server, one can set up a granular plan for key executives, sales and IT people, in which the replication occurs more frequently to achieve the required Recovery Point Objective (RPO) and Recovery Time Objective (RTO). For everyone else in the company, another plan can be set up where the replication intervals are not that frequent.

Another advantage of this approach is that the replicated or failover server is in an Active mode. The failover server can be accessed for reporting and monitoring purposes. With other replication approaches, the failover server is in a Passive mode and cannot be used for maintenance, monitoring or reporting purposes.

Backup and Replication

Some solutions offer both backup and replication as part of a single solution. In this case, the backup is integrated with replication and the users get a two-in-one solution. Considered two-tier architecture, these solutions consists of an application and agent environment. The application server also hosts the network share that stores all the backup files. The files are stored on this network share and not on any particular target server so as to prevent loss of backup files. If the target server goes down, users would like to continue to access their backup files in order to rebuild the target server with as little downtime as possible.

The mailboxes and databases will be backed to the backup server and then replicated to the remote failover server. The full back and restore is done first and then only the changes will be applied through incremental. For restoring emails, mailboxes and databases, the local backup data can be used and for disaster recovery purposes, the remote failover server can be utilized.

Virtual Environments

Many high availability solutions protect data that reside on virtual servers. Customers can have multiple physical servers at the primary location and at the offsite disaster recovery location they can have one physical server with multiple virtual servers. Also, multiple virtual servers from the primary site can be easily backed up and replicated to the disaster recovery site.

With some disaster recovery solutions, both on physical and virtual servers, the appropriate agents are installed and these agents have very small footprint. Because of the limited footprint, the impact on these servers is minimal from a performance perspective. With other replication solutions, one has to install the entire application on the virtual servers and this will take a huge toll on performance.

Physical to Virtual Servers

In this scenario, the production environment has physical servers and the disaster recovery site is deployed in a virtual environment. Both the physical and virtual servers are controlled by the Application and it can be located either at the production site or at the remote site.

Figure 1

Virtual to Virtual Environments

In order to achieve significant cost savings, some companies not only virtualize their disaster recovery site but also use virtual servers in the production environment. One can have one or more physical servers housing many virtual servers both at production and remote sites.

Figure 2

Failover/Failback

When a disaster strikes the primary site, then all the users will be failed over to the remote site. Once the primary is rebuilt, one can go through the failback process to the original primary servers very easily. Also, only a particular virtual server containing Exchange or SQL server can be failed over without affecting other physical or virtual servers.

The only way to make sure that your disaster recovery solution works is to test it periodically. Unfortunately, to do that one has to failover the entire Exchange or SQL server. Administrators will be leery about doing this for fear of crashing the production Exchange or SQL server. Some solutions can create a test mailbox or database and use it for failover/failback testing periodically. Through this approach, customers can be fully assured that their disaster recovery solution will work when it is badly needed and have peace of mind.

Migration

Virtual servers in conjunction with certain disaster recovery solutions can be used as a migration tool. If a physical server goes bad, then one can failover to the remote failover virtual server. Once the primary site is rebuilt, then the failback can be easily achieved. With some applications, there is no need to have identical versions of Exchange on primary and failover servers. In fact, one can run Exchange 2003 on primary server and Exchange 2007 on failover server. This feature can be used as a migration tool. For example, you can failover to the failover server which runs Exchange 2007. Upgrade the original primary to Exchange 2007 and failback again. This scenario is applicable to SQL 2000, SQL 2005 and SQL 2008 servers also.

Conclusion

Companies are increasingly adopting virtual servers as virtualization offers many compelling benefits. This increase in virtualization poses tremendous disaster recovery and data protection challenges to IT Administrators. There is a greater need to implement the appropriate high availability and failover solutions to protect these servers.

Determining Guest OS Placement - Part 2

2009-09-22T11:47:00.001+05:30

In the previous article in this series, I began discussing some of the various techniques used for matching virtual servers to physical hardware. Although the first article in this series does a fairly good job of covering the basics, there are still a couple of other issues that you may have to consider. In this article, I want to conclude the series by giving you a couple more things to think about.

Step Three: Establish Performance Thresholds

The first thing that I want to give you to think about is individual virtual machine performance. I have already talked about resource allocation in the previous article, but in a way performance is a completely separate issue.

One of the main reasons for this is that in a virtualized environment, all of the guest operating systems share a common set of physical resources. In some cases it is possible to reserve specific resources for a particular virtual machine. For example, you can structure memory configuration in a way that guarantees that each virtual machine will receive a specific amount of physical memory. Likewise, you can use processor affinity settings to control the number of cores that each virtual machine has access to. While these are all good steps to take, they do not actually guarantee that a guest operating system will perform in the way that you might expect.

The reason for this is that sometimes there is an overlapping need for shared resources. In some cases, this can actually work in your favor, but, in other cases overlapping resource requirements can be detrimental to a guest operating system’s performance.

The reason why I say this is that Microsoft usually recommends a one-to-one mapping of virtual processors to processor cores. Having said that though, it’s possible to map multiple virtual processors to a single processor core. With that in mind, imagine what would happen if you tried to run six virtual machines on four physical CPU cores.

What would happen in this situation really just depends on how those virtual machines are being used, and how much CPU time they consume. For instance, if each virtual machine was only using about 25% of the total processing capacity of a physical core then performance would probably not even be an issue (at least not for my CPU standpoint).

The problem is that most of the time the load that a virtual machine places on a CPU does not remain constant. If you have ever done any performance monitoring on a non-virtualized Windows server, then you know that even when a machine is running at idle, there are fluctuations in CPU utilization. Occasionally the CPU will spike to 100% utilization, but it also occasionally dips to 0% utilization.

And you will recall, earlier I said that sometimes shared resources can be beneficial to a virtual server, but sometimes they can be detrimental to it. The reason why I say this is that in situations in which the other virtual machines are underutilizing shared resources, a virtual machine may be able to borrow some of those resources from the other virtual machines to help it to perform better. Of course this capability varies depending upon how the virtual servers are configured, and which resources are needed. At the same time, if multiple virtual machines try to consume an abnormally large amount of resources at the same time, it can result in a situation in which the physical hardware cannot keep up with the demand and performance suffers until the demand for resources goes back to normal.

With this example in mind, the question that you have to ask yourself is whether or not it is acceptable for multiple virtual machines to lay claim to the same set of physical resources at the same time. Of course the only way that you can answer this question is to do some performance benchmarking and find out what level of resource consumption is normal for each virtual machine.

Step Four: Perform a Juggling Act

The final step in the process is to perform a juggling act. In some ways, this is not so much a step as it is a byproduct of working in the corporate world. The reason why I say that the last step is to perform a juggling act is that oftentimes you may find that what works best from an IT perspective does not mesh with the company's business requirements. In these types of situations, you will have to find a balance between functionality and corporate mandates. Often this boils down to security concerns.

For example, one of the biggest security fears in regard to virtualization is something called an escape attack. The basic idea behind an escape attack is that an attacker is able to somehow escape from the constraints of the guest operating system, and then gain access to the host operating system. Once an attacker is able to do that, they could theoretically take control over every other guest operating system that is running on the host server.

To the best of my knowledge, nobody has ever successfully performed an escape attack in a Hyper-V environment. Even so, many organizations are still jumpy when it comes to the possibility. After all, zero day exploits do occur from time to time, and Hyper-V has not really been around long enough to warrant total confidence in its security.

Do not get me wrong. I am not saying that Hyper-V is insecure. I am just saying that like any other new product, there may be security holes that have yet to be discovered.

Given the possibility that someone might eventually figure out how to perform an escape attack against Hyper-V, some organizations have begun to mandate that only virtual machines that are specifically designed to act as front end servers can be placed on certain virtual machines. Front end servers typically reside at the network perimeter, and are therefore the most prone to attack. By their very nature, front end servers are designed to shield the backend servers from attack.

Grouping all of the front end servers together on a common host machine ensures that if someone ever does perform an escape attack, they would not gain access to anything other than a bunch of front end servers. Since front end servers do not typically contain any data, this approach would help to protect backend servers from being compromised through an escape attack.

So what is wrong with this approach? Nothing, from a security standpoint. From a utilization standpoint though, this approach may present a colossal waste of server resources. In smaller organizations, front end servers tend to consume very few hardware resources. If your goal was to get the most bang for your hardware buck, you would want to pair low utilization virtual servers with high utilization virtual servers. That way, the two balance each other out, and you can evenly distribute the virtual machine workload across your hardware. In this particular case, the organization’s security requirements take precedence over making the most effective use of the organization’s hardware.

Conclusion

In this article series, I have explained that while a single physical server is usually capable of hosting multiple virtual servers, it is important to group virtual servers together in a way that makes the most efficient use of hardware resources without over taxing the hardware in the process. I then went on to explain that sometimes an organization’s business needs or their security policy may prevent you from making the absolute best possible use of your server hardware.

Determining Guest OS Placement - Part 1

2009-09-22T11:35:00.002+05:30

As you consolidate physical servers in your organization, one of the decisions that you are going to have to make is where to place each virtual server. Deciding which physical server should host which virtual servers is something of an art form. In this article, I will discuss some criteria that you can use to assist you in virtual server placement.

Step one: Determine Each Host’s Capabilities

The first thing that I would recommend doing is taking an inventory of your host servers, so that you can figure out each host’s capabilities. Some important criteria to include in your inventory are the number of CPU cores included in the server, the amount of memory installed in the server, and the speed and capacity of the disk subsystem.

The reason why this is important is because each hosts server only has a limited amount of resources that can be shared between the virtual machines that are residing on it. Knowing what each physical server is actually capable of is the only proof positive way of mapping the virtual server’s needs to the physical server’s resources in an effective manner.

One aspect of the inventory process I have yet to hear anyone mention is that I would recommend taking the time to not only document what hardware is currently present on the server, but also what upgrades could be performed on the server if it were to become necessary. I believe that this is important because one of the main reasons why companies choose to virtualize their servers is so that they can make better use of their hardware, and use fewer physical servers.

With that in mind, imagine what would happen if a company were to install some virtual servers onto a physical server whose hardware capabilities have not been maxed out. If the company eventually needed to create more virtual servers, they may end up investing in an additional physical server to host the new virtual machine, because they believe that their existing hardware is already performing at its maximum potential. In most cases though, it would have been a whole lot less expensive for the company to simply upgrade their existing hardware than to purchase an additional server. Even if the hardware costs of doing so were the same, there are software licensing costs that must be considered.

Step two: Determine Each Virtual Server’s Needs

The next step involved in the virtual server placement process is to determine each virtual machines resource requirements. Generally speaking, I recommend treating a virtual machine in the same way that you would treat a physical machine. Suppose for instance that you were going to be deploying an application server, and application’s publisher stated that they recommend a dual core processor, 2 GB of RAM, and 100 gigs of hard disk space. The application publisher probably assumes that the application is going to be run on a physical server. Even so, it has been my experience that the various hardware requirements apply equally even if the application is going to be run in a virtual machine.

In my example above, I am not saying that as long as the host server has a dual core processor, 2 GB of RAM, and 100 GB of hard disk space that you will be able to run the application in a virtual machine. What I am saying is that if you can allocate those particular resources to a virtual machine in a way that prevents those resources from being consumed by other virtual machines running on the host server, then the application will probably run fine.

Of course there are exceptions to every rule. One thing that you need to be aware of is that when application publisher's site hardware requirement, they do not take resource contention into account. Any time that you are hosting multiple virtual machines, all of those virtual machines compete with each other, and with the host operating system for a limited pool of server resources.

You can partially solve the resource contention problem by dedicating certain resources to the individual virtual machine. For example, memory is one resource that can be allocated in such a way as to prevent it from being used by other virtual machines hosted on the server.

CPU resources can also be allocated, but only to a degree. You can assign processor affinity settings for virtual machines. In essence, this means configuring virtual machines so that they are only allowed to use specific CPU cores. Doing so will not prevent the host operating system from using those cores, but it will prevent a CPU intensive virtual server from running away with all of the physical servers CPU resources. You can also treat the machine’s entire bank of CPU resources as a pool, and set some threshold values that limit the overall amount of CPU resources that a virtual server is allowed to use.

If you do decide to use processor affinity as a way of managing CPU resources for virtual machines, then you must make sure to leave at least one or two CPU cores unallocated. Doing so gives the host operating system some CPU resources that they can use without depriving the virtual servers of CPU resources. That is not to say that the host operating system will not use some of the CPU cores that you dedicated to the guest operating systems, but it does make it less likely. Generally speaking, if the host operating system is running Hyper-V and nothing else, then its CPU consumption will be minimal. Obviously some CPU resources are required for running the host copy of Windows, and there is a degree of CPU resources required for supporting Hyper-V's overhead, I have never run into problems so long as I leave some CPU resources dedicated to the host operating system.

One of the trickier types of resources to allocate our disk resources. Most common practice for allocating disk resources is typically to create separate volumes for each virtual machine, and to then place the virtual hard drives onto the volume that you have set aside for that particular virtual machine. Sometimes a server will have disk requirements that require a more elaborate disk allocation method. For example, an Exchange mailbox server requires multiple virtual hard drives, and those virtual hard drives need to be positioned in a way that ensures performance and fault tolerance. For the purposes of this article let's assume that each virtual server only needs one virtual hard drive, and that each of those virtual hard drives is located on a separate volume.

Even with this type of configuration, resource contention is still an issue. The reason is that although Hyper-V is able to communicate directly with the hardware for most types of hardware calls, any calls to the disk subsystem must pass through the host operating system. This means that it is easy for the server to get bogged down if you're running a lot of disk intensive virtual servers on the same physical hardware, even if you are using separate volumes for each virtual hard drive (although that does help).

Conclusion

In this article, I have talked about some ways of determining what a physical server's capable of, and some ways of allocating specific resources to virtual servers. In the next part of this article series, I will conclude the discussion by talking about some ways of mapping hardware resources to virtual server requirements, and about what to do when business requirements and virtual server mappings do not seem to match up.

Offline P2V Migrations using SCVMM 2008

2009-09-22T11:23:00.002+05:30

Introduction

SCVMM 2008 supports online migrations for Windows operating systems that have Volume Shadow Copy Service (VSS) support and requires offline migrations for Windows operating systems that do not have VSS support. The following article provides the prerequisites, procedures and considerations for offline P2V migrations. In addition I will provide recommendations for when you should consider using offline P2V migrations even if the Windows operating system supports online migrations.

P2V migrations are all performed using a wizard in SCVMM 2008. The same wizard is used for online and offline migrations. All that is required to install is the Virtual Machine Management server and a library server. Both are installed on the SCVMM server by default.

The offline P2V migration wizard gathers the required information, makes decisions based on that information, and finally creates the job that will be executed to perform the migration. The migration wizard for an offline P2V migration involves the following steps:

Launching the Wizard
Specifying the source physical server
Naming the virtual machine
Gathering system information from the source physical server
Modifying the volume configuration
Modifying the IP address used for migration
Modifying the processor and memory configuration of the migrated virtual machine
Selecting the Hyper-V host for placement
Selecting the path to place the virtual machine files on the target Hyper-V host
Selecting the virtual network mapping for each network adapter
Selecting additional properties like startup and shutdown actions
Resolving any potential conversion issues
Launching the migration process

Offline P2V Prerequisites

Before you attempt a P2V migration, there are a host of prerequisites that need to be validated. During the information gathering phase of a P2V migration, SCVMM will need to deploy a P2V agent (VMMP2VAGENT.EXE) to the source server to gather information. The source server is required to have a minimum of Windows Installer 3.1 installed for the agent to install successfully. Before you attempt a P2V migration, you should download Windows Installer from Microsoft Downloads. Search for KB893803.

During an offline P2V migration the source server is powered down and booted from a WinPE image so that the source server’s disks can be accessed without any locks on the files. The WinPE image will need access to the disk drives and the network interfaces to read the data from the source servers’ disk drives and transfer that data across the network to the host where the target virtual machine resides. During the information gathering phase, the P2V agent will identify any additional drivers or updates that are required and will be presented those requirements to you via the wizard. You will need to copy these files into the SCVMM folder structure following these steps:

Download the required update packages or drivers indicated from the Microsoft Web site. The update packages will need to be renamed to an 8.3 naming format and possibly will need to be extracted. It may also be necessary to extract the drivers to get the raw driver files.
Copy the renamed update packages into the folder C:\Program Files\Microsoft System Center Virtual Machine Manager 2008\P2V Patch Import.
Copy the raw driver files into the folder C:\Program Files\Microsoft System Center Virtual Machine Manager 2008\Driver Import

Make sure to use drivers designed for Vista or later operating systems, because the version of WinPE used in SCVMM 2008 is based on Windows Vista.

Offline P2V Considerations

For some servers you should use offline P2V migration to make sure that transactional data is properly saved to disk to avoid corruption. Active Directory domain controllers are prime example. An online migration of a domain controller could potentially cause a USN rollback situation as described in Appendix A of the white paper “Running Domain Controllers in Hyper-V”.

You should perform P2V conversion of a domain controller in offline mode so that the directory data is consistent when the domain controller is turned back on. At no time during the P2V migration should the physical DC and the new virtual DC be running and connected to the production corporate network. Once the P2V migration is complete, the virtual machine should be powered on while connected to an isolated network so you can verify that the P2V migration process is complete. Once the migration is verified, the physical DC should never be turned back on.

Offline P2V Migration Performance

The speed of the migration process is affected by network, processor and disk I/O capabilities of the source server and target host. To minimize the time of a P2V migration you should consider doing the following:

Dedicate a Hyper-V host for P2V migrations
Place the Hyper-V host as close to the source server as possible
Do not perform migrations over slow WAN links
Place the source server and the target Hyper-V host on gigabit Ethernet networks

Step-By-Step Offline Migration of a Windows 2000 Server

Windows 2000 Server is the only supported Windows operating system that requires a P2V migration. This is required because Windows 2000 Server does not have VSS support. To demonstrate an offline P2V migration, we will migrate a Windows 2000 Server called PHYSICAL1 to a virtual machine called VIRTUAL1. These procedures assume that you already have SCVMM 2008 installed with managed Hyper-V hosts that have the capacity to support the PHYSCIAL1 being migrated.

Use the following procedures to perform a physical to virtual migration:

In the SCVMM console Actions menu, click Convert Physical Server.
On the Select Source page, enter PHYSICAL1 as the name of the physical computer that you would like to convert, enter the credentials that have local administrative rights on the server, and then click Next.

Figure 1

On the Virtual Machine Identity page, enter VIRTUAL1 for the virtual machine name, modify the virtual machine owner, enter a description if desired, and then click Next.
On the System Information page, click the Scan System button to scan PHYSICAL1. SCVMM will use the credentials you provided in step 2 and remotely connect to the server, transfer the P2V agent, install the agent, and then scan the server. When the scan is complete, the system information box at the bottom will display the operating system, the processor count, the hard drive information, and the network adapters. When you are done reviewing the system information, click Next.

Figure 2

On the Volume Configuration page you can modify the original source server configuration and define the disk controller that the new virtual machine should be connected when migrated. Make modifications to the hard drive type, size, and controller to which the volume should be connected and click Next.

Figure 3

On the Offline Conversion Options page, select the method that the WinPE image should use to obtain an IP address (DHCP or static IPv4 or IPv6 address). If you select a static IP address you will need to provide the IP address information. Once the required information is provided, click Next.

Figure 4

On the Virtual Machine Configuration page, you will see that it is possible to modify the number of processors and the amount of memory to assign to the new virtual machine. For a Windows 2000 server, only a single processor configuration is supported. Make any required modifications to the memory, and then click Next.
Figure 5
On the Select Host page, the available hosts are ranked based on performance and available capacity for this virtual machine. The hosts are ranked using a star ranking with the recommended host at the top of the list. Select the Hyper-V host that you want to place the new virtual machine and then click Next

Figure 6

On the Select Path page, modify the path to store the new virtual machine in the desired location on the Hyper-V server and then click Next.
On the Select Networks page, select the virtual network connection binding that you want for the virtual machine. In the case of a DC migration select the virtual machine to be in the Not Connected state to prevent unwanted network communications until you have verified everything is working correctly. Click Next.

Figure 7

On the Additional Properties page, select the Automatic Stop and Start actions you prefer and then click Next.

Figure 8

On the Conversion Information page, review any open issues for PHYSICAL1, and then when you have completed your review and resolved these issues, click Next.
On the Summary page, review the conversion settings and click Create to start the physical to virtual migration process.

Figure 9

During the conversion process, the Jobs window is displayed. You can use it to track the progress of the conversion.

Conclusion

System Center Virtual Machine Manager 2008 is Microsoft’s solution for providing online and offline physical to virtual migrations and placement on Virtual Server 2005 R2 and Hyper-V. SCVMM support for offline migration is primarily focused on Windows 2000 Server migrations, but should also be used for situations where the online VSS approach would result in possible corruption of data. This article provided information about SCVMM offline migration options and the required prerequisites for a successful migration. The wizard based step-by-step approach makes a P2V migration a simple and quick process.

OS Virtualization in Practice - Part 2

2009-09-22T11:15:00.001+05:30

Introduction

In the previous article we started using operating system virtualization by installing the Citrix Provisioning Server, configuring the basic settings for the Provisioning Server and building the master client to create the image on the created virtual disk. In the previous article we concluded with the installation of the device client of the Provisioning Server. We will continue now by adding this client into the provisioning server database and creating an image of the system on vDisk.

Creating the image

As described in the previous article we need to add the client to the Provisioning Server infrastructure. This is done at the device collection level by choosing Create Device. The devices are recognized by their MAC address, which means you will need to find out the address of the client first. You will need to specify the name of the client before you start (for the master image this is just for administrative purposes). When the device is created, some configuration settings need to be performed via the properties option. In the least, the boot from the options menu needs to be set:

General - Boot From: Need to be set to; Hard Disk, so the server will boot from it.
vDisks – vDisks for device: The vDisk should be selected on the image it should be written on. Remember that this vDisk needs to be configured in private mode, so changes can be written to the virtual disk.

Figure 1: Adding the client to the Provisioning Server infrastructure

When the system is added the system can be restarted. The system needs to be started using PXE to setup a connection with the provisioning server infrastructure. When the system has connected to the Provisioning Server the system will start the operating system from the hard disk.

When the system is loaded the virtual disk is connected to the system. To create the image the disk needs to be added as a hard disk by assigning a driver letter to the disk and formatting the disk using Disk Management (can also be arranged on the Provisioning Server). When the disk is available as a normal Windows drive the Provision Server Image Builder utility can be started. Within this utility it is advisable to use the optimize button to disable unnecessary services and programs. After that browse to correct destination drive and push the Build button. The operating system will be imaged to the virtual disk. Remember that the technique is similar to other image methodologies, so arrange that there are no unique characteristics in the operating system or applications (see for example my article about running Citrix Presentation Server/XenApp with Citrix Provisioning Server).

Figure 2: Device Image Builder in action

When the image is created the system needs to be closed down. The virtual disk is then available again in the console for changing properties. I assume that most people will use Provisioning Server for the option to use one virtual disk for more clients. Therefore we change the access mode of the vDisk to Standard Image and choose one of the cache types (I prefer caching on the device on HD or RAM). After this change it is possible to roll out new clients using operating system streaming.

Figure 3: Changing the vDisk to a standard image

Adding a new client

We have configured a virtual disk with an operating system image, so now we can add a client to use this virtual disk to start operating system streaming. Again we need to add this client into the console by using the MAC address of the client. To this client the vDisk needs to be assigned and the boot from option needs to be configured with the option vDisk. This arranges that the connected vDisk will be used to boot up (in other words operating system streaming). Normally, a client will be part of a domain. At this moment the power of Provisioning Server will be shown. By right clicking the client and choosing the option Active Directory – Create Machine Account. You can choose within the wizard the Organization Unit in which the computer account needs to be created.

Figure 4: Create an Active Directory account for the Citrix Provisioning Server client

When the account is created there is one thing that should be arranged. Just like user accounts also a computer account has a kind of password, which is changed on a regularly basis. Because this is synchronized between Active Directory and the Operating System on the client this will cause using Citrix Provisioning Server that this password is out of sync and the client cannot connect to the domain anymore. Therefore on the Organizational Unit the clients are located, a group policy object setting needs to be defined. In the Computer Configuration – Security Settings- Local Policies – Security Options the setting Domain Member: Disable machine account password changes needs to be enabled. Enabling this setting can be seen as a security risk and therefore Citrix Provisioning Server can arrange that this password will be changed periodically by enabling this option within the console.

Figure 5: Disable the machine account password changes

If the policy is defined, the client is added to Active Directory (in the correct Organizational Unit) and the vDisk is assigned, everything is available to start the new client using the PXE servers and starts the operating system via streaming with Provisioning Server. When the logon window is displayed, you will see that Citrix Provisioning Server has arranged that the computer name is changed to the name specified in the console and that it is possible to logon to the domain. Further you won’t notice many changes except the Client icon in the system tray.

Figure 6: Logon screen of the virtualized operating system

Updating a vDisk

Till now we have created our first virtualized operating system and a client is running using that operating system. But after a while updates need to be applied to the virtualized operating system. Think of Windows Updates and hotfixes, applications updates and/or new applications. There are several methodologies, which I will explain briefly in this paragraph.

Creating a complete new vDisk: This first option is the most labor-intensive one, but also the most simple. The starting point is just to use the same procedure as already described by creating a new vDisk, followed by installing a new system for creating the image. You could also use the earlier installed master image builder, but remember that Citrix advices to install the Provisioning Server Client as the last software component. After the image is created on the vDisk the vDisk can be assigned to the client and when rebooted they will use the new vDisk. In previous manuals this methodology was described, but Citrix now recommends to use one of the below methodologies.
Updating (a copy) of the current vDisk: I personally recommend this version, because it is quick and much easier than the incremental methodology. The first step is creating a copy of the current vDisk using Windows copy commands (remember that the file should not be in use to accomplish this part. I also create a copy of the vDisk before I put it into production, so I don’t have to disturb production activities). After importing the vDisk into the console, the mode should be changed to private mode. Boot one server with this disk in private mode and install the updates. Shutdown the server and change the mode to standard mode again, so the disk can be used for offering the updated operating system. Citrix Provisioning Server has an automatic update feature, so such a new vDisk will be automatically assigned to the client (when the client reboots).
Incremental vDisk Updates: Using this methodology you will also create a copy of the current vDisk, import the copied vDisk into the console and configure it into private mode. Boot a client with this private mode vDisk and install the updates. After shutting down this client, the disk should be configured in standard mode again. Then using the auto update utility will create a delta-file which can be applied again using the automatic update features.

Conclusion

In this second article I continued showing using operating system streaming in practice. We started the article with creating an image, followed by adding a new client. The last topic was about applying updates to the virtualized operating system. Of course it is not possible to mention all options and functionalities of a product, but I think this article series gives a good overview of such a product and have made your enthusiastic about the technology and would like to discover the product more yourselves.

OS Virtualization in Practice - Part 1

2009-09-22T11:03:00.001+05:30

Introduction

In a previous article series I explained the basics of operating system virtualization, including the techniques, advantages, disadvantages and possible scenarios. But of course you would like to see how this works in practice. In this article I will show you how to operate system virtualization using Citrix Provisioning Server version 5.

Preparation: Server Installation and Initial Configuration

The Citrix Provisioning Server exists as a server component and a component on the client which makes it possible to create the virtual disk (vDisk). This also starts a client using the operating system streaming technique. The installation of the client component will be described later on this article; we will focus first on the installation of the server component.

The installation has some requirements. The configuration needs to be stored on a Microsoft SQL database. This can be a dedicated Microsoft SQL server or, for smaller/test environments, an SQL Express version. In a production environment, a dedicated SQL server is advisable because, ideally, you would want to install at least two Citrix Provisioning Servers for fault tolerance and you would also like to have access to the database even if one server is unavailable.

Note:
You need to have ample disk space available for storing the virtual disks.

When using more Provisioning Servers, the disk space should be claimed on a file share, SAN or NAS. With a single server, this can also be located on the local storage. A Citrix License Server is also required (the same as for using XenApp or other Citrix products).

The server component also requires .Net Framework 3.0, which will be automatically installed during the installation, if not available already. The installation of the server component is started using the PVSRV_Server.exe. The installation is pretty straight forwarded. First, the license agreement needs to be accepted, followed by specifying some customer information and the location where the application needs to be installed. The most important part of the installation is the question about the components which you would like to install. Like most products, it offers to install all components or just a selection of those. Which components you will need depends on which roles are already available in your infrastructure and which you would like to use for this product. Remember that only one PXE role can be available per IP subnet.

Figure 1: Selecting the components which will be installed

After this question the installation will actually start. When the installation is complete, the intial configuration will automatically start. During this intial configuration you can specify which supporting services you will use, like DHCP and PXE services, where they are located and if you would like to create an new farm (creating an new Provisioning Server environment) or to join an existing farm (adding a Provisioning Server to current infrastructur). Also, the location of the virtual disk store, the network interface cards for the streaming protocol (including ports), enabling/disabling the TFTP service and the bootstrap configuration are a part of this intial configuration. This configuration can also be started later on to change these settings afterwards. Do not forget to add the DHCP options for PXE booting to your DHCP role, when using the PXE role.

Figure 2: Initial Configuration

Figure 3: Initial Configuration

The server component automatically installed the Provisioning Server console, but there is also a separate installation available to install the console on the administrator workstation or server.

Basic Configuration of the Provisioning Server environment

After the installation, the console needs to be started and connected to the farm the first time by specifying the name of (one of) the Provision Server console and the communication port. After the connection is established several settings can be configured like automatic updates of virtual disk, high availability, delegation of control, tuning of the streams and much more. These topics are pretty interesting, but will go into too much detail for this article. I will keep to the most basic configuration settings, which are needed to get the system up and running. The first thing that should be created is a so called Site. A site is a collection of servers, devices and connected stores. A site is simply created by right clicking the site component in the right pane. In the next dialog a (unique) name for the site needs to be specified and additionally a description, administration security and “auto add” can be configured. After a site is configured, additionally at least one Device Collection needs to be created. In this dialog also a name, description, a template target device (the configration of this client will be used to configure the new clients) can be set. When the site configuration is finished, a store needs to be created. In this store the vDisks will be created, which will be used to host the operating system for the streaming technology.

Figure 4: Create a store for the vDisks

The store needs to have a name and needs to be connected to a site which “owns” the store. Logically, a path needs to be specified on which the virtual disks will be stored. Also the write cache location can be specified (the location where the streamed content on the client will be cached). Lastly, the server(s) need to be specified which will use the store for streaming the content.

Creating a Virtual Operating System

Now that the most basic configuration is done; the next step is to create a virtual disk, which can host the operating system (and the applications installed on the operating system). This is accomplished by right clicking on the store and choosing “create vDisk”. A dialog will pop-up in which you need to specify the following information: the site that will contain the vDisk, the server being used to create the vDisk, a (file)name for the vDisk, a description, the size of the vDisk and the VHD format.

Figure 5: Create a vDisk

In this version 5 the Microsoft VHD format is introduced, which gives the options to create a dynamic VHD format. With the dynamic format not the total specified size of the disk is reserved, but just a small file is created. When the vDisk is used to store files in it, the size will be automatically adjusted. A progress bar will be displayed during the creation and when the vDisk is created a file can be found on the specified path of the store. As you can see in the figure below the file is just about a 2 MB size.

Figure 6: The actual file of the vDisk

Now that the virtual disk is created, it is time to fix the operating system with the corresponding applications placed on the virtual disk. For this you need to install a system with the corresponding operating systems and applications using the traditional way; for example, using a CD set or an electronic software deployment. When the system is completely installed, the last step is to install the Provisioning Server Device software. This installation exists as a single executable. During the installation wizard, only very basic dialogs are presented; accepting the license agreement, supplying customer information and specifying the destination location where the files should be installed. After the installation the system needs to be restarted before you can use the client. But actually, the system needs to be configured within the Provisioning Server software before the system can be restarted. I will continue with this part in the next article, which will be published soon.

Conclusion

In this first article of this article series I showed you the first steps in using operating system streaming. We installed the Provisioning Server and the required supporting software, configured the basis setup of software, created a virtual disk and configured a system to create the image on the virtual disk. The next article will continue with actually creating the image, building a new system using the virtual disk and updating a virtual disk with updates.

Installing Microsoft Application Virtualization (Part 1)

2009-09-22T10:05:00.003+05:30

Introduction

When Microsoft acquired SoftGrid in January 2007, App-V 4.5 was the first version fully branded under the Microsoft umbrella. The most notable change that was made is, logically, the new name. After some other names like Microsoft Application Virtualization (you will find this name when researching the product) the final name became App-V (based on Microsoft hypervisor Hyper-V). You will also see the name System Centre Application Virtualization Management Server for this product.

Beside the name change, several new features introduced such as Dynamic Suite Composition and the Lightweight Streaming Server. This article will not go into the details of these new features since we are not interested in producing a step by step installation guide of App-V in this article.

The installation of the App-V architecture is composed of three components:

App-V Server
App-V Client
App-V Sequencer

Installation App-V Server

Before starting the installation of the App-V Server component you need to decide if you will be using the full App-V environment or the streaming option only. The full App-V environment is exactly the same as the previous SoftGrid version, most importantly, in terms of its database and the full management console. The management console provides you with options which include the assignment of applications to users based on group membership and software license metering. The Streaming only arranges that the sequences can be started using the client, but you should arrange via other software products or scripts authorization (by default everyone can start the applications using the streaming only feature), adding the application shortcuts to the end user and the software licensing part. It depends on several factors which option you choose in your infrastructure. In this article I will describe the installation of the full environment option.

The software installation will be started using the delivered setup.exe. For the full environment you need to start this executable out of the management installation folder. For the streaming part you should start the same named executable in the streaming folder.

Microsoft is (logically) using the MSI installer for the installation of the App-V product. The first window is the welcome message with information about the installation. Nothing interested is mentioned here so we will quickly continue with the next steps.

Figure 1

Of course there is also a license agreement that should be accepted before the installation can be carried out.

Figure 2

In the next screen the user name and organization information needed to fill in.

Figure 3

In the Setup Type Window the option appears to select the installation methodology. I select the custom option to show all the possibilities and explain what do these options mean in your infrastructure.

Figure 4

Because of the custom setup the available installations options appear. The first App Virt Management Server is the actually streaming component. This component is serving the client request to streamed applications. This component requires MS Core XML Services 6 to be installed on the server.

The second option is the Management Console of the suit. The console makes a connection with the App Virt Management Service.

This is the third option. This is a web services based component. To install this option you need Internet Information Services and .Net Framework 2.0

You can install the components on one server or on separated servers. For example the Management Service on an existing IIS server and the console on a special management server. For the article I will install all components on the same server.

Figure 5

If you did not install the required supporting software the following screen will be displayed. You need to cancel the installation and install that software first.

Figure 6

As mentioned before the full App-V environment requires a database. The installation wizard automatically searches for available MS SQL servers and you need to choose on which server you would like to host the database.

Figure 7

Next you can use an existing database (if you have more than one App-V Server, I will discuss this later) or to create a new database. By default the database will be created using the default paths defined on the SQL server, but you can change that with the option “Use the following location when creating the database”.

Figure 8

If you would like to use the secure communication option available within App-V you need to have a server certificate installed before you start the installation. That certificate can be configure or App-V in the Connection Security Window. In this article I will not use secure connections and did not install a certificate.

Figure 9

By default App-V uses port 554 to stream the applications, but you have the possibility here to change the use a different port.

Figure 10

App-V has only one type of permission within the console. There is no delegation of control possible. You can only give a group Full Control within the App-V infrastructure. In this case I will give the administrator role to the Domain Admins.

Figure 11

Secondly you also need to specify which users are allowed to access the App-V infrastructure. This part only allows setup a connection to the server, but does not specify which applications the users can use. In this case I will use the Domain Users.

Figure 12

The next step is to specify the content path. This content path is the folder in which you will store the sequences so they can be streamed to the clients. If you change the default path you need to create the directory in advance. You can always change the path later in the console.

Figure 13

The installation wizard has now collected all the necessary information and will install the App-V server locally on the disks.

Figure 14

After all the installation the last Windows will appear mentioning that the installation is completed.

Figure 15

A restart is required before the App-V server can be used.

Figure 16

After the installation there are a few settings you should configure before starting to use the server. This can be accomplished by using the App-V Management Console. As mentioned before, this console can be installed on the same server or a separate machine. The shortcut to the console can be found within the Administrative Tools folder on the machine you installed the console. The first time you start the console you need to connect to the App-V server.

Figure 17

If the console and the web service are installed on the same server you use the localhost otherwise you have to fill in the server on which the App-V web service role installed. You can use your current credential or specify your special administrator account.

After logging on you need to specify some settings to finalize the installation and optimize the App-V server configuration.

The first step is to configure the Default Content Path which can be set within System Options below the web service server (the server you connect the management console to).

Figure 18

The second location you can choose some important options about the way memory and processor is being used on the App-V server. This should be configured on a per server basis within Server Groups - <Server Group Name> (default is Default Server Group).

Max Memory allocation: The Max Memory Allocation option specifies how much memory the SoftGrid Streaming server can use for the SFT file cache to support user settings. The default value can be rather small for busy SoftGrid Streaming server systems. This value should be raised to the amount of RAM that is in the SoftGrid Streaming server minus the amount of RAM that is needed for Operating System and other components.
Warn Memory Allocation: The Warn Memory Allocation value is the threshold where the server starts logging warings to the ‘sft-server.log’ file. This value is typically around 80% of the Max Memory Allocation value.
Max Block Size: The Max Block Size depicts the size in kilobytes of the buffer in RAM to be used to cache the largest contiguous block of data from a SFT file for a user session. This value is ignored in Softgrid 4.0 and higher and above as the Max Block Size is dynamically determined based on information within the SFT file.
Number of Core Processes: The number of core processes (default is 3) specifies the number of ‘SFTCore.exe’ processes that can run simultaneously on this server. Each process can handle up to 1.5GB of memory so in general there is no need to increase this number.
Max Chunk Size: The Max Chunk Size specifies the size in kilobytes of the largest block of code in any SFT file that may be streamed from this SoftGrid Streaming Server. The default is 64KB and it is recommended to leave it like that.

Figure 19

At the default provider properties, also several settings can be set like the way of refreshing the client with the server and the authentication and logging information to your needs.

Figure 20

Now the App-V server is ready to stream applications. Remember that the default test application is configured to use secure streaming (via port 332), so if you choose to use the App-V infrastructure on the default port you should reconfigure the default test application or add your own sequenced application to the console.

Conclusion

In this first part article I described the necessary steps to install an App-V server. In the upcoming article the installation and basic configuration of the App-V Sequencer and the App-V (TS) Client will be described.

What VMware’s View 3 VDI offers and how to Install it

2009-09-22T09:47:00.002+05:30

Introduction

VMware recently announced their latest version of their enterprise VDI (virtual desktop infrastructure) solution called “View” (version 3). VMware’s View 3 is a “new and improved” version of their previous solution, which was just called “VDI” or “VDM” (virtual desktop manager). In this article, I will cover what VMware’s new View 3 offers, how it can help you, and how to install it.

Whether you have completed the virtualization of your server infrastructure, or not, desktop virtualization is a popular type of virtualization that you should consider. VMware has recently updated their enterprise desktop virtualization solution with new features and a new name – “VMware View 3”.

I have worked in an enterprise business where we tested and later implemented VMware’s VDI solution (prior to View). I can tell you that we had a number of issues which we felt still needed to be addressed. I am impressed that VMware’s new View 3 really addresses the major issues we had. Some of the major issues we encountered included; support of Terminal Services, Citrix, Thin client printing, offline desktops, and much more. Let’s find out what VMware’s View can do.

What does VMware’s new View 3 do for you?

In its most basic form, all desktop virtualization packages work like this:

End user desktop PCs are replaced with virtualized guest operating systems, running inside virtual hosts, such as VMware ESX Server
End users then use a hardware or software thin client device to connect to those desktops. Typically, a protocol like RDP is used.
While you can manually have an end user to virtual guest mapping, this does not scale beyond a handful of users. A VDI “broker” is what comes in and automatically maps the correct user (no matter where they connect from) to their correct virtual desktop system running “in the cloud”. These VDI brokers go on to provide many more features such as dynamic creation of virtual desktop systems for end users, connection over the Web, universal printing support.

Previously, VMware’s VDI solution offered a desktop broker called “VDM”. This broker is still a critical piece of View but it offers so much more. VMware’s View 3 offers you:

Universal Client and universal web interface – a single client can be used whether you are accessing a Physical PC, Terminal Services, Application Virtualization Apps (using ThinApp), or a VDI Virtual Desktop
Reduce Costs of Desktop Management – just as you reduce IT costs and speed response to business needs with server virtualization, desktop virtualization will do the same
Disaster Recovery for Desktop systems – rarely do businesses find that disaster recovery for desktop PCs is cost effective. However, with desktop virtualization, due to the low cost of storing virtual desktops and using universal thin client devices, disaster recovery for desktops suddenly becomes viable. Automation of Virtual Desktop Provisioning
Virtual Printing and a universal print driver provided by ThinPrint. In fact, ThinPrint even has an enhanced version of this called the “.Print Engine for VMware View Environments”
ThinApp, application virtualization
Offline Desktop – a truly amazing experimental feature where you can take your virtual desktop offline and re-sync it later
Thin Client Support
Single Virtual Disk Image for clients to share (as Brian Madden details in his article: A deeper look at VMware's upcoming "View Composer" VDI disk image technology) with the new View Composer.

Overall, VMware claims that View will reduce storage and desktop management costs by 90% and that desktop provisioning time can be cut down to just 15 seconds

What components make up VMware View?

So what does a sample VMware View infrastructure look like? Here is VMware’s vision:

Figure 1: Sample VMware View Infrastructure

As you can see in the diagram, a VMware View infrastructure is made up of the following components:

Clients connecting to view with either View Client, View Portal (web) or Thin client device
View Connection Server – the “VDI Broker” – running Windows Server 2003
A View Administrator, accessing the View Connection Server via a web browser
Microsoft AD Serve, only used to authenticate users
Virtual Center Server, managing the ESX Hosts
ESX Host systems, running the guest VMs which are the View Clients (or virtual desktops)
Guest VMs which are the VM desktops that the client machines are eventually connected to and which are running special VMware View software called the View Agent.

How do you Evaluate and Install VMware View?

Based on the list of the infrastructure that makes up the VMware View (above), you can imagine what will need to be done to get VMware View running in your environment. Assuming that you already have a Microsoft Active Directory running and your own domain controller, here is a list of the, very simplified, steps you would take:

Download a 60 day evaluation license and software kit for VMware View 3. This kit includes:
a) VMware Virtual Infrastructure Suite (ESX Server & vCenter)
b) VMware View Manager
c) VMware View Composer
d) VMware ThinApp
e) Offline Desktop (experimental)
Of course, the installation and evaluation of VMware View is easier if you already have VMware’s vCenter and ESX Server installed in your datacenter. Assuming you do not, you will need the following:
a) ESX Server (make sure it matches the HCL) - unless you already have ESX running
b) vCenter Server (or could be a virtual machine inside your ESX host)
c) Windows 2003 Server that will serve as the VMware View Manager (I also believe that this could be a virtual machine inside your ESX host)
d) Client PC running the View Client (or other type of client)
Install the ESX host and vCenter Server
Install VMware View Manager on the Windows 2003 Server
Configure the VMware View Manager (see the View Manager Administration Guide)
Create a new VM inside the ESX host and install the View Agent inside the VM.
Connect to the new virtual desktop infrastructure (VDI) using the Client PC running the View Client. The client will learn what VM guest it needs to connect to based on the rules configured on the View Manager.

Again, this is a simplified look at how View 3 is installed. For detailed information on requirements, configuring view manager, and deploying virtual desktops, please read the VMware View Manager Administration Guide.

Summary

VMware View 3 is the latest version of VMware’s VDI Solution. View has many valuable updates over the previous version including thin client provisioning, universal printing, application virtualization, offline desktop, and more. I encourage you to take the steps listed out in the “how do you evaluate and install VMware View” section to get started learning more about VMware View, first hand.

A First Look at the New VMware Server 2.0 RC1 (and How it Compares to ESXi)

2009-09-21T17:05:00.002+05:30

Introduction

For many years, VMware Server has been VMware's sole FREE virtualization offering. VMware Server runs on top of the Windows or Linux operating system and is an excellent platform for server virtualization. Recently, it was announced that VMware ESXi Server will now be offered at no cost. Now, if you are looking for a powerful but free virtualization platform for your SMB (from VMware), you have a choice between VMware Server and VMware ESXi. With the release of VMware Server 2.0, there are many few features offered with VMware Server. In this article, let's find out what VMware Server has to offer and how VMware Server compares to ESXi.

What is VMware Server?

For those who do not know, VMware Server is VMware’s free server virtualization product that runs inside Windows or Linux. VMware Server’s main competition is Microsoft Virtual Server. However, with VMware ESXi Server now being free, customers now have a greater choice of free server virtualization products (we will talk about how VMware Server & ESXi compare in an upcoming paragraph).

With VMware Server, you can run multiple guest operating systems inside your host operating system. There are many combinations of how this can be done. For example, you could run Linux inside Windows Server or Windows Vista inside Linux.

Now let’s find out about the latest version of VMware Server…What’s new in VMware Server 2.0 RC1?

VMware Server 2.0 RC1 was very recently released and, as you would expect with a new major revision, there are many new features. Here are some of those features:

Enhanced VMware Infrastructure (VI) Web Access management interface: VMware has replaced the version 1.x “VMware Console” application with a new web-based interface. To me, this is good and bad. The older application console was very nice. It always worked, it was easy to use, and it was consistent. With the new web interface, you could have web browser issues, DNS lookup issues, Java issues, or you could have difficulty understanding where to click. I know that most every application is going to a web-based interface because it does have benefits but there are pros and cons to each. We will take a look at that new web-based interface in the next section.

Figure 1: New VMware Infrastructure Web Access Management Interface

Independent virtual machine console: To me, this is one of the best features. Instead of having to open the virtual machine console in your web browser (inside the VI Web Access interface), you can have a separate desktop icon for each of your guest VMs. You could also use this to administer VMs on other VMware Servers, across the network. Once you launch the console, you have control over the guest’s virtual devices. Here is what it looks like, once launched:

Figure 2: New standalone console

Support for USB 2.0 devices
Remote Client devices

Not only can you connect virtual ISO files and physical drives from the VMware Server but you can also connect virtual and physical CD devices that are on a client system, managing a VM guest remotely. Thus, using the VMware client, you could connect your local CD drive to any server that you happen to be managing.

Figure 3: Ability to access client and server CD devices

Ability to add new SCSI disks on the fly without shutting down the guest VM
Volume Shadow Copy Service (VSS) support

Previously, if you took a VM snapshot, it was possible that the data from an open application may not be valid. Now, with support for Microsoft’s volume shadow copy service (VSS), VMware will actually communicate with the Guest Windows OS and take a VSS snapshot of the virtual disk, inside the guest to ensure that all data is intact when a snapshot is restored.

Virtual Machine Communication Interface (VMCI)

This new interface speeds up virtual machine to host and VM to VM communication.

Automatic Startup of VMs
Support for Firefox 3 as a web browser
Link to Virtual Appliance Marketplace

With this link, you can quickly and easily download virtual appliance from the Internet and import them into VMware Server. In fact, the link should take you to a VMware Server only appliance download section.

Figure 4: Link to the virtual appliance marketplace

64-bit Guest OS Support
Increase Scalability

Support for up to 8 GB of RAM (up from 3.6 GB in Server 1.0) per virtual machine, 10 virtual network interface cards and up to two virtual SMP (vSMP) processors per virtual machine.

What does the new VMware Server 2.0 interface look like?

The new management interface for VMware Server 2.0 is certainly different than version 1.0 and it takes some getting used to. Let’s take a look:

Figure 5: Inventory Screen in the new VMware Server 2.0 RC1 management interface

In Figure 5, above, you can see the new VMware Server 2.0 RC1 management interface. I pointed out a couple of areas that I noticed as being different. The first arrow points to the Datastores section. VMware Server 2.0 now uses datastores as a common store for virtual machines and images. The next arrow points to VMware Tips section. This area is designed to upsell you to the VMwware Infrastructure Suite.

Figure 6: Virtual Machines Gust Configuration

In Figure 6, above, you can see the guest VM status & configuration screen. If you click on a virtual guest machine, you will be able to configure its devices, see its resource utilization, view a quick status screen, and issue quick commands for that server.

Is VMware Server ready for “prime time”?

So VMware Server 2.0 offers some great features but it is ready to be used in production? Well, there is a centralized management application for multiple VMware Server systems called VMware Virtual Center for VMware Server. Did you know that you can even purchase support for VMware Server? This makes VMware server a production-ready virtualization platform. But, is it the best virtualization platform? Now that VMware ESXi Server is free, you have an alternative. We will find out what the new VMware Server 2.0 looks like, then move on to how it compares with VMware ESXi Server.

How does VMware Server 2.0 RC1 compare to VMware ESXi Server?

You should keep the differences between VMware Server and VMware ESXi Server in mind. Now that these are both free you have a choice between them but these are also very different products. Let’s list out the unique qualities of each:

VMware Server 2.0

Runs on top of your current Windows or Linux OS. That means that you can keep all your existing apps and run VMware Server along with everything else you are doing.
While still having good performance, VMware Server’s performance is not as strong as ESXi because the Server runs inside your OS.
Can run on any hardware that your current Windows or Linux host OS supports.
Ideal for desktop virtualization and server virtualization for the SMB. Ideal for those who do not want have to go through the trouble of using a whole new OS for virtualization.

VMware ESXi Server

Runs on the bare metal server hardware. That means that you have to wipe out all of your apps and data on a machine and install ESXi.
Greater performance because it runs directly on hardware.
Able to run only on certain hardware.
Ideal for medium & large enterprise virtualization.

Conclusion

In this article, you learned about the new VMware Server 2.0 RC1 virtualization platform. We discussed the many valuable features of VMware Server 2.0 and you got to see the new management and console applications. Finally, we learned the difference between VMware Server and ESXi Server. VMware Server 2.0 is a significant upgrade from previous versions and an excellent desktop or SMB Server virtualization solution.

Configuring a Virtual Machine Using VMware

2009-09-21T16:37:00.003+05:30

Introduction

This article shows how to use VMware ESX Server, the VMware Infrastructure Client (VIC) and the VirtualCenter management console to create a new VM running a host operating system of Windows XP Professional SP 3. We will look at how to plan and prepare for the deployment of an XP ISO file, as well as to show the steps needed to configure a VM for use on your network.

Preparation

To configure a VM, you need to be using a running version of ESX, or you can download and use VMware Server from the VMware Web site. VMware while not extremely difficult to use, can be very confusing to those first learning it. If you are new to VMware, it is highly recommended that you visit the links section and connect to the VMware Web site documentation and download a version that you can work with on your desktop. For those running production systems and/or ESX server, to prepare for a VM install, you need to follow most of the same steps you would when installing an operating system on a physical system – you need to check the host operating systems minimum hardware requirements as an example.

There are a few general items that you need to be aware of when configuring a new VM with VMware. First, when considering a new VM, you need to be aware of your total resources. VMware works off of resource pools and the theory of using slicing. When you create a new VM, resource must be taken for it therefore you must know how much you need and how much you have. For example, in this article we will create a new Windows XP Professional VM. Hypothetically speaking, if we needed this new VM for software testing and the minimum hardware requirements are now maximized, you may run out of resources very quickly. Secondly, you must consider how you will install the host operating system. Since you still need installation media such as CDs, DVDs or an ISO file, it needs to be accessible to the VMware infrastructure and you need to configure it within your new VM. Lastly, you should have a connection to the Internet via your VMware infrastructure to run Windows (or Microsoft) update to patch and repair your guest operating system. Now that you know a few general guidelines, let’s set up prepare to create a VM. Log into the VirtualCenter with the VIC as seen in Figure 1.

Figure 1: Viewing the VIC (VMware Infrastructure Client)

Once logged in, you can then create a Virtual Machine (VM). To create a VM you will need to be logged on with administrative privileges. Now that you are logged in as an administrator you need to do preparation work to get your VM ready to create and then install. First, you need not only the files for the host operating system but for further preparation you may need extra drivers as well. Both the host system files and the drivers will need to be accessible to the VM once it’s created so either have the data ready via CD, DVD or Floppy media. Also make sure that your disks are usable and not damaged.

If you are running a SAN (as in this lab example), then you can use a VMFS based LUN to store your data on. If you do, then you can switch to the ‘Datastores’ view in your VirtualCenter as seen in Figure 2.

Figure 2: Viewing your Datastore

In this article, we will look at using an ISO file stored on a LUN from an attached SAN over Fiber as the guest operating system. Magic ISO Maker and other online tools can help you take a normal installation disk and create an ISO file out of it, or you can also get ISO files from MSDN and Technet.

Now, we will need to upload the needed ISO file on to a datastore. From a LUN that you have available space on (which can be seen in the General section of the VirtualCenter Datastores view) open the Datastore Browser by selecting ‘Browse Datastore…’ In this example we will also upload a set of SCSI drivers we will need for the installation as well. Once the Datastore Browser is opened, upload the ISO file as seen in Figure 3,

Figure 3: Upload the ISO with the Datastore BrowserCreating a Virtual Machine

In this example we will create a Virtual Machine with ESX server. Now that your installation files (and needed drivers) are uploaded then next task is to create a VM to install Windows XP into. To do that we need to create a VM with the needed resources from the resource pool. To create a VM, you first need to create the container that the host system will sit in. Since VMware is essentially the sharing of resources, you will have to configure each one of those resources in order for your install to take place. For example, you will need to configure a way for the VM to find the ISO file on the LUN. To do this, you must fist create a VM. Then, once the VM is created, you will need to map the VM to the LUN to find the ISO file to run the install from. The easiest way to do this is with the Virtual Machine Wizard. To use this Wizard, you can go to File New Virtual Machine…

Once selected, you will invoke the New Virtual Machine Wizard as seen in Figure 4. Now, you can select the needed resources for the VM. When you launch the Wizard, you will go through a series of windows that allow you to select the type of VM you want, the name and location of it (It can reside on one of multiple servers if running VMware is running in a cluster), the datastore where the VM and its associated files will reside, the selection of the name and type of guest operating system as well as for resources such as CPU, Memory (as seen here), the network location and the Virtual Disk Capacity (or size).

Figure 4: Viewing the Virtual Machine Wizard

Once you get to the last screen (Ready to Complete), take note of the small check box you can select on the bottom left side of the dialog box as seen in Figure 5.

Figure 5: Edit the Virtual Machine Settings

Once you have selected all of the resources you need and have configured your VM with the appropriate settings, now its time to click Finish. You can also edit the VM after it’s created but since we selected to Edit the VM settings before the VM finishes creating you can see in Figure 6 that the Hardware is still listed as ‘adding’.

Figure 6: Configuring the VM Hardware

In Figure 7, you can see the different options available to you when configure a VM’s hardware. Now that we have to install a guest operating system into this VM, we need to configure a way for a CD, DVD or an ISO on a LUN to be accessible to begin the installation.

Figure 7: Configure a Datastore ISO File

Once you have finished configuration your hardware, next you can click Finish and your VM will be created and your ISO file attached to being the installation. Take note to select the check box on the ‘Connect at power on’ option in the Device Status section of the New CD/DVD hardware section where you connected your ISO. You need to select ‘connect’ because if you do not then when you ‘power on’ the VM, the file will not be available thus the installation will not start.

Once back in VirtualCenter, taken note of the task pane on the bottom of the screen. Your VM will be started and your progress shown. Sometimes it takes up to a minute for a VM to be created depending on what your selections are, what host its being added to if in a cluster, how many resources are available and how much load is currently on any given system. Once created, you will now be able to right click the VM in the console (if still in Datastore View, switch to Hosts and Clusters) and then ‘power on’ the VM. Here, you can also select ‘Edit Settings’ or many other options. Now, you should switch to the Console tab as seen in Figure 8.

Figure 8: Viewing an Installation on the VMs Console in VirtualCenter

Now, you can start your installation of Windows XP and hopefully not need the drivers listed. With XP (and why this was chosen for this particular article) its likely you will need extra SCSI drivers so if you do, the process is no different then if you were installing most any other Windows operating system – during the installation, press F6 to install advanced SCSI and/or RAID drivers and when given an option, load them off the LUN, a flp file, a CD/DVD or any other form of media you can connect. You may also have to go into the BIOS of the system and change the boot order as well to get the media connected to the installation program. Once the drivers are installed, you will install XP (and update it at Windows update) as if you were installing it on a physical machine on your companies network.

Lastly, it’s always recommended to patch Windows systems. Even though this current ISO was directly downloaded from MSDN with the Service Pack slipstreamed, running an update online still produced needed patches and hotfixes.

You should also install VMware tools as seen in figure 9 as this will also make it much easier to manage your VM within the VirtualCenter. One of the biggest differences is how you switch between working in the VirtualCenter and/or working within a VM. Without the VMware tools installed, you need to press ctrl+alt to switch between. With the toolset installed, you can operate seamlessly between both without having to do any keystroke combinations to disconnect once connected to a VM.

Figure 9:Installing VMware Tools

Summary

In this article we looked at how to create a VM with VMware ESX server, install a guest operating system (Windows XP) and configure needed resources, tools and settings.

Overview of VMware ESX / VMware Infrastructure Advanced Features

2009-09-21T15:46:00.002+05:30

Introduction

VMware ESX Server and the various VMware Infrastructure Suite (of which ESX Server is a part of) offer many advanced features. While there are many advanced features of ESX Server, itself, many advanced features that most people associate with ESX Server, are typically optional add-ons (products) that are purchased either individually, or more typically, as part of the VMware Infrastructure Suite (or the “VI Suite”). In this article, you will learn what these advanced features are, how they can help you, and how they are packaged and purchased when you consider VMware ESX Server and the VI Suite. As there are so many advanced features, I have chosen the top 10 advanced features of ESX to cover.

#1 ESX Server & ESXi Server

Even if all that you purchase is the most basic VMware ESXi virtualization package at a cost of $495, you still gain a number of advanced features. Of course, virtualization, in general, offers many benefits, no matter the virtualization package you choose. For example - hardware independence, better utilization of hardware, ease of management, fewer data center infrastructure resources required, and much more. While I cannot go into everything that ESX Server (itself) offers, here are the major advanced features:

Hardware level virtualization – no based operating system license is needed, ESXi installs right on your hardware (bare metal installation).
VMFS file system – see advanced feature #2, below.
SAN Support – connectivity to iSCSI and Fibre Channel (FC) SAN storage, including features like boot from SAN
Local SATA storage support.
64 bit guest OS support.
Network Virtualization – virtual switches, virtual NICs, QoS & port configuration policies, and VLAN.
Enhanced virtual machine performance – virtual machines may perform, in some cases, even better in a VM than on a physical server because of features like transparent page sharing and nested page table.
Virtual SMP – see advanced feature #4, below.
Support for up to 64GB of RAM for VMs, up to 32 logical CPUs and 256GB of RAM on the host.

#2 VMFS

VMware’s VMFS was created just for VMware virtualization. Thus, it is the highest performance file system available to use in virtualizing your enterprise. While VMFS is included with any edition or package of ESX Server or VI that you choose, VMFS is still listed as a separate product by VMware. This is because it is so unique.

VMFS is a high performance cluster file system allowing multiple systems to access the file system at the same time. VMFS is what gives you a solid platform to perform VMotion and VMHA. With VMFS you can dynamically increase a volume, support distributed journaling, and the addition of a virtual disk on the fly.

#3 Virtual SMP

VMware’s Virtual SMP (or VSMP) is the feature that allows a VMware ESX Server to utilize up to 4 physical processors on the host system, simultaneously. Additionally, with VSMP, processing tasks will be balanced among the various CPUs.

#4 VM High Availability (VMHA)

One of the most amazing capabilities of VMware ESX is VMHA. With 2 ESX Servers, a SAN for shared storage, Virtual Center, and a VMHA license, if a single ESX Server fails, the virtual guests on that server will move over to the other server and restart, within seconds. This feature works regardless of the operating system used or if the applications support it.

#5 VMotion & Storage VMotion

With VMotion, VM guests are able to move from one ESX Server to another with no downtime for the users. VMotion is what makes DRS possible. VMotion also makes maintenance of an ESX server possible, again, without any downtime for the users of those virtual guests. What is required is a shared SAN storage system between the ESX Servers and a VMotion license.

Storage VMotion (or SVMotion) is similar to VMotion in the sense that "something" related to the VM is moved and there is no downtime to the VM guest and end users. However, with SVMotion the VM Guest stays on the server that it resides on but the virtual disk for that VM is what moves. Thus, you could move a VM guest's virtual disks from one ESX server’s local datastore to a shared SAN datastore (or vice versa) with no downtime for the end users of that VM guest. There are a number of restrictions on this. To read more technical details on how it works, please see the VMware ESX Server 3.5 Administrators Guide.

#6 VMware Consolidated Backup (VCB)

VMware Consolidated Backup (or VCB) is a group of Windows command line utilities, installed on a Windows system, that has SAN connectivity to the ESX Server VMFS file system. With VCB, you can perform file level or image level backups and restores of the VM guests, back to the VCB server. From there, you will have to find a way to get those VCB backup files off of the VCB server and integrated into your normal backup process. Many backup vendors integrate with VCB to make that task easier.

#7 VMware Update Manager

VMware Update Manager is a relatively new feature that ties into Virtual Center & ESX Server. With Update Manager, you can perform ESX Server updates and Windows and Linux operating system updates of your VM guests. To perform ESX Server updates, you can even use VMotion and upgrade an ESX Server without ever causing any downtime to the VM guests running on it. Overall, Update Manager is there to patch your host and guest systems to prevent security vulnerabilities from being exploited.

#8 VMware Distributed Resource Scheduler (DRS)

VMware’s Distributed Resource Scheduler (or DRS) is one of the other truly amazing advanced features of ESX Server and the VI Suite. DRS is essentially a load-balancing and resource scheduling system for all of your ESX Servers. If set to fully automatic, DRS can recognize the best allocation of resource across all ESX Server and dynamically move VM guests from one ESX Server to another, using VMotion, without any downtime to the end users. This can be used both for initial placement of VM guests and for “continuous optimization” (as VMware calls it). Additionally, this can be used for ESX Server maintenance.

#9 VMware’s Virtual Center (VC) & Infrastructure Client (VI Client)

I prefer to list the VMware Infrastructure client & Virtual Center as one of the advanced features of ESX Server & the VI Suite. Virtual Center is a required piece of many of the advanced ESX Server features. Also, VC has many advanced features in its own right. When tied with VC, the VI Client is really the interface that a VMware administrator uses to configure, optimize, and administer all of you ESX Server systems.

With the VI Client, you gain performance information, security & role administration, and template-based rollout of new VM guests for the entire virtual infrastructure. If you have more than 1 ESX Server, you need VMware Virtual Center.

#10 VMware Site Recovery Manager (SRM)

Recently announced for sale and expected to be shipping in 30 days, VMware’s Site Recovery Manager is a huge disaster recovery feature. If you have two data centers (primary/protected and a secondary/recovery), VMware ESX Servers at each site, and a SRM supported SAN at each site, you can use SRM to plan, test, and recover your entire VMware virtual infrastructure.

VMware ESX Server vs. the VMware Infrastructure Suite

VMware ESX Server is packaged and purchased in 4 different packages.

VMware ESXi – the slimmed down (yet fully functional) version of ESX server that has no service console. By buying ESXi, you get VMFS and virtual SMP only.
VMware Infrastructure Foundation – (previously called the starter kit, the Foundation package includes ESX or ESXi, VMFS, Virtual SMP, Virtual Center agent, Consolidated backup, and update manager.
VMware Infrastructure Standard – includes ESX or ESXi, VMFS, Virtual SMP, Virtual center agent, consolidated backup, update manager, and VMware HA.
VMware Infrastructure Enterprise – includes ESX or ESXi, VMFS, Virtual SMP, Virtual center agent, consolidated backup, update manager, VMware HA, VMotion, Storage VMotion, and DRS.

You should note that Virtual Center is required for some of the more advanced features and it is purchased separately. Also, there are varying levels of support available for these products. As the length and the priority of your support package increase, so does the cost.

Conclusion

In this article, I covered 10 of the many advanced features of VMware ESX Server & the VMware Infrastructure Suite. You learned what these advanced features are, how they can help you, and how they are packaged & purchased. VMware ESX is certainly the most feature-rich virtualization product available today and, after reading this article, you should have a good understanding of what these advanced features are and the power that they bring to your datacenter.

What is Storage VMotion (SVMotion) and How do you perform a SVMotion using the VI Plugin?

2009-09-21T15:04:00.003+05:30

Introduction

In my recent VirtualizationAdmin.com article Overview of VMware ESX / VMware Infrastructure Advanced Features, one of the many features I covered was VMware's Storage VMotion (aka SVMotion). I covered how Storage VMotion is similar to VMotion in the sense that "something" related to the VM is moved and there is no downtime to the VM guest and end users. However, with SVMotion the VM Guest stays on the server that it resides on but the virtual disk for that VM is what moves. Thus, you could move a VM guest's virtual disks from one ESX server's local datastore to a shared SAN datastore (or vice versa) with no downtime for the end users of that VM guest.

There are a number of restrictions on this. To read more technical details on how it works, please see the VMware ESX Server 3.5 Administrators Guide.

Additionally, there are at least 3 ways to perform a SVMotion – from the remote command line, interactively from the command line, and with the SVMotion VI Client Plugin (to see these in video form, checkout SVMotion - watch it happen here (in 3 ways). By far, the easiest way to perform a SVMotion is to use the free VI Client Plugin and that is what we will demonstrate in this article.

Image Source: VMware SVMotion

How do I obtain and install the VI Client Plugin?

The free VI Client Plugin was generously created by Andrew Kutz and it provides a wonderfully needed GUI for SVMotion. I still cannot believe that VMware released and heavily touts this feature but offers no GUI interface for it.

The first step would be for you to download the SVMotion from here: SVMotion VI-Client Plugin.

It is a simple Windows MSI installer and there are no questions asked during the installation (that is the kind I like, that is, as long as I trust the app). When you are done installing it, you will see this window:

Figure 1: SVMotion VI-Client Plugin Installation Complete

After you close this window, open the VI Client (if it was already open then you should close it and reopen it).

Next, Go to the Plugins Option, then Manage Plugins, on the VI Client Toolbar, like this:

Figure 2: Go to the Plugins Option, then Mange-Plugins, on the VI-Client Toolbar

Click on the Installed tab of the Plugins Manager and check the checkbox to Enable the new SVMotion Plugin, as you see below.

Figure 3: Enabling the SVMotion Plugin

Now that the SVMotion Plugin is installed and enabled, if you right-click on a Cluster, an ESX Server, or a VM guest, all the way at the bottom, you should see Migrate Storage. This tells you that SVMotion is ready to happen when you are ready to test it.

Note:
You need to have VMotion configured and working for SVMotion to work. Additionally, there are a ton of caveats about SVMotion in the ESX 3.5 administrator’s guide (page 245) that could cause SVMotion not to work. One final reminder, SVMotion works to move the storage for a VM from a local datastore on an ESX server to a shared datastore (a SAN) and back – SVMotion will not move a VM at all – only the storage for a VM.

How to move the storage for a VMware ESX Guest VM using the SVMotion Plugin (with no downtime)

Now that you have the SVMotion GUI, actually moving the storage of a VMware ESX Server Guest VM, with no downtime for the end users, is quite easy. To do it, in the VI Client, right-click on a cluster, ESX server, or guest VM. Go down to Migrate Storage and you should see a window like this:

Figure 4: Preparing to use VMware ESX Server SVMotion

Depending on what you clicked on (cluster, host, or VM) and how much storage you have, you may have very little in the window or you may have a lot.

In my case, my test VM called “David D Test” is located on the local storage of an ESX Server (called “storage 6b”) connected to an iSCSI and a FC SAN. To move my Virtual machine’s storage (including the VMX files and VMDK files) from the local storage to the shared iSCSI SAN (called “storage”), all I have to do is to drag the VM from where it is to the new storage, like this:

Figure 5: Moving Storage with SVMotion

Then, I click Apply.

Down in my task window, I see the “Relocate Virtual Machine Storage”, like this:

Figure 6: Relocating Virtual Machine Storage

When the process is done, I see “Completed” in the task window and I see that my storage for this VM has moved from the local storage to the shared iSCSI SAN storage. I can see this in the datastore section of the VM resources, below:

Figure 7: Storage for the VM has moved

And, of course, the most amazing thing about all of this is that the virtual guest operating system was powered on this entire time. As you can see from the graphic above, the status still says “powered on”. Because of this and because of how SVMotion works, there was never any downtime for the end users who may have been accessing this virtual guest.

This feature is great for maintenance of server hardware, ESX Server maintenance, maintenance of disk arrays, rearranging storage, and many more applications. Of course, for some of those applications (like maintenance of server hardware) you would also have to perform a VMotion and move the running guest OS to another physical server.

Conclusion

In this article, I provided an overview of VMware’s Storage VMotion, where to find an indispensible SVMotion plugin for the VI Client, and a step by step demonstration of how SVMotion works to move a VMware ESX Guest VM’s storage, from one datastore to another, without any downtime to the end users. In my opinion, SVMotion is an amazing product and its application and adaptation will just continue to grow and grow - making the life of virtualization admins like us easier and easier (I hope).

How to schedule tasks with the VMware Infrastructure Client and ESX Server

2009-09-21T12:59:00.003+05:30

Introduction

In the VMware Infrastructure Client (VI Client), you will notice a Scheduled Tasks button on the main toolbar. That button looks like this:

Figure 1: Scheduled Tasks Toolbar Button

If you click on this button, by default, you will see that you can only create new scheduled tasks and you won’t have any scheduled tasks already created. VMware ESX VI Client Scheduled Tasks are a powerful feature of the VI Client, albeit a feature that doesn’t get a lot of recognition.

With the VI Client Task Scheduling feature, you can schedule the following tasks:

Change the power state of a virtual machine
Clone a virtual machine
Deploy a virtual machine
Move a virtual machine with VMotion
Relocate a virtual machine
Create a virtual machine
Make a snapshot of a virtual machine
Add a host

Here is what it looks like:

Figure 2: Selecting a Task to Schedule

Now, for some of these types of tasks that can be scheduled, I have trouble coming up with a scenario where you would want to perform that task when you weren’t around. For example, I am not sure why you would want to add a VMware ESX host system to Virtual Center when you weren’t around. On the other hand, there are many that I can see some great application for. Let’s look at those…

How Scheduled VMware VI Client Tasks can help you

Here are a few examples of how the VMware VI Client scheduled tasks feature can help you:

Change the power state of a virtual machine – say that you wanted to create scheduled tasks that would power off a VM at night and power on that VM in the morning. Perhaps there is a security reason for doing this or perhaps it just helps to reboot the VM for the stability of the underlying applications. Either way, the VI Client Scheduled Task feature can do this for you.
Make a Snapshot of a Virtual Machine – perhaps you run a process in a VM every night that, due to poor programming, can have unexpected results that cause you to have to restore data. With the VI Client scheduled tasks feature, you could schedule a snapshot to run automatically each night before that process ran. By doing that, you have created a VM snapshot automatically using the VI client scheduled tasks feature.
Move a virtual machine with VMotion - using the VI Client scheduled tasks feature, you could create a task that you run daily and move a virtual machine from one host to another – amazing! Perhaps you need to reboot a VMware ESX server each night and this schedule tasks could alleviate any downtime for that server.

Those are just a few of the types of scheduled tasks that you can perform with the VI Client. Now let’s look at, step by step, how to create and test a scheduled task to take a snapshot of a VMware ESX Server Guest VM at a certain time.

How to create a scheduled tasks to take a snapshot of a VMware ESX Server guest VM

With the VI Client, creating a scheduled task to take a snapshot of an ESX Server guest VM at a certain time is easy. Simple click on the Scheduled Tasks button on the main VI Client Toolbar, then click New to create a new scheduled task (as in Figure 3).

Figure 3: Creating a new scheduled task

This will bring up the Schedule a Task window, as you see in Figure 2, above. At that point, you should choose the Make a Snapshot of a virtual machine option, and click OK.

Figure 4: Choosing the snapshot scheduled task

Next, a new window will come up where you will choose the VM guest that you want to make a snapshot of, like this:

Figure 5: Choosing which VM (Virtual Machine) to take a scheduled snapshot of

After clicking Next, you will be asked to provide a name for the snapshot (because we are scheduling to take a snapshot), enter notes about the snapshot, and provide any options related to the snapshot (as in Figure 6).

Figure 6: Naming the snapshot and providing snapshot options

After clicking Next, you will be asked to name the scheduled task, provide a description, then set the frequency for the task.

Figure 7: Naming and setting the frequency for the scheduled task

Notice how you can set the scheduled task to just run once, only after startup, hourly, daily, weekly, or monthly. There is a lot of flexibility in this that allows you to configure scheduled tasks and then not have to worry about them.

In our case, I chose to run the scheduled task just once and I set it to run in 2 minutes.

Figure 8: Final verification of scheduled task

I was given the option to verify the scheduled task one last time, then I clicked Finish.

I saw that the scheduled task was added to the list of scheduled tasks and very quickly the scheduled task started. I saw the progress down in the recent task list (see Figure 9, below).

Figure 9: Scheduled Task Started

The snapshot only took a few seconds and the task showed completed in the recent tasks list.

To verify it, I also went to the Events section of the VI client and saw that the task had compelted there as well.

Figure 10: VI Client Events showing the scheduled task completed

For one last point of verification, I went to the Snapshot Manager for the VM guest and I verified that the snapshot called “Scheduled Snapshot of VM” has indeed taken place (see below).

Figure 11: Snapshot manager for VM guest

And with that, we have demonstrated, step by step, how the scheduled task function of the VI Client can be used to create a scheduled task to take a snapshot of a VMware ESX Server Guest VM on a schedule.

Conclusion

In conclusion, automated task scheduled in your VMware Infrastructure can be very convenient and can save you a lot of time. In this article, I provided an overview of what task scheduling in the VMware Infrastructure client can do for you, scenarios where you would want to schedule tasks, and how to schedule tasks using the VI Client, step by step.

Understanding VMware ESX Server Security Profiles

2009-09-21T12:51:00.001+05:30

Introduction

VMware ESX Server's built-in software firewall is called the "security profile" for the host server. To be clear, this firewall is the firewall for the entire host - including the service console (if it is not an ESXi server) but not the virtual guests running on the host. Personally, I wish that it was just called the "firewall", but the term "security profile" has "grown on me". I hope that after you read this article it will stick in your mind as well. Let's learn how it works, how to configure it in the GUI & CLI, and why it is important to you as a VMware Admin.

How does the VMware ESX Server Security Profile work?

As the VMware ESX Server security profile is the software firewall of the ESX Server its job is to monitor both inbound and outbound TCP & UDP ports to and from the ESX server. This is done in order to protect the server from network attack.

By default, only specific inbound connections are allowed to a VMware ESX Server. Specifically, (on an ESX 3.5 Server) only SSH and ports related to the VMware Infrastructure & Virtual Center management services are allowed inbound. If you want to access the server with any other applications, inbound, you will have to open that specific port.

Why is the VMware ESX Server Security Profile so important to you as an ESX Server Admin?

The VMware ESX Server Security Profile is important to you, as an ESX Server Admin for a few reasons:

So that you can understand how your ESX Server is protected from attack and so that you can properly secure your server.
If there are ESX services that you want to enable, such as FTP or NTP, you will need to open security profile ports.
If you install any 3rd party applications on the server, you may need to open ports.

How do I configure Security Profiles in the VMware ESX Server VI Client?

To configure security profiles in the VMware Infrastructure Client (VI Client), open the client, log in, and click on an ESX Server, as you see in Figure 1 below.

Figure 1: Accessing the VMware ESX Server Security Profile

Next, you would click on the Configuration tab, then on Security Profile (under Software), as you see in Figure 1.

From here, you can see (on the left) what security profile (firewall) ports are opened on your server (both inbound and outbound). For example, on this server, you can see that SSH and CIM services (used for the VI Client and Virtual Center) are all opened, inbound. Outbound, SSH, Virtual center, VMware License server, iSCSI, NTP, and VCB are all open.

Figure 2: Viewing Security Profile Status and Configuring Security Profile Properties

So how do you change what ports are open, inbound and outbound? The answer is to click on the Properties for the security profile, as you see in Figure 2, above.

Once you click on the security profile properties, you will get a new window that looks like this:

Figure 3: Configuring Security Profile Properties

From the Security Profile properties window, you can enable the preconfigured applications & ports.

Let’s say that we wanted to enable SNMP services inbound and outbound. To do this, just check the checkbox next to that service. In our case, I enabled the SNMP Server port, allowing UDP traffic on port 161 inbound and UDP traffic on port 161. Notice that SNMP is not connected to a particular daemon, as the SSH server is. To apply changes, click OK.

There are times when you need to open a port in the firewall for various applications. For example, if you want to use iSCSI.

If a port is connected to a daemon and you select that port, you can click on the Option button for that port and see the services associated with it, like this:

Figure 4: Daemon / Service Properties

As I did not want to make any changes to the service, I just clicked OK.

Notice that you are limited to the preconfigured applications and whatever their specific inbound or outbound port that is preconfigured for that application. Plus, from the GUI interface, you cannot add any new ports or applications.

How do I configure the ESX Server security profile from the command line (CLI)?

To configure the security profile from the command line, use the esxcfg-firewall command. You would first, of course, have to SSH to the ESX Server and log in first before you can use this command.

The command syntax is simple. To see all the command options, just type the esxcfg-firewall command by itself, and press enter (see Figure 5, below).

Figure 5: esxcfg-firewall command syntax

To view open ports, use the esxcfg-firewall -q command line option.

To open a specific port, you would type a command similar to this:

[root@ESX3 root]# esxcfg-firewall -o 1000,tcp,in,test

However, don’t expect your CLI change to show up in the GUI interface.

You can also configure a port range, like this:

[root@ESX3 root]# esxcfg-firewall -o 1000:1050,tcp,in,test

Conclusion

In this article, you learned about VMware ESX Server’s built in software firewall - the “security profile”. You found out about how the security profile is the firewall for the entire host – including the service console (if it is not an ESXi server) but not the virtual guests running on the host. After that, we covered how the security profile works, how to configure it in the GUI & CLI, and why it is important to you, as a VMware Admin.

How does VMware ESXi Server compare to ESX Server?

2009-09-21T11:16:00.002+05:30

Introduction

Most of you are familiar with VMware ESX Server as it has been around for so many years. ESX Server offers the "service console" built in and it is a rather large installation (in comparison to ESXi). The latest version of ESXi is "thinner" and lacks the service console. You should note that ESXi is NOT a replacement for the traditional ESX Server but, instead, an alternate version available. In my opinion, neither of these versions is "better" than another. Instead, these two versions are just "different" from one another. Let us learn how these two differ and help you determine which one is best for you.

What are the 10 major differences between VMware ESX Server and ESXi Server?

1. VMware ESXi Server has no service console: The traditional (full) ESX Server has a special built-in virtual machine called the “service console”. This service console is really a modified version of Red Hat Enterprise Linux that is installed and running in every ESX Server by default. The service console has special access to the VMware-proprietary VMFS file system. 3rd party applications can be installed in the service console and Linux-based utilities can be run in the service console. Additionally, VMware includes a number of ESX-related tools in the service console, most of which start with “esxcfg-“ and they are run by accessing the service console with SSH.

As VMware ESXi Server has no service console, there is no SSH access to the server and there are no 3rd party applications that can be installed on the server. However, there are also benefits to NOT having these features (discussed more below).

2. VMware ESXi Server uses RCLI instead of service console utilities: As ESXi doesn’t have any CLI with VMware-related or Linux utilities, VMware needed to provide a CLI interface to ESXi. What VMware came up with is the Remote Command line Interface (RCLI). This is an application that you typically install as a VM and it is used to perform scheduled or ad hock scripting on the VMware Infrastructure. The ESXi RCLI is its own command line where ESX server service console scripting would be made up of mostly Linux utilities.

3. VMware ESXi Server is extremely thin = fast installation + faster boot: Because the service console has been removed from ESXi, the footprint in memory has been reduced to just 32MB. In my opinion, it is truly amazing that you can run a hypervisor, allowing you to run virtual machines on your server, with just 32MB of RAM overhead. In comparison, the full ESX Server on disk footprint is about 2GB.

Because the hypervisor is so small, the installation happens in about 10 minutes (or so) and the server boots up in 1-2 minutes. This is quite different from the full ESX server installation and boot, both of which are longer.

4. VMware ESXi Server can be purchased as an embedded hypervisor on hardware: While ESXi is so small that it can be easily installed and can even be booted from a USB Flash disk, what is truly unique about ESXi is that it is being sold by hardware vendors as a built-in hypervisor. That means that, say, you buy a Dell server, ESXi can be built inside the server (embedded) on a flash chip, on the motherboard. There is no installation of ESXi on disk.

5. VMware ESXi Server’s service console (firewall) is configured differently: As there is no service console to protect with the ESX Server security profile (software firewall), the security profile configuration in ESXi is very simplistic. The ESXi security profile configuration consists of a couple of services that you can either enable or not enable with inbound access. Here is a comparison between the two:

Figure 1: ESXi Security Profile – only 2 services

Figure 2: VMware ESX Server (full) Security Profile

6. VMware ESXi Server has a “yellow firmware console”: Instead of the full ESX Server “service console” boot (which looks like a Linux server booting), ESXi has a tiny “Direct Console User Interface (DCUI)”. Unofficially, I like to call this the “yellow firmware console”. In this ESXi console, all that you can configure are some very basic ESXi server options such as the root user password, network settings, and a couple other items. In the graphic below, you can see why I call it “yellow”:

Figure 3: ESXi yellow firmware console / DCUI

Because this tiny firmware console (did I mention that it’s yellow?) has so few features, the server is virtually “stateless”. A new server can be configured in seconds because there is almost nothing to configure.

7. VMware ESXi Server has server health status built in: With ESXi some hardware monitoring features are built into the hypervisor. With ESX Server, this is not yet built in. Instead, you must install hardware monitoring software in the service console. For more information on ESXi server health status and how to install vendor-specific utilities to provide similar information on ESX Servers, please see my article: Obtaining server health status in VMware ESX and VMware ESXi.

Figure 4:ESXi Health Status

8. Some networking features are configured through the service console are not available or are experimental: As ESXi is relatively new and as ESX server has the option to install code for advanced ESX Server features, not all features available in the full ESX Server are also available in ESXi. In fact, I have had issues getting VMware High Availability (VMHA) to work in ESXi. VMHA was not officially supported on ESXi until some recent patches came out for ESXi. Still, even after the patches, I had difficulties with ESXi and VMHA.

There are other ESX Server features that are “experimental” on ESXi. For the full list visit: Differences in Supported Networking Features Between ESX Server 3.5 and ESX Server 3i

9. VMware ESXi Server requires fewer patches and less rebooting: Because the full ESX server essentially has a modified Linux system as the service console, there are many patches that have to be deployed to keep it secure. With ESXi, on the contrary, the server has very few patches that need to be applied. Because ESXi has no service console and it is considered more secure and more reliable. Security, Reliability, and Maintainability, are all major factor when considering a hypervisor.

10. You can buy VMware ESXi Server for as little as $495: With the full version of ESX Server, the least expensive purchase option is the Foundation (Starter) kit for about $1,500, while you can purchase ESXi only (with no support) for $495. On the other hand, if you do get the Foundation kit, you not only get the full ESX Server but also ESXi and a number of VMware Infrastructure Suite options. Still, obtaining ESXi for under $500 allows a server to do so much more than it ever could before.

Which version of VMware ESX Server is best for you?

I am not here to sell you on VMware, on ESX Server, or ESXi Server, what I am here to do is to inform you of the drastic differences between these two versions of “ESX Server”. In my opinion, ESX Server (full) must be used if you have 3rd party apps or if you just want to have access to the “Linux-style” service console.

On the other hand, if you are willing to give up those two benefits, with ESXi, you will get an ESXi Server that boots faster, has fewer patches to deploy, and is more reliable. ESXi is also the least expensive option.

I recommend testing both VMware ESX Server and ESXi server. Both are available for a free evaluation download from VMware Inc.

Conclusion

In this article, you learned about VMware ESX Server the differences between ESXi and ESX Server. Additionally, you learned about how to make the right choice for you. Both of these hypervisors from VMware can be evaluated at no cost.

Using VMware: Understanding the Virtual Switch

2009-09-18T15:44:00.002+05:30

Introduction

In this article we will explore the VMware ‘Virtual Switch’. The Virtual Switch is nothing more than a logical switching fabric built into your VMware infrastructure (ESX) so that you can network your Virtual Machines (VMs) however you need them. In the following sections we will cover the basics of the Virtual Switch, terminology used, its use, configuration and management. To view the Virtual Switch, you will need to be using VMware, the VIC and have access to VirtualCenter.

Understanding the Virtual Switch

VMware infrastructure networking components are not easy to comprehend without a little background information and understanding of ‘networking’ in general. First, networking is the connection to and from shared resources, systems and services anywhere you can gain permitted access. In a ‘logical’ or ‘virtual’ environment, this theory is identical with one exception – you must know the difference between a physical and logical adapter and how they all link together through the virtual (logical) switching fabric hosted by VMware. Figure 1 shows the basics of VMware virtual connectivity.

Figure 1: Viewing the Virtual Infrastructure

The VMware Infrastructure complies with a modular design so that all resources can be shared and assigned as needed. Virtual and physical networking components are designed identically the same way. If you need to share some of your physical or logical resources, you simply need to have them available and then configure them for use. This helps to create the most flexibility and if done correctly, the most efficiency. Here in Figure 1 you can see that VMs can be connected to each other through a virtual switch component, and then to physical NICs as needed. In Figure 1 you will also find that the management network is separate (and isolated) from the rest of the network thus increasing security for the management of your infrastructure.

The essential virtual networking components provided by ESX are virtual Ethernet adapters, used by individual virtual machines (VMs) and virtual switches that are used to connect each VM to either each other or to the ESX service console. To configure this functionality, you need to first log into VMware VirtualCenter and browse to the server you want to configure. Once selected, you can choose the configuration tab as seen in Figure 2.

Figure 2: Viewing the Configuration tab in VirtualCenter

In Figure 3 we see that you can when you select Network Adapters from the Hardware menu, you can see the devices present, the speed in which they run at as well as for which switch they are connected to.

Figure 3: Viewing the Network Adapter Properties

Once your physical NICs are in place, we only need to add virtual NICs from your VMs to your Virtual Switch.

Configuring the Virtual Switch

The Virtual Switch is not difficult to configure if you know what your options are. If you understand the concepts of logical vs. physical, now all you need to do is configure them. Obviously, if you have already deployed your ESX server, you likely have a NIC or two installed in it. These are your physical NICs. Inside the ESX environment, you can configure the properties of the logical aspects of the switch to connect your VMs to its own network as well as the outside environment which is usually your local LAN connected to your WAN or Internet. That being said, all you need to do now is configure your VMs, then the network adapters for each of them inside the Virtual Switch. Figure 4 shows the Virtual Switch properties.

Figure 4: Viewing the Virtual Switch Properties

In Figure 5 you can configure your virtual NICs properties. For example, if you needed to configure the speed and duplex of your vmnic, all you would have to so is click on Edit and then select the speed and duplex desired.

Figure 5: Setting the Speed and Duplex on the Virtual NIC

You can also configure the number of ports used in the switch. Ports enable you to create a virtual NIC based connection from a VM to a Virtual Switch. Figure 6 shows the configuration of the ports on the General tab of the Virtual Switches properties.

Figure 6: Configuring the amount of Available Ports

If you need to, you can always click on the Add… link on the Configuration tab in the service console – this way you can invoke the Add Network Wizard as seen in Figure 7. You can add either a VM connection, a new VMKernel or a Service Console connection.

Figure 7: Using the Add Network Wizard

If you choose to add a VM based network, in Figure 8 you can select which physical NIC you would like to connect to and in the preview pane you can start to see your network map being build.

Figure 8: Starting to create a Network

Summary

In this article we discussed the components of VMware based physical and logical networking. As mentioned, the Virtual Switch is not difficult to configure if you know what your options are. Make sure you explore the VirtualCenter virtual networking options and learn how to configure the virtual aspects of NICs, switches and then in future articles we will also look at Teaming.

The Art of Patching your Virtual Infrastructure (Part 1)

2009-09-18T15:24:00.002+05:30

Introduction

Updating systems is an essential step in an enterprise environment. Today's environments demand that the solution to managing patches be an automated controlled process. It is thus vital to have a patch management system (such as Microsoft’s Windows Server Update Services aka WSUS or VMware’s Update Manager) so the updates can be rolled out in batch to a (select) group of systems in your environment.

In part 1, we will discuss the old school way of patching an ESX host, but also look at VMware’s own Update Manager (introduced in VI 2.5) to baseline and patch your ESX hosts.

Patching the ESX host the old way

Before Update Manager was available, a plethora of tools were used to patch an ESX host. The most basic tool used is the built-in command esxupdate. We will not go in to details on how to use it. Suffice to say that it needs a tarred patch (called ESX-1002969.tgz or similar) to work and you need to execute it on the Service Console command prompt once the host is put into maintenance mode.

Because this is a rather manual process there were (and still are) a number of community tools freely available such as:

VMTSPatchManager
ESX-autopatch
My own autopatching method using an IIS repository

Next to these more complex patching systems, it is also possible to write a (simple) bash script to run and update your system such as the one below:

#!/bin/bash
# esxAllPatches.sh -- auto unpack and update esx 3.0.2
# by Vincent Vlieghe
# Version 14/01/2008
mkdir /var/updates
function installPatch
{
tar -xvzf /tmp/ESX-$1.tgz
mv /tmp/ESX-$1 /var/updates
esxupdate -n -r file:/var/updates/ESX-$1 update
rm -rf /var/updates/ESX-$1
rm /tmp/ESX-$1.tgz
}
# Patches 15/11/07
installPatch 1002424
installPatch 1002425
installPatch 1002429
# Patches 30/11/07
installPatch 1002431
installPatch 1002435
installPatch 1002434
installPatch 1002426
installPatch 1002430
installPatch 1002428

#remove remaining entries & directories

rm -rf /var/updates
reboot

Update manager: what is it?

VMware’s Update Manager is used to create baselines and install software patches/upgrades for ESX hosts and Windows and Linux virtual machines running on them. It is a simple (Jetty) web server service and a download client. The update manager component is installed on a Windows 2003 or Windows XP machine that has access to the internet. It uses port 80 (443) to connect to the VMware (ESX) or Shavlik (guest) to obtain patch metadata.

Figure 1: Update Manager architecture as per the Update Manager manual

All configuration data (next to some options in the HK Local Machine registry hive) is saved in a file called vci-integrity.xml located under \Program Files\VMware\Infrastructure\Update Manager. Make sure you use the VI Client plug-in for Update Manager (as discussed later in the article) to change the global configuration settings!

Update Manager: installation and configuration

Ok, let’s look at the installation steps. The first thing to note is that it needs a separate database to function. You have only a few options: SQL Express, SQL Server or Oracle. You could use a SQL Express edition that comes with the installation package, but we suggest avoiding this in a production environment. As a first step you should ask your DBA to create a new database, install the SQL Native client for SQL Server 2005 on the Update Manager server and then create a data source name (DSN) pointing to the SQL database created.

The Update Manager component can be installed on the VirtualCenter server itself or on a separate server. We would suggest the second scenario: you install the Update Manager component on a separate server in a separate domain (DMZ maybe) and connect to the VirtualCenter server. There must be 18Gb+ of free storage or the installer will complain. During installation, select Custom and check VMware Update Manager (figure 2 below)

Note:
To determine the disk and database size needed for your environment, make sure to use the VMware update Manager Sizing Estimator.

Figure 2: Components selection window

The next window is an important one: the credentials are used to connect to VirtualCenter itself and register the extensions used by Update Manager.

Figure 3: Link Update Manager to your VirtualCenter host

Another important step in the installation procedure is determining what ports to use for the Update Manager. If the default settings are kept during the installation, the Update Manager Web server listens on 9084 TCP and the Update Manager SOAP server listens on 8084 TCP. Both are accessed through a reverse proxy that listens on the standard ports 80 (and 443). If you have IIS installed for example (let’s say you combine WSUS and VMware update Manager on the same server), you must change port 80 to something else.

It is also possible to configure the Proxy server and port. The strange thing is that when using the Update Manager plug-in in the Vi Client you can use authentication (fill out a username/password)… Why is it not present in this window?

Figure 4: Port and proxy settings window

As a final step you must configure the location for downloading all patches. We suggest putting all patches on a separate (large enough!) partition.

Note: If you want to change your patches download location after installing Update Manager, refer to the following KB article.

Once the installation finishes, launch your Vi Client, go to Plugins => Manage plugins and click the Download and install… button. After restarting Vi Client, go back to Plugins => Manage plugins and enable the VUM client. Once you click this button, a connection will be established to you Update Manager Server.

Note: If you get an error downloading and installing the VUM client, go to \updateManager\VMware-UMClient.exe on the VirtualCenter media and install it manually

Figure 5: Plug-in manager

A new icon will appear in you VI Client toolbar, called Update Manager

Figure 6: Update Manager in the Vi Client toolbar

Once this is done, you will notice a number of extra Update Manager tabs in the VI Client (for hosts and guests).

Using Update Manager

Update Manager is rather simple to use. You need to create 1 or more baselines, attach these to your ESX hosts, Scan the ESX host and remediate it when not compliant.

Let’s start with creating a baseline for our ESX hosts. Click the Update Manager icon. On the Baselines tab right-click an empty space and select New baseline… Note that you have to specify a baseline target: ESX server itself or VM updates. In this article, we will focus on patching ESX hosts so we select ESX server updates.

Figure 7: Creating a baseline

As you can see on Figure 8 you get a number of options based on product type, severity, language and update vendor. Note the Released date field. ESX update releases are cumulative. A new update release contains all fixes from the previous update release. The after field should thus be set to the release date of the latest version: when you apply ESX 3.5 U2 you should set the after date to the date it was released.

So in our example we select 13 August because that is the release date of ESX 3.5 U2. If you don’t set the after date, Update Manager will show that Update 1 is not present and so the ESX host is NOT compliant. This is a known issue.

Figure 8: Selecting baseline options

The next step is to actually use the baseline: left-click on an ESX host in the VI Client and on the Update Manager tab attach the baseline.

Figure 9: Attaching a specific baseline to an ESX host

Once connected, right-click the ESX host you want to patch and select Scan for Updates in the menu. The scan will complete and will state if it is compliant or not.

Figure 10: Compliant or not, that is the question

Now, right-click the ESX host you want to patch and select Remediate… in the menu. Sit back and relax as the machine is put into maintenance mode and patched (and hope nothing goes wrong during the process…)

What about VirtualCenter and VCB?

Yes, a good question: Upgrading/updating your ESX host is usually not the only thing on your task list. The first step in a large scale upgrade project (such as 3.0 to 3.5 or 3.5 to 4.0) is upgrading the VirtualCenter and the VMware Consolidated Backup (VCB) to the latest version. This is (of course) a manual process. We suggest testing, testing and testing in a design environment.

Conclusion

In part 1 of this article series, we described how to install and use Update Manager, a feature set introduced in VI 2.5. Using update Manager is far easier then running custom scripts or using community tools. The great thing about it is… it works quite well. Stay tuned for our next article on patching virtual machines and other extra tools!

Performing a P2V conversion to VMware ESX Server using VMware Converter Enterprise

2009-09-18T14:33:00.002+05:30

Introduction

The single most popular use for virtualization, by far, is to consolidate physical servers to virtual servers. Absolutely, the easiest way to do this is to perform a physical to virtual (P2V) conversion. With a P2V conversion, you use either an imaging application or a dedicated P2V conversion application to take all data on a physical computer, move that data to the virtualized infrastructure, modify the drivers on the transferred operating system, and boot that converted virtual machine - now virtualized.

Besides performing a P2V conversion, you may also have some VMs that are virtualized on another vendor's virtualization platform. When you convert these virtual machines into your new virtualized infrastructure, this is called a virtual to virtual (V2V) conversion.

What is VMware Converter?

VMware Converter is VMware’s solution for P2V and V2V conversions. “Converter”, as they call it, comes in two different versions – Starter and Enterprise. The starter edition is free and available to everyone whereas the enterprise edition is only available to those who have Virtual Center management servers. Still, even the enterprise edition has no additional cost.

The starter edition is meant for “one off” conversions, backups, or clones of one or a few servers. With the starter edition, you can perform hot cloning, local conversions, and remote conversions to non-ESX VMware virtualization applications (Server, Workstation, or Player). A hot conversion is where you can convert a running physical machine to a virtual machine.

The enterprise edition does all that the starter edition does but it allows you to perform multiple simultaneous conversion, cold conversions using a boot CD, and it allows you to convert to ESX Server as well.

As we will be performing a hot conversion to VMware ESX Server today, I will be demonstrating VMware ESX Server Converter Enterprise in this article.

Where do I obtain VMware Converter Enterprise?

To use VMware Converter Enterprise, you first need to obtain a copy. There are really two ways to do this.

Install the VMware Converter Enterprise Plugin – built into VMware’s VI Client 3.5 is the VMware Converter Enterprise Plugin.
Download and Install the VMware Converter Enterprise standalone edition – you can download from VMware’s website, the standalone edition of VMware Converter Enterprise (see the VMware Converter 3.0.3 release notes for more information).

While either of these will perform your P2V conversions for you, I preferred the edition of VMware Converter that was already built in to my VI client and installable directly from there.

Installing the VMware Converter Enterprise Plugin

Downloading and installing the VMware Converter Enterprise plugin is much easier than downloading an installable application. To download and install the VMware Converter Enterprise plugin, open your VMware Infrastructure client (VI Client), go to Plugins on the toolbar and click Manage Plugins. From there, the window shown in Figure 1 will appear.

Figure 1: VI Client Plugin Manager

Just click Download and Install under VMware Converter Enterprise.

In a few seconds, you will be asked for your setup language and, what appears to be a regular application installation commences. Here are screenshots from that installation:

Figure 2: Converter Installation

After clicking install, you can monitor the program installation:

Figure 3: Converter Installation Progress

The installation only takes a few seconds. When done, you will be back at the plugin manager and you will see that the VMware Converter is installed.

Figure 4: Converter Plugin is installed

At this point, we are directed to the installed tab to enable the new plugin. I clicked on the installed tab, and found the Converter Enterprise client and clicked Enabled.

Figure 5: VMware Converter Enterprise Plugin Enabled

So how do we use the new plugin? Let’s find out.

Using the VMware Converter Enterprise Plugin

Once enabled, you will find that if you right-click on an ESX host system in the VI client, there will be a new option – Import Machine. This option is the result of the newly installed and enabled VMware Converter Enterprise.

Let’s say that we want to perform a P2V conversion of a Windows XP workstation into the VMware ESX Server Infrastructure. To do this, we would select the ESX Server that we want to import this new virtual machine to, right-click on the ESX host, and click import machine.

Figure 6: Importing a Virtual Machine with VMware Converter Enterprise

At this point, the 4 step import wizard will start.

Figure 7: VMware Converter Import Wizard

You will be asked what the source of your import is. In our case we will import from a physical computer. However, we could also import from another VMware ESX Server, VMware Workstation, VMware Fusion, VMware Server, a VMware Consolidated Backup (VCB) image, or other third party virtual machine or backup.

Figure 8: Source of system being converted

Next, you will be asked for the physical computer hostname and administrative credentials.

Figure 9: Physical computer hostname and administrative credentials

At this point, VMware Converter will connect to the physical computer and, very likely, as you if the VMware Converter Agent can be installed on that system.

Figure 10: Remote Installation of VMware Converter Agent Required

You will need to click YES to continue.

The agent will be installed on the physical system, information about the disk volumes on the physical host will be retrieved, and you will be asked to review it.

Figure 11: Reviewing disk information from physical computer

I chose to take the defaults an import the “C” drive from the physical host, ignoring the hibernation and page files.

Next , you will be shown the destination for the converted host system. As I originally selected “ESX4”, that was our destination.

Figure 12: Destination of the newly converted virtual machine

You will be asked for the name of the new VM and where you want it located in the virtual machine inventory. I named this test machine “WIN-XP-1-P2V”.

Figure 13: Virtual Machine name

Next, you will be asked what datastore you want to store the new virtual guest in and what virtual NIC cards you want connected to the new virtual machine (shown in Figure 14).

Figure 14: Selecting the virtual NIC cards to be connected to the converted VM

Then, you will be asked if you want to customize the new VM. I chose to install the VMware Tools and remove all Windows system restore checkpoints (in Figure 15).

Figure 15: Customizing the imported virtual machine

You will be given the option to schedule the P2V conversion (in Figure 16).

Figure 16: Ability to schedule the P2V Conversion

And finally, you will see the “ready to complete” (are you sure?) screen (in Figure 17). In this screen, you can choose to power on the VM after it is created.

Figure 17: Ready to complete screen with power on option

After you click Finish, the P2V conversion (import) will begin. You will see its progress in the Recent Tasks window.

Figure 18: Checking the progress of the P2V conversion

After some time (depending on the size of your physical computer hard drive that is being imported), the new VM will be created and available. Notice in Figure 19 the new “WINXP-1-P2V” VM that was created and how I successfully powered it on in Figure 20.

Figure 19: After P2V Conversion

Figure 20: Successfully powered on VM created from VMware Converter Enterprise

A couple of things to watch out for:

Uninstall as many drivers as possible from the physical computer that will be converted
Make sure that your guest OS can reach fully qualified domain names on the network and that you are referring to it using FQDN
Delete at much data on the physical computer as possible and use the option to transfer only the smallest amount of hard drive data as is required
If cloning an already virtualized system, reinstalling your application, and just copying the data is not too difficult, then that is preferred to a full P2V conversion as you will end up with a “cleaner” VM (with less garbage from the previous OS installation, applications, and drivers)

Conclusion

In this article, you learned what VMware Converter Enterprise is and, step by step, how to use it to perform a conversion to VMware ESX Server. Server consolidation through P2V and reinstallation is, by far, the most popular use for server virtualization. Using a P2V converter tool is going to make that server consolidation much easier and if you are moving to VMware virtualization, VMware’s converter, in my opinion, is the best way to go.

How to access the VMware ESXi hidden console

2009-09-18T14:17:00.001+05:30

Introduction

With the full version of VMware ESXi Server, that has been available for years, there is a special “virtual machine” that runs a modified version of Red Hat Linux Enterprise. That special VM is called the service console and is used to administer the ESX host system.

With the free VMware ESXi Server, that service console has been removed. There are many benefits to this – less overhead, fewer patches, and greater security. With ESXi, the “console” is a simple yellow and black menu driven text interface with only the most basic options. However, ESXi actually has an extremely thin linux-based console that can be accessed.

Officially, VMware says that you should administer your ESXi server using either the GUI VI Client or the CLI VMware RCLI. Thus, if you want to perform commands and scripting on your ESXi server, you need to install the remote command line interface on your Windows PC.

However, there is another CLI interface for ESXi that can be used to run commands directly on the server. This is in contrast to RCLI where the command is run on your local management PC and connects to the ESXi host over the network. The difference is that with RCLI, you cannot, say, edit a remote file as you could do if you were using the traditional ESX Server service console.

Thus, the only way to edit a file like /etc/hosts or /etc/inetd.conf is to access this hidden & unsupported thin linux interface and edit these files with vi. Also, with the ESXi hidden console, you can run commands like esxtop, esxcfg-route, and vmkfstools.

How do I access the VMware ESXi hidden Console?

Accessing the hidden & unsupported ESXi console is not difficult if you know how to do it. However, if you do not know how to do it, there is no menu option or easily accessed help file that tells you how to access it.

To access the hidden & unsupported ESXi console, you must go to the console of the server. You cannot access this console via RCLI, RDP, the VI client, or other method. The only way to access the ESXi console is to go to the console of the server.

Figure 1: ESXi Console

Once you are on the server’s console, press Alt-F1.

Figure 2: After pressing Alt-F1

At that point you will see a console log of what has happened on the server but there is no prompt and no help file available. If you type something, it will not appear on the screen.

What you need to do is to type the command unsupported and press enter. Again, this will not appear on the screen. When you do this, here is what you will see:

Figure 3: After typing “unsupported” in ESXi

This activated what VMware called “Tech Support Mode”. As the warning says, this is unsupported unless you are using it with help from VMware Tech Support. Because of this, neither VMware nor I can make any warranties if, by using this interface, something unexpected happens to your ESXi Server. Because of that, you should only do this on a TEST system.

Now, type your ESXi Server root password.

Figure 4: Successfully logged into the hidden ESXi Server console

At this point, you are successfully logged into the hidden ESXi console. So what can do you once you are in here? Let’s find out…

What can I do inside the VMware ESXi hidden console?

The ESXi hidden / unsupported console is a “Linux-like” interface but extremely light when compared to a real Linux installation. For example, some of the most basic Linux commands work like ls (to list files), cd (to change directories), rm (to remove files), cp (to copy files), vi (to edit files), and reboot.

However, other common Linux commands do not work, such as more, pg, nano, or man.

The most interesting configuration files are located in /etc, just like in Linux. The most useful commands that you can execute are located in /sbin.

In this article, I am offering a quick overview of the ESXi command line but for a more complete reference you should read chapter 2 of the VMware Remote Command-Line Interface Installation and Reference Guide because that covers the vicfg-xxxx commands in detail. However, inside the ESXi console, you run most of those same vicfg-xxxx commands but they start with esxcfg-xxxx instead (the deprecated version). In fact, the RCLI Reference Guide (link above) has a chart that shows the esxcfg-xxxx to vicfg-xxxx equivalent command syntax.

In my opinion, the most important thing that I have used the hidden/unsupported ESXi console for is to edit text configuration files on the ESXi Server. This is important because, as I said, this cannot be done using the RCLI. For example, here are a few of the text files I have edited:

/etc/hosts – due to issues related to ESXi servers coming and going randomly from my VMHA resource pool, a VMware Tech had me edit the /etc/hosts file to statically make host entries for the other ESXi hosts in the RP. This was done to rule out any DNS issues.
/etc/inetd.conf – this file can be used to enable services that, otherwise could not be enabled. For example, by removing the hash (#) mark before the ssh or the ftp, I can enable these services on my ESXi server.

Here is an example of editing the inetd.conf file to enable SSH:

Figure 5: Editing the inetd.conf file to enable SSH

Of course, there are other files that can be edited or viewed, like the passwd file or inittab.

Again, I offer the warning that all of this is unsupported by VMware unless you are performing these steps under their direction.

Conclusion

In this article, I covered the "hidden" & unsupported VMware ESXi Server console. Almost everyone knows that ESXi doesn't have a service console but it does have a hidden console. In this article, I also demonstrated the benefit of using this hidden console. Primarily, that benefit is that you can edit text files directly on the server to allow you to enable services like SSH. However, as you have access to the server’s console, and can do much more than you could in the simple console menu interface, the possibilities of tweaking and configuration are only limited by the limited command set on the server.

New VMware ESXi Server - Configuration Checklist

2009-09-18T12:27:00.003+05:30

Introduction

In this article, VMware ESX Video author, I will provide a step by step configuration checklist for the proper planning, installation, configuration, and security of a new ESXi Server. While installing ESXi is not difficult, installing it properly is.

Let us begin

One of the best things about VMware ESXi (besides being free) is that it is quick and easy to install. However, there is more to properly configuring it than just getting it installed. Not only do you want it installed but you also want it configured to function for all your future needs and to do so securely. Let us see how to do just that.

VMware ESXi New Server Checklist

I will break this new VMware ESXi Server Installation Checklist into 3 phases:

Installation
Console Configuration
VI Client Configuration

Let us get started with the Installation phase…

Installing VMware ESXi Server

Verify that your hardware is compatible with VMware ESXi. Use the VMware HCL (hardware compatibility list).
If you do not have it already, you will need to download an evaluation copy (or purchase a copy) of VMware ESXi. Fortunately it is free and not too terribly large to download. You can download it at the VMware ESXi Server free download site.
Prior to the ESXi Installation, you should review your server BIOS settings. You will want to enable VT if you want to have 64 bit guests and disable BIOS controller power management. As with the installation of any operating system, you want to make sure that the boot order is going to allow you to boot from the ESXi installation media.
Insert your installation media and boot up ESXi. In my case, I performed the Installation inside VMware Workstation using my video instructions on Installing VMware ESXi inside VMware Workstation which allowed me to get these installation snapshots.
Typically, you will take all the defaults in the installation. Here are some sample screen shots with comments of what to do at each port, below them in the comments:

Figure 1: ESXi Installation

Figure 2:  Press Enter to begin Installation

Figure 3:  Press Enter to Accept the default hard drive for install

Figure 4: Press F11 to Install ESXi

Figure 5: Press Enter to

VMWare ESXi Console Configuration

Once ESXi has successfully installed and rebooted, we have a list of tasks to perform at the console level to properly configure it. This “ESXi Console” as I call it is technically called the Direct console user interface (DCUI) but for the purposes of this article, let us just call it the “ESXi Console”.

Press F2 to customize the ESXi Server using the console (below).

Figure 6: Once booted, press F2 to Customize

Going down the list from the top to bottom of the console interface, here is our list of what we need to configure at the console level:

Configure the root password

Figure 7: Configuring the root password on a VMware ESXi Server

Configure Management Network – the networking for the ESXi Server is called the “management network” so in this step, you need to configure the IP address, subnet mask, and default gateway. While your server will likely start out with an IP address obtained from DHCP, as this is a server, you need to configure a static IP address.

Figure 8:  configuring the static IP Management in ESXi

Configure DNS Servers on this ESXi Server – Just as you tell your PC what DNS Servers to use and what the domain is that it should use, you also need to tell your ESXi Server. Go into DNS Settings inside DNS Configuration to give this server the DNS Server IP’s and its hostname.

Figure 9: Assigning DNS Server Installation for ESXi Server

Next, you need to add a Custom DNS Suffixes to assign the DNS Suffix for this ESXi server.

Figure 10: Assigning a Custom DNS Suffix

Now, Exit the Management Network Configuration by pressing ESC. You will be prompted to confirm that you want to save this new configuration. Make sure that you accept the new configuration with a Y for YES.

Figure 11:  Accepting Changes to the Management Network

To ensure that this server is properly configured, you should use theTest Management Network function in the console, like this:

Figure 12: Testing the Management Network

What is this? Our Management Network Test failed? This points out that we need to make sure that this ESX host is able to resolve DNS and above to resolve its own DNS hostname. Now, let us add it.

To resolve the fact that this ESX host is not in DNS, go to your DNS Server and make a host entry for the new ESX host, like this:

Figure 13:  Adding a Windows DNS Server host entry for the new ESXi host

From here, we are done with the console configuration so let us move onto administering the new server using VMware’s VI Client.

VI Client Configuration

Connect to your vCenter Server and add the new ESXi server to vCenter. Authorize as the root user and I recommend enabling lock down mode at this time.

Figure 14:  Adding the new ESXi Host

Configure Licensing – if you have the vCenter Server licensing configured to “change host license server settings to match these VirtualCenter Server settings whenever a host is added to the inventory” then the new ESXi Server licensing should be automatically configured. Still, you should check your licensing for the new server and verify that it is properly licensed (not an evaluation) and that any optional features you need (like VCB or VMotion) are enabled.

Figure 15:  Checking Licensing for an ESX host

Connect ESXi Server to SAN – iSCSI or FC. For more information on ESX Server and iSCSI, see my articles How to create an inexpensive iSCSI SAN for VMware ESX and Connect VMware ESX Server to a free iSCSI SAN using Openfiler.
Configure NTP Server & Start NTP – it is important to have the proper time configured on your ESXi Servers for a variety of reasons (logging, security, iSCSI authentication) and NTP is the correct way to do this. To enable NTP, go to the Configuration for your server, click on Time Configuration, and then click Properties.

Figure 16

Add a new NTP Server such as pool.ntp.org

Figure 17

Then set NTP to Start Automatically and then Start NTP.

Consider Security - while ESXi is a very secure OS already (even more secure than the regular ESX Server), I encourage you to consider the security implications of it. Here are a couple of things you can do-a. Read the VMware VI Security Hardening Guide and consider what it recommends. This guide was recently updated to cover ESXi (ESX 3i 3.5).b. Get on the update list to be notified when the new version of TripWire ConfigCheck will be released which will support ESXi (3i). This is a very powerful tool and I highly recommend it but, so far, it only supports ESX Server (not ESXi). They have an email notification list you can joint to be notified when the new ESXi version is released.
Consider Documentation & Communication – these are two areas that are too often forgotten. When adding any new server, you need to update your documentation, hardware inventory, network management, and more. You also need to notified other administrators that the new server is available and how to administer it.
If you will be wantig to gain access to the command line on your ESXi server, read my article How to Access the VMware ESXi Hidden Console
Configure options features, such as vMotion, VCB, and/or other backup solutions.

Conclusion

In conclusion, adding a new VMware ESXi Server should be quick and easy. However, there are often many parts of adding that new server that are forgotten until later. By having a quick checklist for installation and configuration, adding that new server can be easier and you will save time in the long run.

Maintaining VMware: Three Common Virtual Machine Tasks

2009-09-17T16:39:00.001+05:30

Introduction

The line between PCs and VMs is beginning to blur – only seemingly separated by how physical components are arranged and utilized. Much of the same maintenance tasks you would do on a PC now apply to a VM. For example, you still need to install software and deploy desktops. So, how is this done virtually? In this article, we will look at some common administrative tasks you will perform as a VM administrator.

Making new Virtual Machines Quickly

The VMware VirtualCenter (or VC for short), is used for centralized configuration and management of your VM infrastructure. Many times, as an administrator you are asked to ‘build a new VM’. What this means is that someone is asking you to create a new system for them to utilize. To the person who will use this system, it's transparent as to how it's deployed to them – let us take a closer look at what happens behind the scenes.

Clones, Templates and ISOs are an administrators savior when working with VMware. To those who have spent years installing software such as applications and operating systems on bare metal hardware, this could not be any easier. For those using Symantec Ghost, Sysprep or any other form of cloning software, you will find this even easier. You no longer need to image a system with VMware.

Now, you can use ISO’s to set up your initial VM. By mapping an ISO image to your newly minted VM, you can pull just about any operating system imaginable into your VM inventory. Yes, you have to still be weary of 32 vs 64 bit operating systems and the fact that some OS’s still have issues during installation, but it could not get any easier. Once you have mapped and set up your VM, you can easily ‘duplicate’ it for further rollouts. For example, if you have a need for 30 Windows Vista Ultimate VMs, you could create one of them and then create a template out of it and use it for cloning purposes.

When cloning, you can easiely deploy a new VM from a template via ‘Virtual Machines and Templates’ as seen in figure 1.

Figure 1

Once you have a completed set of templates (for Linux, Windows or other) you can then deploy whichever you need quickly and easily.

Keeping your Virtual Machines Secure and Healthy

When working on your new VMs, you will have the same exact configuration settings to make a desktop system. Hotfixes, Service Packs, and updates need to be downloaded and installed. You will still have to customize your systems and set up networking, domain connections and other advanced configuations. Figure 2 shows Windows Vista being updated via ‘Windows Update’ in the VC console.

Figure 2

Next, it is wise to configure your firewall, automatic updates, spyware protection and UAC (for example). Make sure you also intsall Antivirus software!

Figure 3

As you can see, from defragging your hard disk to retooling your security, it is important that when working with a VM, you follow the same steps you would with any system. These are often forgotten about because new administrators sometimes tend to think that since VMs are contained within VMware, then there is some confusion as to how they are accessed or secured, such as using Remote Desktop for remote administration of your VM. Make sure you check your VirtualCenter logs and reports for issues on how VMs are operating within the ESX enviroment and then use Vista’s performance statistics. By checking both, you will know if you are running out of resources too quickly.

Using VMware Tools

To create the ultimate experience, install VMware Tools on top of your new VMs. This will help you work with the VM while using the VC. Figure 4 shows VMware tools properties which can be invoked from the System Tray (systray) icon. Here you can configure many options which will give you a better experience when working in the VC.

Figure 4

In the figure you will be able to see that you can configure specific options, such as, how time synchronization is performed on the client VM as well as which devices should be connected. You can enable or disable removable devices in the Devices tab. When synchronizing the time, you should specify whether you want the guest OS (VM) to keep the same time as the VirtualCenter.

Figure 5

You can also select which removable devices can be connected when starting the VM. In Figure 6, the IDE (hard disk), and NIC are selected.

Figure 6

Custom scripts may also be used in this case. You can write a script and invoke it here, which can be used to run commands, map drives and so on. These are used to map specific power states. A default script for each power state and is included in VMware Tools. These scripts are located in the guest operating system in C:\Program Files\VMware.

For example, if you wanted to suspend the guest operating system via a script, you can use the suspend-vm-default.bat file.

Next, if you want to shrink your virtual disks with VMware Tools, you can use the Shrink tab. The Shrink tab lets you prepare to export a virtual disk to another system using the smallest disk file size. Use the shrink option to save space that will be eaten up by your VM files.

Figure 7

Laslty, the About tab basically gives you some info on the product, as well as to alert you to the fact that the service is running. Here you can also find the VMware Tools build number. This helps you verify your VMware Tools version in use.

Summary

In this article we reviewed some of the most basic configuration steps you will take when working with a new VM. You should be familiar with updating systems, doing performance maintenance and intsalling and configure VMware Tools.

Understanding and Customizing VMware ESX Server Performance Charts

2009-09-17T16:20:00.001+05:30

Why do you need VMware Performance charts?

As a VMware Administrator you must know what is going on in your virtual infrastructure. When things are not going as planned, you need to troubleshoot it. Performance charts are key in being able to troubleshoot performance issues in your virtual infrastructure. Thus, you need performance charts to:

Have a informal baseline of what your utilization is today, in a visual form
Troubleshoot performance issues when you have performance issues
Optimize your virtual infrastructure performance to keep performance as good as it can be and to make the right decisions in the future

What do VMware’s Virtual Infrastructure Performance Charts offer you?

Whether you use VMware’s ESXi server only (just one server) or if you have the Enterprise Virtual Infrastructure Suite (with vCenter and 100 ESX Server), VMware’s Performance charts are available to you and offer you many features.

With the standalone ESXi edition you will only have charts at the host and guest level. On the other hand, with vCenter, you will have performance charts available at the cluster level (if you have created a VMHA or DRS cluster).

Depending on the level of the chart that you are using, you will be offered different information. For example, on a guest you can graph CPU, memory, disk, network, and system. On an ESX host, you will have those plus “management agent”. On a cluster, you will only see CPU and memory. Keep in mind that when I say “CPU” there are many CPU-related performance settings under CPU. For example you can access average CPU usage, CPU used, CPU guaranteed, CPU extra, CPU ready, CPU system, and CPU wait. Other performance categories such as memory, network, and disk will each have their own performance criteria that you can manually add to your graph.

Figure 1: Sample VMware ESX Performance Chart

By clicking Change Chart Options, charts can be created for real-time information, past day, week, month, year, or a custom timeframe. Here is what that window looks like:

Figure 2: Changing your VMware ESX Performance Chart Options

Custom charts can be saved so that you can pull them up quickly when needed. Charts can also be saved as graphics or printed. To give your chart more screen space, you can choose to have the chart “popup” on its own window (get it out of the VI client window). This is certainly something you want to do if you are going to look at a graph for more than a few seconds. Here is what a “popup” chart looks like:

Figure 3: VMware ESX PopUp Performance Chart

To me, the most important thing about using the standard VMware ESX Performance charts is 1) knowing what level to go to look for something (cluster, host, or guest) and 2) knowing what statistic to look for (CPU, memory, disk, network, or other).

Just like using any other troubleshooting tool, your success and efficient use of it comes from your experience in troubleshooting performance issues and your knowledge of your environment and applications. For example, where do you start? I would start on the cluster (if you have one), then to the ESX host, then to the guest that is causing trouble. At each of these levels, I would look at CPU, memory, disk, and network.

After using the standard performance charts for a while, it is likely that you will want to customize them pretty quickly to find out just what you need to know. Let us find out how to do that.

How do you customize VMware ESX Performance Charts?

As you saw in Figure 2, above, it is easy to customize your performance charts and even save those customizations. Let me give you an example. Say that I wanted to create a custom chart for my ESX host (and even a group of ESX hosts) that shows CPU performance for the last month. To do this, I would go to the ESX server in the VI client and click on the Performance tab. From there, click on Change Chart Options. I would go to the CPU section and click on Past Month. To save your new chart, click on Save Chart Settings. Here is what it looks like:

Figure 4: Savings a VMware ESX Custom Performance Chart

By doing this, the next time you come into the performance chart, you can click Change Chart Options and load this saved chart by selecting it under Saved Chart Settings.

Figure 5: Loading a VMware ESX Saved Performance Chart

In fact, if you want this saved chart to load every time you bring up this graph, you can check the checkbox that says Always Load these Settings at Startup.

So as you found out, customizing VMware ESX Performance charts is easy but what if the VI Client and vCenter just don’t offer you enough performance information.

How do you get more VMware ESX Performance information?

If you need more performance information and more intelligent performance solutions, I can make a few recommendations:

vKernel – specializing in performance appliances for VMware. When it comes to VMware performance, the most useful tool, in my opinion, is vKernel’s performance modeling tool, Modeler. With Modeler, you can find out all the “what if” answers to the performance questions, before you make performance changes. Read about it in an article by Gabrie Van Zanten at How to Model and Predict Changes to your VMware ESX Infrastructure using vKernel Modeler
Veeam Monitor – recently announced in a free edition, Veeam Monitor is a powerful performance monitoring application. Read about it in my article The benefits of VMware ESX performance monitoring with Veeam Monitor free edition
Solarwinds VM Monitor – I wrote an article about this free tool that uses SNMP to give you a quick dashboard view of your ESX Server and guest VM performance. Note: only works with ESX Server, not ESXi.
Akorri BalancePoint – a comprehensive performance management application that even interfaces with your storage area network (SAN)

Conclusion

In conclusion, VMware ESX performance charts are very powerful but also are limited to their core functionality. With the built-in performance charts you can view VMware ESX host, guest, and cluster performance, create & save custom charts, and view performance on so many different performance objects. I hope you will spend a little more time using VMware ESX Performance Charts with the help of this article.

How can the free vWire OpsCheck help with your VMotion Configuration?

2009-09-17T15:58:00.001+05:30

Introduction

VMware’s VMotion is one of the core features of the Virtual Infrastructure Enterprise suite. VMotion will move your virtual guest machines from one ESX Server to another without the VM guest ever suffering any downtime. VMotion is used with Distributed Resource Scheduler (DRS) to balance the load of the VM Guests across the virtual infrastructure.

While VMotion is not too difficult to configure, you do want that critical piece to work and work the first time. Plus, you want its configuration to be optimized according to VMware’s best practices. This is the power of OpsCheck. And, better yet, OpsCheck is free from TripWire.

Where do I get OpsCheck?

TripWire has created a new community called vWire. At the vWire community, you can download two free VMware tools (there are more on the way) and visit their virtualization community (as a side note, you can even get a free tshirt if you refer a friend). The two free VMware tools that are offered are ConfigCheck and OpsCheck. ConfigCheck is a VMware security assessment tool (you can learn more about it in my article Assessing VMware ESX server security with TripWire ConfigCheck). OpsCheck, on the other hand, is the VMotion verification and best practice analysis tool.

Downloading OpsCheck is quick and easy. It is a very small tool of only 7.5MB. There is no installation. In fact, OpsCheck is really a Windows command script that calls and executable Java JAR file. I downloaded OpsCheck and unzipped the file. I ran the opscheck windows command script.

Figure 1: Running the OpsCheck Windows Command Script

A Windows command window appeared, accepted the end-user license agreement, and TripWire OpsCheck version 1.0.0 appeared.

Figure 2: Logging OpsCheck into your Virtual Infrastructure

In order to use OpsCheck and VMotion, you need to have Virtual Center (vCenter) running. Thus, there is no need to try out OpsCheck if you do not have Virtual Center and vMotion.

To connect OpsCheck to your vCenter server, you need to provide the hostname for vCenter, username, and password. As you see in Figure 2, I did this, then clicked Login and Continue.

You will know when OpsCheck has logged into vCenter because it will show you an inventory of your Clusters and ESX Hosts, as you see in Figure 3.

Figure 3: OpsCheck has listed out my clusters and hosts

From here, all you have to do is to either select 2 or more ESX hosts or a cluster. In my case, I selected ESX hosts 4 and 5 and clicked Check and see results.

OpsCheck quickly analyzed my VMotion configuration and told me that I had 10 incompatibilities between VMs and Hosts (see Figure 4).

Figure 4: OpsCheck has analyzed my VMotion configuration

As shown in Figure 4, OpsCheck reports on:

Host-specific
Incompatibilities between two hosts
VM-specific incompatibilities
Incompatibilities between VM’s and hosts

I clicked on the detailed report of all detected to find out why my VMs and hosts were incompatible. This opened a web browser with the OpsCheck Report, shown in Figure 5, below.

Figure 5: OpsCheck Report Results

The OpsCheck Report showed me that 12 of my VMs were checked and 8 of my VMs were incompatible. Wow – that is 75% of my VM Guests that are not going to work if they were VMotion’ed. I wouldn’t have known this otherwise. Without OpsCheck, I would have tried to do a VMotion or DRS would have used VMotion and that VMotion would have failed. That could have caused downtime for that VM Guest and, perhaps a critical application to end users.

This is the reason that you need OpsCheck, to find out if VMotion is going to work before it doesn’t work and you suffer downtime.

If I click on the Detailed Information for each of these incompatible VMs, I am taken to the vWire OpsCheck Troubleshooting Guidance for VMware VMotion (see Figure 6). This is a great guide that helps you to troubleshoot why VMotion is not going to work. I was taken directly to the reason, in my case, that VMotion was going to fail: Datastore Required by Virtual Machine Not Present on Host.

Figure 6: OpsCheck Troubleshooting Guidance for VMware VMotion

If I go back to the screen shown in Figure 5, the description for the very first incompatibility was: VM VIMA Appliance uses datastore "esx5:storage1" which is available on esx5.wiredbraincoffee.com but not on host esx4.wiredbraincoffee.com.

I went back and looked at this and, sure enough, I had created the VIMA appliance to be stored on the local datastore on ESX5 which would not be available if the VIMA Appliance was VMotion’ed to ESX4. The second line also reported that there was a CPU incompatibility between the two ESX hosts that would prevent VMotion. The OpsCheck Troubleshooting Guide told me this:

With the release of Update 2 for VI3, it is now possible to enable Enhanced vMotion Compatibility (EVC) on clusters to minimize CPU compatibility issues. As a last resort workaround, it is always possible to power off the virtual machine and perform a cold migration. For additional information, please refer to VMware KB Article 1003718 and the VMware vMotion and CPU Compatibility Guide.

CPU Enhanced VMotion Compatibility (EVC) is certainly something I need to configure to really get VMotion working between these two ESX hosts in my lab environment.

Conclusion

In conclusion, the free vWire OpsCheck tool is something that every VMware Admin should run to ensure that VMotion will really work in their VMware ESX DRS cluster or just to ensure that you can VMotion if you choose to. I encourage you to try out OpsCheck on your own VMware Virtual Infrastructure that has VMotion enabled.

Using Roles to Secure your VMware ESX Infrastructure

2009-09-17T15:36:00.002+05:30

Introduction

If you think about it, both Windows and Linux have security roles. In Windows, you might be a print server operator, server administrator, or backup operator. These are some of the built-in roles that Windows calls “built-in groups” (which has been assigned special Windows rights to perform some actions). VMware is no different from these operating systems in the sense that it has its own build in security roles and that you can also create your own security roles. Let us learn more about them.

How does VMware ESX Infrastructure security work?

In VMware ESX & Virtual Infrastructure, security is configured at various levels using permissions. Permissions are the core of VMware infrastructure security. These permissions are a combination of a user/group and a security role that is applied to some level of the VMware Infrastructure.

If you are using VMware ESX or ESXi without vCenter, permissions are assigned at the ESX host and VM guest level. If you are using VMware vCenter, you have additional levels of security that permissions can be applied to.

For example, there is a permission tab, shown in Figure 1 below, at the VM Guest level.

Figure 1: VMware Infrastructure Permissions Tab

Notice in Figure 1, how the permission tab shows the user/group and the roles that form the permission that is applied to this VM Guest. The permissions tab also shows where this permission is defined at.

In the case of the permission tab in Figure 1, this permission is not actually applied at the level of this VM Guest. This permission is applied at the Hosts & Clusters level (the highest level in the VMware Infrastructure Inventory).

But what about roles? That’s what this article is about so let us get on with that…

How do you use Roles to Secure your VMware ESX Infrastructure?

While VMware Infrastructure Security Roles are used in the Inventory section of the VI Client, they are not defined there. Roles are defined by clicking the Administration view, shown below in Figure 2.

VMware Infrastructure Administration view contains:

Roles – what we are covering in this article
Sessions – who is logged into vCenter and the message of the day
Licenses – what licenses are in use, what types, by what servers, and how many remain
System Logs – VMware ESX & vCenter system logs
Figure 2: VI Client Administration view to add a role

On the Roles tab, you will see the currently defined security roles for your VMware Infrastructure. If this is the first time you have been in here, likely these are the default roles. Some of the more important default VMware Infrastructure Roles are:

Read-Only – just what it says, for any object that has the read-only role defined, the security group user associated with it will have only the ability to view (read) the status of that object. For example, perhaps the IT Support Help Desk group should have read-only access to all VMs so that they can check status to see if a VM is up or down.
Administrator – by default, the virtualization omnipotent power role that the administrator user will have across the entire infrastructure. Very likely, you shouldn’t assign the administrator security role to anyone or any group because you need to be more selective. You need to apply the “principle of least privilege” and assign the least amount of privilege required for someone to do their job. For example, if someone just needs access to administer a single virtual guest machine, then they just need the virtual machine administrator role, below.
Virtual Machine Administrator – this is the ideal role to assign to a user or group of users that need to manage a virtual machine (or group of VMs) that are specific to their area. For example, perhaps you have database administrator (DBA) who needs to manage four SQL Server VMs. You could assign that DBA (or the DBA group) the virtual machine administrator role on those VMs. Even better, you could create a folder in your virtual infrastructure, put the SQL servers inside, and assign the DBA group the Virtual Machine Administrator role on the entire folder.
Data Center Administrator – in larger virtual infrastructures you will have multiple virtual datacenters administered by multiple groups of administrators. To properly secure and design this in vCenter, you create virtual data centers, move the appropriate ESX hosts and VM guests into them, and apply the data center administrator role to them, combined with the proper security group for the administrators who will manage that virtual data center.

Again, these are just a few examples of default roles. A couple common examples of how these roles would be assigned are:

Administrator Role could be assigned to the Windows Administrators security group
Read only role could be assigned to a help desk group

While the default roles are very usefully, likely you will want to create custom roles. To add custom roles, click Add Role, select a set of privileges, and give the role a name. Alternatively, you can also clone an existing role and modify it.

Let us add a new SQL Server DBA Support Role by cloning an existing role. To do this, I go to Administration, select the Virtual Machine Administrator Role, and click on Clone Role. A new role is created called Clone of Virtual Machine Administrator. Now, I right-click on this role and click Edit Role. I then rename it and call it SQL Support.

Figure 3: Cloned Security Role

Now that we have our new role, we need to apply it to some VM guests, a folder, or cluster in our virtual infrastructure. In our case, let us say that we have a DRS/HA cluster of SQL Servers called SQL Server Cluster. Back in the Inventory view, I click on my SQL Server Cluster, then on the Permissions tab. On the permissions screen, Iright-click in the white-space area and click Add Permission, as you see in Figure 4.

Figure 4: Adding Permission to the SQL Server Cluster

I now select the new custom role we created, SQL Support and click Add to add a user or group. In my case, I select the SQLServer2005Admin Group that was already created and click OK. We now have our new custom role assigned to the entire cluster. As we close to propagate this permission, this permission also applies down to all the objects in this cluster. However, as we copied the virtual machine administrator role, this group of SQL Admins should only have permission to manage the virtual guest machines in the cluster, not the cluster itself or the ESX servers in the cluster. Here is what it looks like:

Figure 5: Assigning Permissions

Instead of cloning an existing role, you can also create your own role. This is also done by going into the Administration view. From there, just click on Add Role.

As you see in Figure 6, you just give your role a name and check off the privileges you want to assign to it.

Figure 6: Creating a custom role

Here are a couple examples of other ways that custom roles could be used:

Virtual Machine Power Off / On – assigned to an admin for a particular virtual machine application (using the principle of least privilege by assigning only what the user needs vs assigning the virtual machine administrator role)
Console Interaction – this is likely to be combined with the virtual machine power off/on privilege. This privilege allows the user to perform VM guest console remote control.

Conclusion

In this article, we learned what VMware ESX Server security roles are and why you need them. If you think about it VMware ESX Server security roles and permissions are no different than any other operating systems that you are likely already familiar with. I highly recommend you plan and implement security, using ESX roles and permissions, in your virtual infrastructure.

What is VMware vCenter Heartbeat and How will it help you?

2009-09-17T15:26:00.002+05:30

Introduction

VMware’s logic is that vCenter is used to manage so many Tier 1 applications and that makes vCenter, itself, a Tier 1 application. We all know that Tier 1 applications need to be highly available. So, if VMware’s logic is right, then vCenter also needs to be highly available. That is where vCenter Heartbeat steps in.

Of course, this logic is true only if you feel that vCenter is worthy of that Tier 1 application status. At large enterprises they may not have to think about this question at all. These companies may have a large team of virtualization admins who use vCenter around the clock. They may have even opened up access to vCenter to various parts of the business who use it to manage their virtual machines. Obviously, in cases like these, there is more than just an inconvenience to a single admin if vCenter goes down.

However, at other companies who use vCenter, they have to first ponder the question as to what would be lost if vCenter were suddenly not available. I can tell you that the ESX hosts and Guest VMs will continue to work fine. vCenter is not required for ESX functionality but it is required for specific, more advanced, features of virtual infrastructure. For example, VMHA will still function but DRS will not. For the entire list see- What if my VirtualCenter server crashes?

What is vCenter Heartbeat?

So we said that vCenter Heartbeat provides vCenter high availability but what, exactly, does it check and attempt to protect you from?

OS failures on the vCenter server
Hardware failure of the vCenter server
Network failures affecting the vCenter server
Application failures on the vCenter server (like the vCenter services or SQL server failure where the vCenter data is located)

The backup vCenter server will even take over for the primary server if there is significant application performance degradation.

How does it work? vCenter Heartbeat server works by replicating all vCenter configuration and data to the secondary passive server using (hopefully) a dedicated network channel. The secondary server is really up all the time, with the live configuration of the active server, but an IP packet filter is masking it from the active network.

Here is what it looks like:

Figure 1: vCenter Heartbeat Server application (Graphic courtesy of VMworld Europe presentation TA15)

And here is a diagram of how it works:

Figure 2: Graceful transfer of vCenter server from active to passive (Graphic courtesy of VMworld Europe presentation TA15)

VMware’s vCenter Heartbeat was announced at VMworld Europe 2009 and it is already used by over 130,000 customers around the world when announced. How can that be, you ask? No, VMware didn’t come up with this product out of the blue. VMware is really just reselling NeverFail under the name. According to this story at Virtualization.info (VMware kills another ecosystem with vCenter Server Heartbeat 1.0), VMware has an exclusive agreement with NeverFail. That agreement means that VMware will not resell other products from competitors nor can NeverFail sell this product on their own any longer. In the same story, it’s pointed out how this new exclusive agreement effectively kills all competition from a variety of companies who were previously partners with VMware.

vCenter Heartbeat is available for $9995 per vCenter or $12,995 when bundled with vCenter server.

How can vCenter Heartbeat help you?

More specifically, vCenter Heartbeat provides continuous monitoring of vCenter connectivity, databases, and components, license server, and update manager. I was very pleased to see that it does indeed work across a LAN or WAN. Thus, Heartbeat provides offsite replication and availability for vCenter. I also think that it’s great that it has only a small impact on the performance of the virtual infrastructure. Unlike some other clustering solutions, Heartbeat is hardware agnostic so you can use a physical server as a primary server and a virtual server as a secondary server, etc.

We know that if you did run vCenter on a virtual machine, you could partially protect it using VMHA. However, that isn’t going to work over a WAN nor does it help if the SQL data is not on the vCenter server. Plus, VMHA has no application awareness of vCenter and could care less if the services won’t start (for example). That said, according to Virtualization.info, 60% of customers still run vCenter on physical machines.

There are several design configurations for implementing vCenter Heartbeat. For example, you could have physical to physical, physical to virtual, or virtual to virtual.

Initially, to create the secondary server, the primary server is cloned. If the primary is already a virtual server, you can simply clone it using the VI Client. If the primary server is a physical server, you would have to clone it using a P2V conversion tool like VMware Converter.

Keep in mind that Heartbeat does not just protect vCenter but also other VI components installed on the vCenter server such as Update Manager, License Server, Capacity Planner, and VMware Converter Enterprise.

For Oracle users out there, you should know that VMware Heartbeat only works only if you use MS SQL Server as your vCenter Server database. Thing brings up an important point – that the vCenter database does not have to be on the same server as vCenter for Heartbeat to protect vCenter.

10 Basics of Linux that apply to managing VMware ESX through the service console

2009-09-17T15:06:00.002+05:30

How the management of VMware ESX, using the service console OS (COS), is the same as the management of the Linux OS and Linux servers.

Introduction

If you are using the full version of VMware ESX you have the option to manage it, from the command line, using the service console operating system (called the COS). The service console, in VMware ESX, is really a modified version of Red Hat Enterprise Linux. Thus, basic Linux administration knowledge is very valuable when you go to manage VMware ESX from the command line.

On the other hand, if you are using VMware ESXi you likely do not access any CLI console from the server. Two command line options for managing ESXi from the command line are-

The hidden ESXi service console – for information on this tiny Linux console, with very limited features, and how to access it see my article How to access the VMware ESXi Hidden Console.
The VMware remote command line interface (RCLI) – for information on RCLI, see my article; Using VMware’s remote command line interface (RCLI) with VMware ESXi.

Now, here are my 10 basics of Linux administration that apply to managing VMware ESX:

1. Understanding file structure and navigation are critical

Just like navigating Linux or Windows from the command line, it is critical in ESX that you know how to navigate the file structure. Here are some common Linux & ESX commands you will use to get around:

ls - to list out files in a directory, just like the DOS dir command. Although, the DOS dir command actually does work in ESX as well. I prefer the long format of the ls command, ls -l

Figure 1: the ls, dir, and ls - l commands in VMware ESX

cd – change directory
rm – to remove files
cp – to copy files
rename – to rename files
pwd – to show the current directory

One of the best Linux commands I ever learned was the command that allows me to find a file anywhere on a filesystem-
find ./ -print grep {what you are looking for}

Yes, this works great in ESX and it allows me to find the location of log files or executables when they are not in my path or I forget where they are stored. Here is an example of how I used this to find the location of the esxcfg-firewall command:

Figure 2: using the find command

2. Remote access is usually via SSH when using the CLI

Just as I connect to a Linux server using a SSH client like putty, I also connect to my ESX server. In fact, all the command line examples in this article were done with putty through SSH.

You should know that access to the ESX service console is not allowed, via SSH, for root, by default. To enable it, you need to go to the server’s console, edit /etc/ssh/sshd_config, set PermitRootLogin to yes, save it, and restart the ssh dameon with service sshd restart.

3. Local user administration is in /etc/passwd

Just as in Linux, it is best practice in ESX to create yourself a local user that can be used to su to the root account when local root privileges are needed (yes, even if you are using vCenter and likely will not use this a lot).

You could edit the /etc/passwd file, sure, but you should, instead, use useradd to add local users from the command line (but this is also easily done in the VI client if you connect directly to an ESX host). You can change passwords using passwd, just like in Linux.

One thing that is different is that you can set just about all of the ESX authorization settings by using esxcfg-auth.

4. Critical administration commands can be found in

As we learned back in #1 with the find command, the esxcfg-XXXX commands are located in /usr/sbin. These are ESX specific commands that you will need to use if administering the server from CLI.

Here is what they look like:

Figure 3: esxcfg commands located in /usr/sbin

5. Text file editing with vi and nano is a must

How are you going to edit text files like sshd_config to enable SSH remote access without a text editor? Well, you can’t. You must know how to use one of the Linux / ESX text file editors – vi or nano.

Like whiskey, vi is “an acquired taste” and takes some getting used to. If you are a Linux admin, you already know vi. For those who don’t, I encourage you to use nano as it works much like the Windows notepad.

Here is a look at nano:

Figure 4: Using nano to edit text files in VMware ESX

6. You will need to patch it with using RPMs but with different tools – rpm and esxupdate

Just like any OS, you will need to patch ESX. In Linux, this is typically done at the command line using rpm. While rpm is available in ESX, you should instead use esxupdate to apply ESX patches.

Still, the concept is the same and the applications are almost identical.

For more information on using esxupdate and patching in ESX see:

ESX Patch Management Guide
My other article, Using ESXUPDATE to update VMware ESX Server

7. Common network tools like ping, ifconfig, traceroute, proper network configuration are all crucial.

Just as in configuring Linux or even Windows from the command line, critical pieces of ESX Server aren’t going to work without the proper network configuration. The easiest way to do that in ESX is to use the VI client but you can do it at the command line using commands like esxcfg-nics, esxcfg-route, esxcfg-vmknic, esxcfg-vswif.

About half of what these commands do is to edit traditional Linux text configuration files like /etc/hosts, /etc/resolv.conf, /etc/sysconfig/network, /etc/vmware/esx.conf.

Just like any Linux host, in ESX you must have an IP address, proper subnet mask, default gateway (if you want to get outside your subnet), DNS servers (unless you are going local), your ESX host name must be able to be resolved as a FQDN, and you must have full network communication. That full network communication can be tested with traditional Linux commands like ping, traceroute, nslookup, and ifconfig

8. Process administration, at times, is necessary – ps, kill

Just as in Linux, at times, process administration is required. In ESX, you can view running processes with the ps (or process list) command. You can kill processes with the kill command.

Unlike Linux, ESX has some critical processes such as vmware-watchdog, vmware-hostd, vmklogger, and others.

9. Performance management from the CLI is quickly handled with top and esxtop

Eventually in any OS you will have a performance management issue. You can quickly resolve performance issues in Linux with top. In ESX, top also works but you should, instead, use esxtop.

Figure 5: VMware ESXTOP

For more information on understanding performance statistics with esxtop, see the VMware ESX Resource Management Guide and Interpreting ESXTOP Statistics in the VMware Community.

10. Getting help with --help and man

And finally, getting help in Linux and in ESX are the same. To learn more about a command you can use that command and add “dash dash help” or “--help" after it. Even better, you can get more instructions using man, which stands for manual pages. For example, if I wanted to learn about esxcfg-firewall, I can just type man esxcfg-firewall and I see a screen like this:

Figure 6: VMware ESX man pages

Conclusion

Some would say “of course VMware ESX service console and Linux are the same, the ESX service console IS LINUX”. That is not exactly true as it is a modified version of Red Hat Enterprise Linux. Plus, what libraries and packages are loaded in it? What extra commands? What commands are removed? There are many differences. Also, the ESX service console Is may still be based on Linux but may be very different from other flavors of Linux like Ubuntu, Suse, or Fedora.

From this article, you learned 10 Linux system administration tasks / commands that you can perform in VMware ESX Server and, trust me, if you are not familiar with Linux already, this basic knowledge will be extremely helpful when you get to the ESX service console and need to, say, find and edit a configuration file.

A First Look at the New VMware Server 2.0 RC1 (and How it Compares to ESXi)

2009-09-17T12:23:00.002+05:30

Introduction

What is VMware Server?

Now let’s find out about the latest version of VMware Server…

What’s new in VMware Server 2.0 RC1?

VMware Server 2.0 RC1 was very recently released and, as you would expect with a new major revision, there are many new features. Here are some of those features:

Enhanced VMware Infrastructure (VI) Web Access management interface: VMware has replaced the version 1.x “VMware Console” application with a new web-based interface. To me, this is good and bad. The older application console was very nice. It always worked, it was easy to use, and it was consistent. With the new web interface, you could have web browser issues, DNS lookup issues, Java issues, or you could have difficulty understanding where to click. I know that most every application is going to a web-based interface because it does have benefits but there are pros and cons to each. We will take a look at that new web-based interface in the next section.

Figure 1: New VMware Infrastructure Web Access Management Interface

Independent virtual machine console: To me, this is one of the best features. Instead of having to open the virtual machine console in your web browser (inside the VI Web Access interface), you can have a separate desktop icon for each of your guest VMs. You could also use this to administer VMs on other VMware Servers, across the network. Once you launch the console, you have control over the guest’s virtual devices. Here is what it looks like, once launched:


Figure 2: New standalone console

Support for USB 2.0 devices
Remote Client devices


Figure 3: Ability to access client and server CD devices

Ability to add new SCSI disks on the fly without shutting down the guest VM
Volume Shadow Copy Service (VSS) support

Virtual Machine Communication Interface (VMCI)

This new interface speeds up virtual machine to host and VM to VM communication.

Automatic Startup of VMs
Support for Firefox 3 as a web browser
Link to Virtual Appliance Marketplace


Figure 4: Link to the virtual appliance marketplace

64-bit Guest OS Support
Increase Scalability

Support for up to 8 GB of RAM (up from 3.6 GB in Server 1.0) per virtual machine, 10 virtual network interface cards and up to two virtual SMP (vSMP) processors per virtual machine.

And these are just some of the feature that I found important. For all the VMware Server 2.0 RC1 features and the release notes, visit the VMware Server 2.0 RC1 website.

What does the new VMware Server 2.0 interface look like?

The new management interface for VMware Server 2.0 is certainly different than version 1.0 and it takes some getting used to. Let’s take a look:


Figure 5: Inventory Screen in the new VMware Server 2.0 RC1 management interface


Figure 6: Virtual Machines Gust Configuration

Is VMware Server ready for “prime time”?

How does VMware Server 2.0 RC1 compare to VMware ESXi Server?

VMware Server 2.0

Runs on top of your current Windows or Linux OS. That means that you can keep all your existing apps and run VMware Server along with everything else you are doing.
While still having good performance, VMware Server’s performance is not as strong as ESXi because the Server runs inside your OS.
Can run on any hardware that your current Windows or Linux host OS supports.
Ideal for desktop virtualization and server virtualization for the SMB. Ideal for those who do not want have to go through the trouble of using a whole new OS for virtualization.

VMware ESXi Server

Runs on the bare metal server hardware. That means that you have to wipe out all of your apps and data on a machine and install ESXi.
Greater performance because it runs directly on hardware.
Able to run only on certain hardware.
Ideal for medium & large enterprise virtualization.

Conclusion

High Availability and Disaster Recovery for Virtual Environments

2009-09-17T12:01:00.003+05:30

Virtualization is increasingly being used by IT departments for server consolidation and testing purposes. Virtual servers offer flexibility, but if a single physical server containing multiple virtual servers fails, then the impact of data loss is enormous.

Introduction

Virtualization Benefits

Companies are adopting virtualization at a rapid speed because of the tremendous benefit it offers and some of them include:

Server Consolidation: Virtualization helps to consolidate multiple servers into one single physical server thus offering improved operational performance.
Reduced Hardware Costs: As the number of physical servers goes down, the cost of servers and associated costs like IT infrastructure, space, etc. will also decrease.
Improved Application Security: By having a separate application in each virtual machine, any vulnerability is segregated and it does not affect other applications.
Reduced Maintenance: Since virtual servers can easily be relocated and migrated, maintenance of hardware and software can be done with minimal downtime.
Enhanced Scalability – The ease with which virtual servers can be deployed will result in improved scalability of IT implementation.

File or Block Level Replication

Replicated server is always in a passive mode - cannot be accessed for reporting/monitoring purposes.
Possibility of virus/corruption getting propagated from production server to replicated server.

Application Specific Replication Approach

Backup and Replication

Virtual Environments

Physical to Virtual Servers

Virtual to Virtual Environments

Failover/Failback

Migration

Conclusion

The ins and outs of wireless network security.

2009-09-16T17:06:00.001+05:30

Introduction

In 1999 the IEEE completed and approved the standard known as 802.11b, and WLANs were born. Finally, computer networks could achieve connectivity with a useable amount of bandwidth without being networked via a wall socket. Suddenly connecting multiple computers in a house to share an Internet connection or play LAN games no longer required expensive or ugly cabling. Business users could get up out of their chairs and sit in the sunshine while they worked. New generations of handheld devices allowed users access to stored data as they walked down the hall to a meeting. The dawn of networking elegance was upon us. Users could set their laptops down anywhere and instantly be granted access to all networking resources. This was, and is, the vision of wireless networks, and what they are capable of delivering.
Fast forward to today. While wireless networks have seen widespread adoption in the home user markets, widely reported and easily exploited holes in the standard security system have stunted wireless' deployment rate in enterprise environments. While many people don't know exactly what the weaknesses are, most have accepted the prevailing wisdom that wireless networks are inherently insecure and nothing can be done about it. Can wireless networks be deployed securely today? What exactly are the security holes in the current standard, and how do they work? Where is wireless security headed in the future? This article attempts to shed light on these questions and others about wireless networking security in an enterprise environment.

A few technical details

WLAN networks exist in either infrastructure or ad hoc mode. Ad hoc networks have multiple wireless clients talking to each other as peers to share data among themselves without the aid of a central Access Point. An infrastructure WLAN consists of several clients talking to a central device called an Access Point (AP), which is usually connected to a wired network like the Internet or a corporate or home LAN. Because the most common implementation requiring security is infrastructure mode, most security measures centre around this design, so securing an infrastructure mode wireless network will be the focus of this article. 802.11b specifies that radios talk on the unlicensed 2.4GHz band on one of 15 specific channels (in the US, we are limited to using only the first 11 of those 15 channels). Wireless network cards automatically search through these channels to find WLANs, so there is no need to configure client stations to specific channels. Once the NIC finds the correct channel, it begins talking to the Access Point. As long as all of the security settings on the client and AP match, communications across the AP can begin and the user can participate as part of the network.

Bandwidth on an 802.11b network is limited to 11Mb per access point. This 11Mb is divided among all users on that access point. If ten people access the same AP, communication to the wired world will be limited to approximately the equivalent of a decent DSL line. Because the 802.11b standard does not contain any specifications for load balancing across multiple access points, devices that strictly adhere to the standard have no answer if you find your network becoming over populated. The only way to manage this is to add another AP in the same area, but with a different network name and radio channel, effectively having more than one separate network (up to a maximum of three), in the exact same area. Some wireless vendors have proprietary solutions for load balancing, but discussing these initiatives falls outside the scope of this article. Interested readers should look into individual companies' propaganda documentation before they deploy their wireless network if they feel they will need these services.
Basic security: 802.11b's nod towards private communications and its weaknesses
From its inception the 802.11b standard was not meant to contain a comprehensive set of enterprise level security tools. Still, there are some basic security measures included in the standard which can be employed to help make a network more secure. With each security feature, the potential for making the network either more secure or more open to attack exists.

Service Set Identifier

The Service Set Identifier (SSID) is meant to differentiate networks from one another. Initially, AP's come set to a default depending on the manufacturer. For example, all Linksys AP's are set to the network name of 'linksys', while Cisco AP's are initially set to 'tsunami'. Because these default SSID's are so well known, not changing it makes your network much easier to detect. Another common mistake regarding the SSID is setting it to something meaningful such as the AP's location or department, or setting them to something easily guessable. The SSID should be created with the same rules as any strong password (long, non-meaningful strings of characters including letters, numbers and symbols).

By default the Access Point broadcasts the SSID every few seconds in what are known as 'Beacon Frames'. While this makes it easy for authorized users to find the correct network, it also makes it easy for unauthorized users to find the network name. This feature is what allows most wireless network detection software to find networks without having the SSID upfront.

SSID settings on your network should be considered the first level security, and should be treated as such. In its standards-adherent state, SSID may not offer any protection to who gains access to your network, but configuring your SSID to something not easily guessable can make it harder for intruders to know what exactly they are looking at.

What is the difference between a router and hub or switch?

2009-09-16T16:31:00.000+05:30

A router is a more sophisticated network device than either a switch or a hub. Like hubs and switches, network routers are typically small, box-like pieces of equipment that multiple computers can connect to. Each feature’s a number of "port’s" the front or back that provide the connection points for these computers, a connection for electric power and a number of LED lights to display device status. While routers, hubs and switches all share similar physical appearance, routers differ substantially in their inner workings.

Traditional routers are designed to join multiple area networks (LANs and WANs). On the Internet or on a large corporate network, for example, routers serve as intermediate destinations for network traffic. These routers receive TCP/IP packets, look inside each packet to identify the source and target IP addresses and then forward these packets as needed to ensure the data reaches its final destination.

Routers for home networks (often called broadband routers) also can join multiple networks. These routers are designed specifically to join the home (LAN) to the Internet (WAN) for the purpose of Internet connection sharing. In contrast, neither hubs nor switches are capable of joining multiple networks or sharing an Internet connection. A home network with only hubs and switches must designate one computer as the gateway to the Internet, and that device must possess two network adapters for sharing, one for the home LAN and one for the Internet WAN. With a router, all home computers connect to the router equally, and it performs the equivalent gateway functions.

Additionally, broadband routers contain several features beyond those of traditional routers. Broadband routers provide DHCP server and proxy support, for example. Most of these routers also offer integrated firewalls. Finally, wired Ethernet broadband routers typically incorporate a built-in Ethernet switch. These routers allow several hubs or switches to be connected to them, as a means to expand the local network to accommodate more Ethernet devices.

In home networking, hubs and switches technically exist only for wired networks. Wi-Fi wireless routers incorporate a built-in access point that is roughly equivalent to a wired switch.

Guideline for Securing Wireless LAN Deployment

2009-09-16T15:37:00.003+05:30

Introduction

Wireless LAN (WLAN) is now widely deployed in Hong Kong. You can find hotspots in shopping centres, Internet cafes, hotels and Airport now. It is not surprised to see WLAN accessible along the street in the near future. Due to the flexibility in cabling and the low cost, home and corporate adoption of the technology is booming. WLAN, however, has its disadvantage in terms of security. If not properly deployed, it can bring about great security risks.

What is 802.11b and Wi-Fi?

Wireless LAN can be considered as an extension of the current LAN technology. Instead of using copper wired as the physical connection, high frequency radio wave is used to transmit signals. PCs equipped with a wireless LAN adapter can connect to each other in a network through the air. The most common WLAN standard is IEEE802.11b (also named Wi-Fi). It works on a bandwidth of maximum 11 Mbps on one of the 15 channels (in Hong Kong, use is limited to the first 11 channels) of the unlicensed 2.4GHz band. The negotiated bandwidth can fall back from 11 Mbps to 5.5 Mbps and 2 Mbps when the signal is weak or the environment is noisy. The signal-to-noise ratio can be improved by attaching an antenna to the AP or the client. WLAN uses a shared medium so you can expect collisions exist that lower the effective bandwidth.

There are two modes of communication: ad-hoc mode specifying the client-to-client communication and infrastructure mode specifying client-to-hub communication. In the infrastructure mode communication, the hub or the Access Point connects all clients up to form a wireless network. Each network has a Service Set Identifier (SSID) to differentiate itself from the others. By default the Access Point broadcasts the SSID periodically to let users to locate the network.

IEEE 802.11b includes an optional security feature called the Wired Equivalent Privacy (WEP) to encrypt the traffic between the client and the AP. The standard defines the 64-bit WEP key (with 40-bit secret key). Currently a stronger 128-bit WEP (with 104-bit secret key) is commonly available. The client and the AP must agree on a shared key before communication can be established.

Vulnerabilities and Risks of Wireless LAN

The greatest vulnerability of WLAN network is the lack of physical security. Unlike wired network, intruders do not need to enter your premise to connect to your wireless network and you have no good way of tracking who is connecting at any time.

The second security vulnerability comes from the default settings of the WLAN devices. The default settings are there for ease of deployment and compatibility. These settings allow non-technical users to connect and use WLAN without difficulty. Most users and companies do not change the default settings right after the deployment. Intruders can make use of these ¡§convenience¡¨ to connect your network as well. These are the well known default settings in a WLAN access point (AP):

No encryption (WEP) used or using a default encryption key

Default SSID (e.g. WaveLAN Network, default, wireless)

Default administrator name & password (and SNMP community string as well)

DHCP enabled by default, automatically assign IP address to all connected devices

The third vulnerability comes from the current WLAN technology 802.11b. Firstly the 802.11b incorporates no authentication mechanism and its encryption protocol, the Wired Equivalent Privacy (WEP) protocol has no automatic encryption key change mechanism. Besides, WEP is known to have a flaw that allows collection of enough packets to break the encryption.

The last vulnerability is the weakest link - human. Without a careful study of the risks associated with the current WLAN technology, some people are deploying WLAN for sensitive services. Some companies do not have control on their staff plugging in APs to their internal network, opening a backdoor to intruders and making the perimeter firewall and internet antivirus gateway useless.

The consequences of any intruder connecting to your WLAN network are:

Network resources (e.g. Internet bandwidth) being misused and productivity being affected.

Information leakage due to network sniffing by intruders outside your premise where you have no control of access.

Virus infection due to injected viruses by intruders.

Damage to confidentiality, integrity and availability when systems penetrated by intruders.

The damages might transform to financial, trust and reputation loss. You might have legal liability by allowing this to happen (e.g. violation of agreement of usage, and claim of loss when your network being used for hacking attack).

Wireless LAN Security Checklist

Here is a checklist to secure your WLAN deployment.

General Checklist to Home and Business Use of WLAN

Physical Security
1. Do not put the WLAN Access Point (AP) close to window or door.
2. Power-off when the access point not in use.

Encryption of communication
1. Turn on WEP encryption. The 128-bit key WEP is preferred over the 64-bit key.
2. To further improve the security over time, change the WEP periodically.
Securing SSID
1. Change the default SSID to something else for your network.
2. If possible, turn off SSID broadcast (some AP manager GUIs provide such function, sometimes called ¡§closed network¡¨). You need to tell individual users the SSID.
Controlling access to authorized WLAN card
1. Turn on MAC Address filter to allow only authorized WLAN card to make connection. This is effective if the list of WLAN cards is manageable.
Controlling the IP network
1. Disable DHCP service on the AP. Use static IP address on wireless LAN client. Client without valid IP address cannot connect.
SNMP configuration
1. If your AP is configured using SNMP, make sure you change the default SNMP name and community string. Use a longer SNMP community string with mix of numerals and alphabets
2. Enable SNMP access control list (ACL) to control who can configure the AP
3. For security over time, change the SNMP community string periodically
Mobile Computing Security
1. Most probably you are using WLAN with mobile devices. Make sure you observe other mobile security issues (e.g. theft of hardware, lack of protection from corporate antivirus gateway and firewall) and deploy appropriate protections.
Human Security
1. Do not reveal your password, SSID, WEP key and other security configurations to the third party. When in doubt, change these settings.
Legal and Ethical Responsibility
1. Unauthorized access of information system is a criminal offense. Do not try to connect to others¡¦ wireless networks and systems for curiosity, research or other intents. If you find out your neighbour¡¦s WLAN is insecure, please inform them to get it fixed. As a responsible person, please do not disclose this vulnerability with owner name and location to a third party.

Additional Checklist for Corporations

1.use of technology: For very sensitive and serious services, you have to assess the risk of WLAN before taking it as an option. Put in your budget the extra cost of management and security strategies in WLAN security protection before deploying WLAN.
2.Management Policy: Do not allow the staff to build their own access point. Carry out periodic check to audit if this policy is enforced.
3.Perimeter Protection: Treat WLAN as untrusted network. Segment wireless traffic in a separate network. Install a properly configured firewall between the wired infrastructure and the wireless network to manage traffic going into the internal network or service network.
4.Switched network connection:Connect APs to network switches (instead of hubs) to avoid communication sniffing.
5.Stronger Encryption: WEP protocol has it flaw. Intruder can collect enough packets to break the encryption. It is advisable for corporation to deploy Virtual Private Network (VPN) technology on top of WEP to encrypt wireless communications.
6.Authentication: Consider other forms of authentication for the wireless network (such as RADIUS and Kerberos which currently are available for some products.)
7.Use Upgradeable Solution:WLAN technology is evolving quickly. When choosing a WLAN solution, ensure AP and wireless card can update the firmware. Keep WLAN devices firmware update periodically.

Next Step of Wireless LAN Security

Two of the major security issues of WLAN are the lack of authentication and the weakness in the WEP. Some proprietary WLAN implementations, like Cisco and Lucent, have included client authentication from the 802.1x standard that is used in traditional Ethernet network. Some go a step further to do mutual authentication of client and server by adopting PKI. The Temporal Key Integrity Protocol (TKIP), initially termed as WEP2, was attempted to strengthen the encryption by using dynamic WEP keys which changes every 10,000 packets. These security enhancements will be available in the coming WLAN standards.