VMware vSphere FT Configuration

 Image depicting the Network configuration.

2. Turning on FT.

3. 54% through setting up FT.

4. FT setup complete.

5. vLockstep Interval and Log Bandwidth information are now updated.

6. Primary VM is located on 10.10.10.146. 

7. Secondary VM is running on the Secondary Host- 10.10.10.145.

8. Testing FT using the built in Test Failover command.

9. Failover test completes. Notice that 10.10.10.146 has become the secondary location.

10. After the Failover Test, the primary host server is now 10.10.10.145 and the primary VM is running on it.

11. Furthermore, after the Failover Test, the secondary VM runs on the secondary host server, 10.10.10.146.

12. Failover test completion will result in showing the primary VM on the new primary host server and the new secondary host server with the accompanying vLockstep Interval and Log Bandwidth.

13. Finally, VMware vSphere FT is ready to provide continuous protection to your VMs.

Create Backup job in Symantic Backup exec 2010

Infrastructure setup

This guide is not a best practice guide in any way, it should be treated as an example on how it can be done.

I’m going to use the GRT feature with Backup Exec (BE) to being able to recover individual items etc.

Installation of Backup Exec 2010 R3

Startup browser.exe and select Installation and press Backup Exec.

Type in the license keys. Press Next.

Type in the service account that should be used, in my case “target\SA-BE2010” and password. Press Next.

The installation finds my Exchange server and wants to install the remote agent. Press Next.

The installation is done. Press Next.

Starting up the Backup Exec console. Press “Get software patches and updates”. Update with the latest hotfixes. Press Next.

The updates have been installed. Press Finish.

The arrows on the picture are marking the steps that are going to be configured. Start with Create Logon Accounts.

Press Next.

I’m selecting to Edit my account “SA-BE2010” and typing in my password. Press Next.

Selecting “Common logon account..”. Press Next.

Press “Configure Devices”.

I want to use “Backup-To-Disk Folder” option. Select that one.

The wizard starts. Press Next.

Give the Folder a name “Backup-To-Disk Folder”. Press Next.

Browse for a folder to save the backups into. Press Next.

I don’t want to allocate the maximum size right away. Press Next.

Default values are used, 4 GB per backup-to-disk file. Press Next.

Default values are used, 100 backup sets per backup-to-disk file. Press Next.

Maximum of 2 concurrent jobs. Press Next.

The disk space threshold is set to 500 MB. Press Next.

A summary is shown. Press Next.

Press Finish.

Select “Create Media Sets”.

Since this is the first time, we want to create a new media set. Press Next.

The media set is given the name “Exchange”. Press Next.

Default values are used. Press Next.

Default values are used. Press Next.

A Summary is shown. Press Next.

Press Finish.

The 3 “Getting started” tasks are now completed.

Service Account

Before the installation started I was creating an account named “SA-BE2010” and it’s a member of “Domain Admins” and “Organization Management”.

Restore options

Go to Tools -> Options -> Microsoft Exchange. Put a checkbox in “Automatically recreate user accounts and mailboxes”,
set a default password by pressing “Change Password..”. Then press OK.

Create the backup job

Select “Job Setup” and on the left side press “New job using wizard”.

Selecting Custom and browsing for “Server03.target.local” which is my Exchange server.
Choosing the Microsoft Information Store and check the databases to the right. Press Next.

The backup method that’s used is “Full backup job”. Press Next.

I want to run the backup schedule; every day at 23.00 (11.00 PM). Press Next.

Select “Backup-to-disk folder” and selecting the “device” we created in earlier setup. Press Next.

Keeping the default values. Press Next.

Summary view. Press Submit.

Verification of the backup job

Starting the backup job manually and open it up.

A summary of the backup job.

This blogpost is also published at:
http://www.testlabs….p-exec-2010-r3/

truth v/s hype “Still Vmware don’t have any solution for ensure 100% up time for any enterprise application”

Unfortunately still don’t have any solution for ensure 100 % up time for mission critical application.I

Ideally two are the basic solution, which we can purpose in Vmware environment, we can configure HA for VMs, if primary host(where Currently VMs are resided) goes down, all Vms will migrate to another host (If another host have enough reserve resource)

and will restart all Vms on this host.

It will consider Minimum 5 mins Downtime (Fail to server 100 Up time)

Second option is FT, we can purpose to FT solution, FT facility are supporting to limited only Processor, if your processor are supported then you can assign single processor CPU for virtual machine.

“If you have enterprise application and you expecting 1000 concurrent session then you can face performance issues”

This solution are not probably 100 good.

Third solution is “Vmware Vcenter Site recovery Manager” this also good solution but it also consider few mins downtime and little bit expansive solution for mid size organization.

Little bit frustrate “When typing into a remote console, you see unintended repeated keystrokes “

Details

When typing into a remote console, you see unintended repeated keystrokes.

Solution

If you are using a wide-area or low-bandwidth connection, the time delay over the network may be long enough to cause the virtual machine to start auto-repeat.

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

1. Power off the virtual machine.
2. Add a line, similar to this, at the end of your virtual machine’s configuration (.vmx) file:

   keyboard.typematicMinDelay = "2000000"

   The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

3. Power on the virtual machine.

To make the changes using the vSphere Client:

• Power off the virtual machine
• Right click virtual machine select Edit Settings
• Click Options > General  > Configuration Parameters
• Click Add Row
• Under Name enter keyboard.typematicMinDelay  In the Value field  2000000
• Click OK
• Power on the virtual machine

Host CPU Spikes at 100 Percent when install new VM

You experience high CPU usage in the guest operating system. However, when you examine Task Manager, no CPU usage issues are displayed in the host operating system.

There are instances where performance problems or symptoms may arise, but the cause may be due to the VM environment/configuration. The information and screenshots provided below are available to help determine if the performance problem may exist due to virtual instance instead of at the Traveler level.

Please check the following areas to determine if the VM is the cause of the performance related issue.

Check for VM Alarms

Click the Alarms tab to determine if there are any alerts available.

This example shows a high CPU Alarm condition for the timeframe being investigated. Engage your VMWare team as soon as possible to investigate errors such as these.

Check the CPU of the Traveler server by following these steps:
Click the Performance tab.
Click the “Advanced” button

Click the “Chart Options…” link

For CPU, choose “Past week” or the appropriate time frame for investigation.
Under the Counters section, check the boxes for “Usage” and “Ready”

Click Apply / OK

Save the chart (screenshot or click the save icon in the top right)
Notice that one of these (the Usage one) is in percentage of CPU. The key is to look for critical thresholds and peak times. Look for patterns.

Usage = CPU Usage as a percentage during the interval (during the amount of time that was selected)
Ready = Percentage of time that the virtual machine was ready, but could not get scheduled to run on the physical CPU.

A short spike in CPU usage or CPU ready indicates that the system is making the best use of the host resources. However, if both values are constantly high, the hosts are probably overcommitted. Generally, if the CPU usage value for a virtual machine is above 90% and the CPU ready value is above 20%, performance is impacted.

It can be many reason for 100 CPU spike by the host, one of the hardware compatibility issue can be also for 100 CPU spike.

Poor performance when virtual machines reside on local storage on VMware ESXi 5.0 Affected configurations The system may be any of the following IBM servers: BladeCenter HS23, type 7875, any model The system is configured with at least one of the following: UpdateXpress Service Pack Installer, any version VMware vSphere Hypervisor 5.0 with IBM Customization Installable, Base Install This tip is not option specific. The mpt2sas device driver for the VMware ESXi 5.0 is affected. VMware ESXi 5.0 Solution Issue the following esxcli commands in the ESXi Shell to remove ilfu and LSIProvider VIBs. esxcli software vib remove -n ilfu esxcli software vib remove -n LSIProvider

Virtual PC Performance Checklist

• Make sure your Host Operating System’s disk is defragmented.

  This includes the System Disk (the disk your OS boots off of) as well as the Disk that holds your Virtual Hard Disk File.
• Run Fewer Applications.
I’m continually amazed when folks complain about VM performance and when I get to their desk I see that they are running Outlook. That 200+megs could be better used by the system. Are you running a VM or checking your email? Consider checking your email on a schedule,  or using Outlook Web Access while you work on your VM.

• Enable Hardware Assisted Virtualization

If you’ve got this on your computer, turn it on. There IS some concern about really sophisticated Trojans that can use this technology for evil, but for me, it’s all good as it speeds most Guest Operating Systems (especially non-Microsoft ones) up quite a bit.
• Give your Virtual Machines LESS MEMORY
o I’ve found that 512 megs is just about the Ideal Amount of memory for 90% of your Virtual Machines. Don’t bother trying to give them 1024 megs, it’s just not worth the pressure it’ll put on the Host Operating System.

• Considering making a custom Windows install for your VMs.

Rather than going to all the effort to REMOVE things, why not create a Windows installation that can be shared across your organization that doesn’t include the crap ahead of time. There’s a Windows Installation Customizer called nLite that lets you prepare Windows installations so they never include the stuff you don’t want. Makes it easier if Solitaire is never installed

• Make sure the Guest Operating System is defragmented.

Disk Defragmenter that runs in that “Text Mode” place before Windows really starts up. This allows it to get at files that don’t always get defragmented.

• Don’t use NTFS Compression on the Virtual Machine Hard Drive File in the Host Operating System

NTFS Compression doesn’t work on files larger than 4 gigs, and can cause corruption.

• Don’t Remote Desktop or VNC into Host Operating Systems that are hosting Virtual Machines.

If you’re remoting into a machine where THAT machine is running a VM, note that to the Remote Desktop protocol (and VNC) the VM just looks like a big square bitmap that is constantly changing. That guarantees you slow performance. If you can, instead, Remote Desktop into the Virtual Machine itself.

• Make sure you’ve install the Virtual Machine Additions (or Tools, or Utilities, or Whatever)

Virtual PC and VMWare and Parallels all include drivers and tools that improve the performance of your Virtual Machine. They are there for good reason, make sure you’ve installed them.
 Also, if you’re running a Virtual Machine created under and older version, like Virtual PC 2004, and you’re now running under a newer one, like 2007, pay attention to the upgrade warnings and install the latest drivers and Virtual Machine Additions.

Virtual PC Performance Checklist

which VM backup should be more reliable ?

Type of VM backup through Symantec

agent-based backup is also known as guest based backup. An agent is installed in every virtual machine and treats each virtual machine as if it was a physical server. The agent in this scenario is reading data from disk and streaming the data to the backup server

Advantage-

• Both physical and virtual machines are protected using the same method
• Application owners can manage backups and restores to guest OS
• Time tested and proven solution
• Meets their recovery needs
• This is the only way to protect VMware Fault Tolerant virtual machines and VMs with Physical Raw Disk Mappings RDMS

Disadvantage-

• Significantly higher CPU, memory, I/O and network resources utilization on virtual host machines when backups run.
• Need to install and manage agents on each virtual machine
• Cost may be high for solutions that license on a per agent basis as opposed to per hypervisor based licensing
• lack of visibility into changing virtual infrastructure
• No visibility for backups from VM administrators’ point of view; for example, backups are not visible at vSphere client level
• Complex disaster recovery strategies
• Lack of SAN transport backups to offload backup processing job from virtual infrastructure
• No protection for offline virtual machines and virtual machine templates
• Slow file by file backup by agent sending the even unchanged data over and over again

 

Agentless backup-

Agentless backup, also known as host-based backup, refers to solutions that do not require an agent to be installed on each VM by the administrator. However, it’s important to note that the software may be injecting an agent onto the guest machines without your knowledge.

Advantage-

• VMs can be backed up online or offline
• Less CPU, memory, I/O and network impact on the virtual host
• An agentless architecture doesn’t require the management of agent software
• No per VM agent licensing fees

• Extremely difficult to recover granular object data – first restore the entire VM and its virtual disks
• Traditional login techniques to log into the server
• Temporary “injected” drivers can destabilize the system and compromise data integrity
• Troubleshooting is more complex when using injected (temporary) agents
• A centralized controller is a single-point-of-failure
• Requires a fully-virtualized environment. Physical machines still require agent-based backup. If you have physical and virtual you will need two backup solutions – one for physical and the other for virtual.

 

Agent-Assisted Backup-

Agent assisted backups are also known as host based backup and integrate with VMware’s VADP and Microsoft VSS to provide fast and efficient online and offline backups of ESX, vSphere and Hyper-V. The primary difference between agentless and this design is its perspective: it pairs the VMware VADP or Microsoft VSS with an agent that gathers application metadata to enable multiple avenues of recovery (full VM, applications, databases, files, folders and granular objects).

 

• The backup is for the entire virtual machine. This is important because it means the entire VM can be recovered from the image.  It also means that products like Backup Exec & NetBackup can offer “any-level” of recovery from the image contents: Files / Folders, Databases and Granular database contents, like email and documents.
• The backup can be offloaded from both VM as well as the hypervisor. This means that Backup Exec & NetBackup have the flexibility to offload VM backup onto an existing backup server, instead of burdening the hypervisor.  It also means that users have the option of deploying a dedicated VM, e.g. a virtual appliance, when a physical backup server is not practical.
• Application owner can self-serve restore requests: The application owner can request restores directly back to the application.
• Enhanced security: The agent installed for assisting with VM backup can be managed by the application owner. Thus you are avoiding the need to share guess OS credentials with backup administrator.

 

Best Way to store Backup-

1. Backup VM directly from storage location for example, SAN, iSCSI, NAS, without having to install any software agent inside the VMs

2. Centralized backups for Virtual machines
3. Keep all schedule in simple way for easily understand, thing wrest scenario and make backup plan
4. Make it documented for every backup policy.

 

 

Virtaul machine file structure

Once you understand virtual machines (VMs) from a hardware perspective, you can study the components that make up a VM on an ESX/ESXi host. These are the various VMware file types associated with a VM, located in the VM’s directory on the host (represented in the illustration below).

 

tools options, and power management options. While you can edit this file directly to make changes to a VM’s configuration, don’t do this unless you know what you are doing. If you do make changes directly to this file, make a backup copy first.

VMDK files. All virtual disks are made up of two files, a large data file equal to the size of the virtual disk and a small text disk descriptor file, which describes the size and geometry of the virtual disk file. The descriptor file also contains a pointer to the large data file as well as information on the virtual disks drive sectors, heads, cylinders and disk adapter type. In most cases these files will have the same name as the data file that it is associated with (i.e., myvm_1.vmdk and myvm_1-flat.vmdk). You can match the descriptor file to the data file by checking the Extent Description field in this file to see which -flat, -rdm or -delta file is linked to it. 

The different types of virtual disk data files that can be used with VMware virtual machines are:

The -flat.vmdk file
This is the default large virtual disk data file that is created when you add a virtual hard drive to your VM that is not an RDM. When using thick disks, this file will be approximately the same size as what you specify when you create your virtual hard drive. One of these files is created for each virtual hard drive that a VM has configured, as shown in the examples below.

The -flat.vmdk file
This is the default large virtual disk data file that is created when you add a virtual hard drive to your VM that is not an RDM. When using thick disks, this file will be

• The -delta.vmdk file
  These virtual disk data files are only used when making snapshots. When a snapshot is created, all writes to the original -flat.vmdk are halted and it becomes read-only; changes to the virtual disk are then written to these -delta files instead. The initial size of these files is 16 MB and they are grown as needed in 16 MB increments as changes are made to the VM’s virtual hard disk. Because these files are a bitmap of the changes made to a virtual disk, a single -delta.vmdk file cannot exceed the size of the original -flat.vmdk file. A delta file will be created for each snapshot that you create for a VM and their file names will be incremented numerically (i.e., myvm-000001-delta.vmdk, myvm-000002-delta.vmdk). When the snapshot is deleted, these files are automatically deleted after they are merged back into the original flat.vmdk file.

  

   

• The -rdm.vmdk file
  This is the mapping file for the raw device mapping (RDM) format that manages mapping data for the RDM device. The mapping file is presented to the ESX host as an ordinary disk file, available for the usual file system operations. However, to the VM, the storage virtualization layer presents the mapped device as a virtual SCSI device. The metadata in the mapping file includes the location of the mapped device (name resolution) and the locking state of the mapped device. If you do a directory listing, you will see that these files will appear to take up the same amount of disk space on the VMFS volume as the actual size of the LUN that it is mapped to, but in reality they just appear that way and their size is very small. One of these files is created for each RDM that is created on a VM.

  

The .vswp file. When you power on a VM, a memory swap file is created that can be used in lieu of physical host memory if an ESX host exhausts all of its physical memory because it is overcommitted. These files are created equal in size to the amount of memory assigned to a VM, minus any memory reservations (default is 0) that a VM may have set on it (i.e., a 4 GB VM with a 1 GB reservation will have a 3 GB VSWP file created). These files are always created for virtual machines but only used if a host exhausts all of its physical memory. As virtual machine memory that is read/written to disk is not as fast as physical host RAM, your VMs will have degraded performance if they do start using this file. These files can take up quite a large amount of disk space on your VMFS volumes, so ensure that you have adequate space available for them, as a VM will not power on if there is not enough room to create this file. These files are deleted when a VM is powered off or suspended.

Virtual machines will lock the .vswp, -flat.vmdk and -delta.vmdk, .vmx and .log files during runtime.

The .vmss file. This file is used when virtual machines are suspended and is used to preserve the memory contents of the VM so it can start up again where it left off. This file will be approximately the same size as the amount of RAM that is assigned to a VM (even empty memory contents are written). When a VM is brought out of a suspend state, the contents of this file are written back into the physical memory of a host server, however the file is not automatically deleted until a VM is powered off (an OS reboot won’t work). If a previous suspend file exists when a VM is suspended again, this file is re-used instead of deleted and re-created. If this file is deleted while the VM is suspended, then the VM will start normally and not from a suspended state.

The .vmsd file. This file is used with snapshots to store metadata and other information about each snapshot that is active on a VM. This text file is initially 0 bytes in size until a snapshot is created. A VMSD file updates with information every time snapshots are created or deleted. Only one of these files exists regardless of the number of snapshots running, as they all update this single file. The snapshot information in a VMSD file consists of the name of the VMDK and VMSN file used by each snapshot, the display name and description, and the UID of the snapshot. Once your snapshots are all deleted, this file retains old snapshot information but increments the snapshot UID to be used with new snapshots. It also renames the first snapshot to “Consolidate Helper,” presumably to be used with consolidated backups.

The .vmsn file. This file is used with snapshots to store the state of a virtual machine when a snapshot is taken. A separate .vmsn file is created for every snapshot that is created on a VM and is automatically deleted when the snapshot is deleted. The size of this file will vary based on whether or not you choose to include the VM’s memory state with your snapshot. If you do choose to store the memory state, this file will be slightly larger than the amount of RAM that has been assigned to the VM, as the entire memory contents, including empty memory, is copied to this file. If you do not choose to store the memory

 

net4solution.blogspot.com

Link

net4solution.blogspot.com