Latest Fling from VMware Labs – Makyo

Makyo lets you copy virtual machines and vApps from one vCenter Server to another using a wizard in the vSphere Web Client. The said copy operation from one vCenter Server to another is done by starting an OVF export operation on the source server and an import OVF operation on the target server. No intermediate files are created when you copy a virtual machine or a vApp. The fling is installed as a plugin to the vSphere Web Client. 

VMware vSphere Blog: Clarification on (Zero-Down Time) VMware Tools Upgrade in vSphere 5.1

There have been some recent questions about upgrading to the latest version of VMware Tools in vSphere 5.1 and the benefits it may bring with future upgrades of VMware Tools. Historically, VMware Tools upgrades has always required an operating system reboot as new device drivers and kernel modules will not go into effect until the next reboot. For Windows operating systems, you could “suppress” a reboot by specifying an advanced installer option. For UNIX/Linux operating systems, the new device drivers and kernel modules will be staged when you upgrade VMware Tools, but will only be activated upon the next reboot. In both case, you can continue to run your virtual machine in a partially upgraded state for a limited amount of time until your next maintenance window, but it is recommended that you reboot as soon as possible.

In vSphere 5.1, some of you may have heard about something called Zero-down time VMware Tools upgrade where an operating system reboot will no longer be required for upgrading to future versions of VMware Tools. However, this statement is inaccurate and has caused some confusion with our customers. I would like to take this opportunity to help clarify the expected behavior as you plan for VMware Tools upgrade in vSphere 5.1.

Is there downtime when upgrading to vSphere 5.1 version of VMware Tools?

Yes. If you are running VMware Tools prior to vSphere 5.1, an operating system reboot will always be required for new device drivers and kernel modules to go into effect.

Is there downtime when upgrading to future versions of VMware Tools?

It depends. If one or more components have been updated since the last VMware Tools upgrade or one of the VMware Tools components requests a system reboot, then a reboot will be required. The following VMware KB http://kb.vmware.com/kb/2015163 has been created to help identify the components that would require a reboot. A reboot would not be require if only the base components of VMware Tools have been upgraded (e.g. no PVSCSI, VMXNET3). You can refer to the above KB for components that require a reboot.

What has changed in VMware Tools for vSphere 5.1 for upgrades?

We have made improvements in our VMware Tools installer to help reduce the need for operating system reboots when upgrading common components for VMware Tools. This overall reduces the amount of time for managing VMware Tools upgrade as well as reducing or potentially eliminating the amount of downtime required for a system reboot when upgrading VMware Tools.

Which Operating Systems does this apply to?

Windows Vista or greater

What version of virtual hardware or Virtual Machine Compatibility is required?

Virtual Hardware 9 or VMware ESXi 5.1 Compatibility or greater

What about UNIX/Linux Operating Systems?

As mentioned above, this currently only applies to Windows operating system for Vista or greater. However, VMware continues to look for ways to improve the VMware Tools platform and UNIX/Linux operating systems is definitely something that is being looked at.

Is VMware Tools Upgrade Required When Upgrading vSphere?

Please refer to this blog article by Kyle Gleed.

Get notification of new blog postings and more by following VMware Automation on Twitter:  @VMWAutomation

. Bookmark the

.

ownCloud 5.0 beta 1

Start testing :-)

From:   Frank Karlitschek 
To:     "owncloud@kde.org Mailinglist" 
Date:   Wed, 20 Feb 2013

Hi everybody,

I'm very happy to announce the beta 1 of ownCloud 5

You can download it here:
http://owncloud.org/releases/owncloud-5.0.0-beta1.tar.bz2

This is beta quality and it is not recommended to use this in a production environment. 
But if you want to help with testing and QA please download it and give feedback on 
the bugtracker:
https://github.com/owncloud/core/issues
Let's give it a hard test.

The new encryption system is not yet part of this release but it will be included in
the next beta. An improved UI for the external filesystem mounting will also come with 
the next beta.

Thanks to everybody who contributed and especially the people who worked super hard on
fixing bugs in the last few weeks and during the developer sprint last weekend.

You guys rock!!!

Frank

iOS 6.1.2 now available (updated)

iOS 612 now available

Apple has released iOS 6.1.2 which, according to Apple, "Fixes an Exchange calendar bug that could result in increased network activity and reduced battery life." Check for software updates on your Apple device to find it.

Update: Ars Technica says that the 6.1.2 update has fixed the Exchange calendar bug, but did not resolve the passcode unlock bug we reported on last week.



VMware Accelerate: Is Your Organization Ready for the Software-Defined Data Center?

by Heman Smith

Infographics are great for providing clarity. As the one below illustrates, the role of IT workers is rapidly transforming — and IT executives are keen on building the optimum IT organizational structure for the software-defined data center (SDDC).

If you want an agile, business-responsive, service-driven IT organization, the role of IT must change from a reactive, rigid structure to one that is proactive, innovative and dynamic. The key to the success of this transformation to a SDDC is a symbiotic partnership between IT and the business, driven by executive leadership.

Accelerate Advisory Services consultants work collaboratively with customer stakeholders to assess their organization’s operational readiness against a cloud operational capability scale, which VMware has developed from years of experience with the technologies and processes of successful cloud computing. Looking at the organization’s IT operations from this cloud capabilities framework perspective, we gather information and data to provide our customers with actionable recommendations and financial guidance on their transformation to a SDDC.

When I work with customers, I review the core assumptions for successful IT operations in a cloud-driven world:
• IT needs to change in significant ways to achieve the capabilities needed for effective cloud operations.
• People and organization both need to adjust to reflect the faster pace, the new technologies and critical changes in processes.
• When IT becomes a service broker, its financial model fundamentally changes, and measurements are essential for success.
• Intentional, ITIL-type processes and control are no longer optional, but essential.
• The new, cloud-centric technology architecture delivers tremendous capability and requires more responsibility.

Accelerate consultants can help you undertake your transformation to the software-defined data center. Visit our Web site to learn more about our offerings, or reach out to us today at accelerate@vmware.com for more information.

Would you like to continue this conversation with your C-level executive peers? Join our exclusive CxO Corner Facebook page for access to hundreds of verified CxOs sharing ideas around IT Transformation right now by going to CxO Corner and clicking “ask to join group.”

Heman Smith is an operational capability consultant for VMware Accelerate Advisory Services. Follow him on Twitter @hemansmith

. Bookmark the

.

Video – vSphere 5.1 Data Protection

vSphere Data Protection (VDP) is a robust, simple-to-deploy, disk-based backup and recovery solution. vSphere Data Protection is fully integrated with VMware vCenter Server and enables centralized and efficient  management of backup jobs while storing backups in deduplicated destination storage.


The benefits of vSphere Data Protection are:
  • Provides fast and efficient data protection for all of your virtual machines, even those powered off or moved between physical hosts.
  • Significantly reduces disk space consumed by backup data using smart deduplication across all backups. 
  • Reduces the cost of backing up virtual machines and minimizes the backup window using change block tracking and VMware virtual machine snapshots.
  • Allows for easy backups without the need for third-party agents installed in each virtual machine.
  • Uses a simple straight-forward installation as an integrated component within vSphere, that can be managed by a web portal.
  • Direct access to vSphere Data Protection configuration integrated into the standard vSphere Web Client.
  • Protects backups with checkpoint and rollback mechanisms.
  • Provides simplified recovery of Windows and Linux files with end-user initiated file level recoveries from a web-based interface.

The VMware vSphere Web Client interface is used to select, schedule, configure, and manage backups and recoveries of virtual machines. During a backup, vSphere Data Protection creates a quiesced snapshot of the virtual machine. Deduplication is automatically performed with every backup operation.
The following terms are used throughout this document in the context of backup and recovery.
  • A datastore is a virtual representation of a combination of underlying physical storage resources in the  datacenter.
  • A datastore is the storage location (for example, a physical disk, a RAID, or a SAN) for virtual machine files.
  • Changed Block Tracking (CBT) is a VMkernel feature that keeps track of the storage blocks of virtual machines as they change over time. The VMkernel keeps track of block changes on virtual machines, which enhances the backup process for applications that have been developed to take advantage of VMware’s vStorage APIs.
  • VMware vStorage APIs for Data Protection (VADP) enables backup software to perform centralized VM backups without the disruption and overhead of running backup tasks from inside each virtual machine.
  • Virtual Machine Disk (VMDK) is a file or set of files that appears as a physical disk drive to a guest operating system. These files can be on the host machine or on a remote file system.
  • The vSphere Data Protection appliance is a purpose built virtual appliance for vSphere data protection.
Download VMware vSphere Data Protection 5.1

vSphere Data Protection Advanced (VDP Advanced) – Is a new standalone product sold separately from vSphere – It extends the capabilities of VDP with greater scalability and integration with business-critical applications to protect midsize vSphere environments. VDP Advanced provides fast agent-less image-level backups, as well as guest-level application-consistent protection of Microsoft® SQL Server™ and Microsoft® Exchange Server™.   

vSphere PowerCLI Blog: PowerCLI 5.1 Release 2 Now Available

PowerCLI 5.1 Release 2 has now been released and can be downloaded here.  As always you will find some great new features, bug fixes and enhancements which make PowerCLI even better than before… I know its hard to believe but its true.

VDS Cmdlets

PowerCLI SnapinsWhenever I would ask the question at VMUG’s or VMWorld, “What would you like to see next from PowerCLI” I would always get the same answer “Support for Virtual Distributed Switches!”.

Previously there has been a fling available and also some work created by community member “Luc Dekens” to use VDS, this was a great start but in some cases was not a sustainable solution as it was either not supported or more complicated to maintain or use.

I am now pleased to tell you that PowerCLI has a new snapin, this snapin is called VMware.VimAutomation.VDS and is for managing Virtual Distributed Switches.

Introduced are 14 new cmdlets which will allow you to perform actions against your VDS configuration, we can use the Get-VdsCommand cmdlet to list the new cmdlets.

An overview of these are below:

Cmdlet Name Cmdlet description
Add-VDSwitchPhysicalNetworkAdapter This cmdlet adds host physical network adapters to a distributed switch.
Add-VDSwitchVMHost This cmdlet adds hosts to the specified distributed switch.
Export-VDPortGroup This cmdlet exports the configuration of a specified distributed port group to a specified .zip file.
Export-VDSwitch This cmdlet exports the configuration of a specified vSphere distributed switch to a .zip file.
Get-VDPortgroup This cmdlet retrieves distributed port groups.
Get-VDSwitch This cmdlet retrieves vSphere distributed switches.
New-VDPortgroup This cmdlet creates distributed port groups.
New-VDSwitch This cmdlet creates vSphere distributed switches.
Remove-VDPortGroup This cmdlet removes distributed port groups.
Remove-VDSwitch This cmdlet removes vSphere distributed switches.
Remove-VDSwitchPhysicalNetworkAdapter This cmdlet removes host physical network adapters from the distributed switches they are connected to.
Remove-VDSwitchVMHost This cmdlet removes hosts from the specified distributed switches.
Set-VDPortgroup This cmdlet modifies the configuration of distributed port groups.
Set-VDSwitch This cmdlet modifies the configuration of vSphere distributed switches.

Remember each of these cmdlets has help built in, to access the help including examples of how you might use these cmdlets use the following:

Get-Help cmdletname –full

PowerShell v3 Support

As well as the new cmdlets for working with Distributed switches and all the other great enhancements in PowerCLI 5.1 Release 2 we made sure we listened to our customers and with the release of PowerShell version 3 it seams that a lot of people are already making use or planning to install PowerShell v3.

You will be happy to know that PowerCLI now supports PowerShell v3, this not only gives you support from VMware but also we are now able to take advantage of some of the great enhancements which PowerShell v3 brings.

Some PowerShell v3 examples…

Simplified Syntax… Making PowerShell and therefore PowerCLI easier to read and quicker to type we can use simplified syntax to give us even more English like statements, before we would have needed to use the {} brackets to compare a property, now we are able to type it the same way we would think it…

SNAGHTML26e15701_thumb3

The above simple example shows all virtual machines which are powered on.

vCloud Director 5.1 Support

With PowerCLI 5.1 R2 we have also added support for vCloud Director 5.1, you can now automate the latest version of vCloud director using both PowerCLI and PowerCLI for tenants in a vCloud Director 5.1 environment.

image_thumb2

. Bookmark the

.

VMware vSphere Blog: vSphere 5.1 – VDS Feature Enhancements – Port Mirroring – Part 2

In the last post I covered the configuration of one of the port mirroring session type, Switch Port Analyzer (SPAN) on a host. SPAN is a simple configuration on VDS that allows users to quickly replicate traffic to another virtual machine on the same host. However, SPAN on VDS has following limitations

-       The source and destination ports of the session should be on the same host. Thus limiting the visibility to a particular host.

-       If the monitored virtual machine is moved from one host to another using vMotion, you can’t monitor that virtual machine traffic anymore.

The Remote SPAN (RSPAN) port mirroring session addresses above concerns and also provides the capability to send mirror traffic to a central analyzer tool. The analyzer tool can be connected multiple hops away in a network as shown in the diagram below.

RSPAN Deployment Diagram

The RSPAN port mirroring session configuration is little more involved when compared to SPAN setup. You have to configure RSPAN session on VDS and also configure RSPAN VLAN on physical switches. A dedicated RSPAN VLAN is defined to carry the port mirror traffic. Let’s briefly take a look at the main components of the RSPAN session as shown in the above diagram.

1)   VDS – VDS is called as source switch because RSPAN source of the port mirroring session is on this virtual switch.

2)   S1 – Physical switch is intermediate switch. S1 is not RSPAN source or destination switch.

3)   S2 – Physical switch is destination switch. The S2 switch port where Analyzer is connected acts as RSPAN destination.

4)  Analyzer – Device where packet analysis is performed.

Since RSPAN end to end mirror session configuration requires physical switch support, users should look at the physical switch vendor’s documentation for guidelines and any limitation of RSPAN feature.

We will now go through the steps of configuring a remote mirroring (RSPAN) session on VDS. As shown in the diagram below, select “Remote Mirroring Source” and configure the source of the RSPAN session.

RSPAN configuration – screen1

According to the configuration screen above, VDS switch can also act as the destination for the RSPAN session by selecting “Remote Mirroring Destination”. I will talk about that deployment in the part 3 of this series.

The next step in the configuration process is enabling the port mirror session status, providing VLAN ID for RSPAN traffic, and selecting or deselecting the preserve original VLAN option.

RSPAN configuration – screen 2

In this example we have configured VLAN 400 as RSPAN VLAN or “Encapsulation VLAN ID”. We have deselected Preserve original VLAN. Also, allow Normal I/O on distributed ports (Please refer to the diagram below).

In scenarios where virtual machine tags traffic and you want to preserve the VLAN information in the monitored packets, you should check the preserve original VLAN box. Once you check the box the mirrored packet will be double tagged also called as QinQ tag. The external tag of these packet will be VLAN 400, RSPAN VLAN. In this example the monitored virtual machine doesn’t send tagged traffic so we have deselected preserve original VLAN option.

RSPAN configuration – screen 3

The next step is to select the ports that need monitoring. As shown in the figure below, select the virtual machine or vmknic ports that you would like to monitor as part of this RSPAN session.

RSPAN configuration – screen 4

Then select the direction of the traffic that will be mirrored. In this case both ingress and egress traffic is selected.

RSPAN configuration – screen 5

After the source port and traffic direction config, it is time to configure the destination port where the mirror traffic will be sent. You can choose uplinks connected to the VDS as the mirror destination.

RSPAN configuration – screen 6

In this example, we have selected only uplink1 to carry the mirror traffic.

RSPAN configuration – screen 7

This concludes the configuration on the VDS.

After completing the RSPAN source session configuration on VDS, we will configure the Switch S1 and S2 such that mirror traffic is delivered to the Analyzer connected on the S2 port. Please refer to the “RSPAN Deployment” diagram  for the switch connectivity details.

S1 Switch Configuration:

1)   Configure VLAN 400 as RSPAN VLAN (Example Cisco CLI commands)

  1. Vlan 400
  2. Remote span
  3. exit

2)   Configure physical switch port where host’s vmnic1 (uplink1) is connected as trunk, and then add VLAN 400 in the list of allowed VLANs.

3)   Configure VLAN 400 on the trunk port connecting physical switch S2.

S2 Switch Configuration:

1)   Configure VLAN 400 as RSPAN VLAN (Example Cisco CLI commands)

  1. Vlan 400
  2. Remote span
  3. exit

2)   Configure VLAN 400 on the trunk port connecting physical switch S1.

3)   Configure destination RSPAN session to send traffic to the switch port where analyzer is connected (Example Cisco CLI commands)

  1. monitor session 10 source remote vlan 400
  2. monitor session 10 destination interface Gig 1/22

After this configuration you will be able to monitor virtual machine traffic centrally on the Analyzer device that is connected multiple hops away from the source.

In the next post, I will discuss how you can configure VDS as the RSPAN destination session and monitor traffic centrally through a virtual machine connected to the VDS.

Get notification of these blogs postings and more VMware Networking information by following me on Twitter:  @VMWNetworking

. Bookmark the

.

VMware vSphere Blog: vSphere 5.1 – Network I/O Control (NIOC) Architecture – Old and New

Recently there has been some discussion around the egress traffic management feature of vSphere Distributed Switch (VDS) also called as Network I/O Control (NIOC). Thanks to my colleague Frank Denneman for providing more details about this feature on his blog site and bringing to my attention an architectural change in the vSphere 5.1 release. This change impacts how the Limit parameters are applied at the host level. In this post, I will first describe the old architecture of NIOC and then discuss the change. I will also talk about the impact of this change and what users need to keep in mind while configuring limit parameter.

Let’s first take a look at the NIOC components and architecture in the previous releases of vSphere. The diagram below shows a vSphere host with two 10 gig NICs, VDS components, NIOC configuration table, and different traffic types running on the host.

NIOC – Old Architecture

The following are the key architectural layers in the VDS:

1)   Teaming Policy layer: This is the layer where teaming policy defined at the port group level gets applied. Based on the choice of the load balancing algorithm and the active/passive uplink configurations at the port group level, this layer will determine which traffic from the virtual ports (vnic,vmknic) will be sent over the which physical NICs ( uplinks). For example, when the default load-balancing algorithm of “Route based on originating virtual port” is selected, based on the port ID hash output traffic will be sent on Physical NIC1 or Physical NIC2. The diagram above shows VM1 traffic flowing through NIC1 and VM2 through NIC2.

2)   Shaper : This is the layer where the Limit parameter configured for a traffic type is enforced. For example, if the virtual machine traffic is limited to 2 Gig any additional virtual machine traffic will be dropped at this layer even if physical NICs have capacity. In the diagram above total VM1 and VM2 traffic can’t exceed 2 Gig of bandwidth.

3)   Scheduler: In this layer scheduler schedules traffic on physical NIC based on the share configurations per traffic type. There is one scheduler instantiated per physical NIC, and it handles all the traffic that is sent by the teaming layer. The share parameter is used to decide what percentage of physical NIC bandwidth is allocated to that particular traffic type.

Based on the number of active traffic types scheduled on a particular uplink and their share configuration, the scheduler will make sure the bandwidth is distributed among the traffic types according to the share configurations. If one of the traffic types is not utilizing any bandwidth then that bandwidth gets distributed among other traffic types. Shares configuration thus provides flexibility and better utilization of bandwidth. However, it is important to note that the limit parameters override the shares parameter configuration. If there is a limit parameter configured for a traffic type, it can’t utilize the unused bandwidth of a NIC and go over the assigned limits. As a best practice we recommend not to use limit parameter unless user really wants to control a traffic type.

After looking at the old architecture let’s now talk about the changes in the new vSphere release. As shown in the diagram below, you will find that there is a shaper instantited per physical NIC similar to the scheduler function per NIC. In this release instead of applying limit parameters across the whole teaming level they are now applied per physical NIC level.

NIOC – New Architecture

So the question is what is the impact of this change? Let’s take the VM traffic type example to illustrate.

As shown in the table in the above diagram, the VM Traffic is limited to 2 gig bandwidth. The VM Traffic consists of VM1 and VM2 communication, and it utilizes both the physical NICs. In this situation each shaper is going to make sure that it doesn’t send more than 2 gig of VM traffic. If you take a look at the overall VM traffic coming out of the host, it will be (2 + 2) 4 Gig. This is different from what we saw in the old architecture where the limit is applied across the two NICs and max VM traffic out of the host is 2 Gig as configured in the table.

This change is going to impact only traffic types that are utilizing multiple physical NICs. You will not see any difference how limits are applied for infrastructure traffic types such as vMotion and iSCSI, unless you are using multi-NIC vMotion or multi-pathing (MPIO) i.e more than two uplinks for a particular traffic type.

When you look at the configuration screen shown below, we still call the limits as “Host Limit (Mbps)”. We might have to change that as “Uplink Limit (Mbps)” to reflect how the limits are applied. But for now, if you are using limit parameters you should find out if that traffic type is flowing through multiple NICs. If yes, then, to calculate the overall host level limit for that traffic type, multiply the configured limit parameter with the number of NICs on which the traffic is flowing. For example, in the diagram above, VM traffic is configured with 2 Gig limit and the traffic is flowing through 2 NICs. The overall host level VM traffic is limited to 2gig x 2 NICs = 4 Gig.

Screen Shot – Host Limits

Please let me know if you have any specific questions on this feature.

Get notification of these blogs postings and more VMware Networking information by following me on Twitter:  @VMWNetworking

. Bookmark the

.

VMware Support Insider: Introducing VMware vCenter Support Assistant 5.1

Today, VMware is very pleased to announce that VMware vCenter Support Assistant 5.1 is now generally available to the public.

VMware vCenter Support Assistant 5.1 is a free, downloadable plug-in for VMware vCenter Server. It provides an easy-to-use, secure, one-stop shop both for creating and managing support requests and generating and uploading logs. It is deployed as a virtual appliance and integrates with VMware vCenter Server as a plug-in that can be accessed using either the VMware vSphere Client or the VMware vSphere Web Client.

Check out this short Demo!

OK you say? Where are the goods? Jump right in with these links, or read on for a more in-depth introduction.

Figure 1: VMware vCenter Support Assistant Conceptual View.

Easily open or view the status of any existing support request, add comments, reply to support engineer queries, and attach diagnostic information or other files such as screenshots. It also includes a VMware Knowledge Base search capability, which enables you to resolve common issues more rapidly. The vCenter Support Assistant plug-in helps you gather diagnostic information up front from your  vSphere environment that VMware Technical Support finds most useful.

You can also use VMware vCenter Support Assistant to file support requests for any product that you already have support entitlement for whether that entitlement is by subscription, or paid for incident packs. With just a few clicks, VMware vCenter Support Assistant can directly generate log support bundles from the following products:

VMware vCenter Server

* Includes both VMware vCenter Server for Windows and the VMware vCenter Server Appliance.

VMware vSphere (ESX or ESXi)

NOTES: Access to public Internet is not required for the VMware vCenter Server, but is required for the VMware vCenter Support Assistant virtual appliance and the vSphere Client. Refer to the System Requirements.

All files are sent securely using SSL.

Since log files may contain sensitive, confidential, and/or personal information, the VMware vCenter Support Assistant provides the optional capability to scrub logs prior to submission.

Technical Guide

The following guide is depicted using the VMware vSphere Client; however, VMware vCenter Support Assistant plugin-in also works with VMware vSphere Web Client introduced in VMware vSphere 5.1

Accessing VMware vCenter Support Assistant

Once deployed and registered, VMware vCenter Support Assistant will appear under the Solutions and Applications in the Home tab in the vSphere Client. The Support Assistant plug-in will also appear under “Classic Solutions” in the VMware Web Client.

Figure 2: VMware vCenter Support Assistant in Solutions and Applications.

Once VMware vCenter Support Assistant is selected, the solution will present a login screen. This login screen allows you the user to access My VMware directly from the solution, create a case, review or update a case, and attach diagnostics or other attachments.

Figure 3: Login to My VMware.

Once logged in, the user will have the option to View or Create a Technical Support Request through VMware vCenter Support Assistant.

Creating a New Technical Support Request

Let’s take moment to create a new Technical Support Request by selecting “Create a New SR.” Once you login, you will be checked against your entitlements and allowed to open a Service Request against all the eligible products. You can also review and update a Support Request and attach log support bundles or other attachments.

Figure 4: View or Create a Technical Support Request.

After selecting the option “Create a New SR”, the user is prompted to select the account associated with their My VMware account as well as the product related to the issue.

Figure 5: Select Account and Product.

Once the account and product are selected, the user is prompted to describe the problem. Knowledgebase Articles will appear for the user as they do on My VMware.

Figure 6: Describe the Problem and Suggested Resources.

Next, the user is prompted to provide the severity level based on business impact, category, detailed description, etc in the Contact and Support Request Details.

Figure 7: Contact and Support Request Details.

Once the creation of the Technical Support Request is completed the user receives a on-screen confirmation with the support request number.

Figure 8: Create Support Request Confirmation

Uploading Diagnostics

After the new Technical Support Request is created, the user is prompted to either upload or finish the task. It is highly recommended that the user collect and upload the diagnostics immediately and attaches them to the support request to expedite support. So, let’s select “Yes – Upload” from the Create Support Request Confirmation to initiate the collection from the desired hosts.

Figure 9: Select Hosts.

Next, the user is prompted to select the System Logs desired for the diagnostics bundle as well as the option to collect performance data.

Figure 10: Select System Logs and Performance Data Option.

Once the user has selected the hosts and system logs, they are asked to confirm and initiate the upload procedure. This upload is run in the background and all transfers are sent via HTTPS to VMware from the VMware vCenter Support Assistant virtual appliance.

Figure 11: Confirm and Initiate Upload.

Once the user selects to start the collection and upload, the following dialog is presented. This dialog presents the status of the log collection progress for the support request. This dialog can be closed with the “X” and the collection and upload will continue as a background process, which we will show in a moment. Please note, the vSphere Client / vSphere Web Client should be open till the logs are fully downloaded and upload starts. Uploading of logs is handled in the background and the user does not need to be logged into vSphere Client / vSphere Web Client.  If the dialog remains open and collection and upload completes, the user will be prompted with a completion status dialog.

Figure 12: Log Collection Progress.

The collection and upload progress can also be checked by selecting “Upload Activity” in the top right navigation. This will display the status, start and end date/time on all recorded uploads.

Figure 13: Upload Activity.

Viewing Technical Support Requests

Let’s take a moment to view and update an existing Technical Support Request by selecting “View / Modify Existing SR” from VMware vCenter Support Assistant solution home screen.

Figure 14: View or Create a Technical Support Request.

After selecting “View / Modify Existing SR” the user is displayed a list of technical support requests linked to their My VMware account. Notice that support request 12217135709 created earlier is listed and highlighted. The user is able to view the details of the request, initiate diagnostics collection, and add attachments with ease.

Figure 15: Select Support Request. Get Details, Collect/Upload Diagnostics and Add Attachments.

By selecting “Details” the user is able to view the details of the support request as well as add additional comments.

Cool FeatureNotice that VMware vCenter Support Assistant adds a comment to the support request notes confirming the upload of diagnostics to VMware.

Figure 16: Support Request Details.

By selecting “Upload Attachment” after selecting a case from the Select Support Case screen, the user can provide additional information to the engineers, such as screenshots, diagrams or other logs.

Figure 17: Add Attachments.

Ryan JohnsonRyan Johnson is a Senior Technical Account Manager in Professional Services at VMware. Ryan is a member of the VMware Technical Account Manager Program and provides cross-functional advisory and customer advocacy services, backed by the full resources of the VMware organization. He and other members of the team partner with customers to help realize their success with VMware solutions, accelerate their return on VMware investments and mitigate risk. Find out more about the VMware Technical Account Manager Program at vmware.com/go/tam/.

Follow the VMware Technical Account Manager Program on Twitter as @VMwareTAM and follow Ryan @tenthirtyam

. Bookmark the

.