I originally had TA2441, VI3 Networking Concepts and Best Practices, on my schedule, but upon a close review of the agenda it looks like this is all stuff I’ve seen before. In fact, it looks like stuff I’ve written about quite extensively, so I’m skipping out on this session. Sorry to disappoint anyone!
You are currently browsing the monthly archive for September 2008.
Tags: Networking, Virtualization, VMware, VMworld2008
This is the liveblog for TA2644, Networking I/O Virtualization, presented by Pankaj Thakkar, Howie Xu, and Sean Varley.
The session starts out with yet another overview of VDC-OS. This session will focus on technologies that fall into the vNetwork infrastructure vService. The agenda for the session includes networking I/O virtualization, virtualized I/O, and VMDirectPath.
Starting out, the presenter first defines what exactly networking I/O virtualization is. Networking I/O virtualization is providing muxing/demuxing packets among VMs and the physical network. VMs need to be decoupled from physical adapters, and the networking I/O virtualization must be fast and efficient.
Now that the audience has an idea of what networking I/O virtualization is, the presenter changes focus to talk about the architecture that provides I/O virtualization. First, there is a virtual device driver that can either model a real device (e1000, vlance) or that can model a virtualization-friendly device (vmxnet, a paravirtualized device). I’m glad to see the vendor refer to this as a paravirtualized device, since that’s really what it is.
Below the virtual device and virtual device driver, there is the virtual networking I/O stack. This is where features like software offloads, packet switching, NIC teaming, failover, load balancing, traffic shaping, etc., are found.
Finally, at the lowest layer, are the physical devices and their drivers.
The next discussion is tracing the life of a received packet through the virtualized I/O stack. After tracing the life of a packet, the presenter discusses some techniques to help reduce the overhead of network I/O. These techniques include zero copy TX, jumbo frames, TCP segmentation offload (large send offload and large received offload).
The problem with using jumbo frames, though, is that the entire network must be configured to support jumbo frames. Instead, the use of TSO (or LSO, as it is sometimes known) can help because it pushes the segmentation of data into standard size MTU segments down to the NIC hardware. This is fast, but even a software-only implementation of TSO can provide benefits.
(As a side note, it’s difficult to really understand the presenter; he has a very thick accent.)
On the receive side, the technology called NetQueue is intended to help improve performance and reduce overhead. When the NIC receives the packet, it classifies the packet into the appropriate per-VM queue and notifies the hypervisor. The presence of multiple queues allows this solution to scale with the number of cores present in the hardware. It also looks like NetQueue can be used in load balancing/traffic shaping, although I’m unclear exactly how as I didn’t understand what the presenter said.
Zero copy TX was discussed earlier (copy the packet from the VM directly to the NIC), but there was no discussion of zero copy RX. With NetQueue and VM MAC addresses being associated with the various queues, it’s also possible to do zero copy RX. The caveat: the guest can access the data before it is actually delivered to it.
The focus on the presentation now shifts to a discussion of VMDirectPath, or I/O passthrough. This technology initiative from VMware requires hardware I/O MMU to perform DMA address translation. In this scenario, the guest controls the physical hardware and the guest will have a driver for that specific piece of hardware. VMDirectPath also needs a way to provide a generic device reset; FLR (Function-Level Reset) is a PCI standard that provides this.
SR-IOV (Single Root I/O Virtualization) is a PCI standard that allows multiple VMs to share a single physical device. If I understand correctly, this means that VMDirectPath will allow multiple VMs to share a single physical device via SR-IOV. Part of SR-IOV is creating virtual functions (VF) that the guest sees and mapping those to physical functions (PF) that the physical hardware controls and sees.
Challenges with VMDirectPath include:
- Transparent VMotion: Because the guest controls the device, there’s no way to control device state, so VMotion won’t be possible. This is logical and fully expected, but certainly has an impact on the usefulness of this technology.
- VM management: Users are now placed back into the issue of managing device drivers into VMs based on the hardware to which they are connected.
- Isolation and security: A lot of the features provided by the hypervisor (VMsafe, MAC spoofing, promiscuous mode, VMware FT, etc.) are lost when using VMDirectPath.
- No memory overcommitment: Physical devices will DMA into the guest memory, but this requires that memory overcommit is disabled so that this works.
Although these limitations around VMDirectPath are significant, there still can be valid use cases. Consider appliance VMs or special purpose VMs, such as a VM to share local storage or a firewall VM, where technologies like VMotion or VMware FT aren’t necessary or aren’t desired.
Generation 2 of VMDirectPath will attempt to address the challenges described above. One way of accomplishing that is called “uniform passthrough,” in which there is a uniform hardware/software interface for the passthrough part. This allows a transparent switch between hardware and software from the hypervisor while the guest is not affected or even aware of the mode. This puts the control path under the control of the hypervisor, but bypasses the hypervisor for the data path.
This Gen2 implementation allows for migration because the mode is switched from direct to emulation transparently and without any special support within the guest OS.
Another way of implementing is described by Sean Varley of Intel. This method is called Network Plug-in Architecture. Most of the functionality in this solution is embedded inside the guest device driver, which typically would be VMware’s paravirtualized vmxnet driver. Sean underscores the need for SR-IOV support in order to really take advantage of VMDirectPath, because it doesn’t really scale otherwise.
This particular solution consists of a guest OS-specific shell and an IHV-specific hardware plug-in. The interface of the guest OS-specific shell will be well-known and is the subject of a near-future joint disclosure between Intel and VMware. The plug-in will allow various other IHVs to write software that will allow their hardware to be used in this approach with VMDirectPath.
This plug-in also allows for emulated I/O, similar to what ESX offers today, in the event that SR-IOV support is not available or if the user does not want to use VMDirectPath. Upon initialization, the guest OS shell will load the appropriate plug-in and (where applicable) create a VF that maps onto a VMDirectPath-enabled physical NIC.
Migration in this scenario is enabled because the hypervisor remains in control of the state of the shell and the plug-in at all times. The hypervisor can reset the VF, migrate the VM, and then load a new plug-in on the destination via the initialization process described earlier.
The key advantages of this particular approach are IHV independence, driver containment, and hypervisor control. This enables IHV differentiation and removes the VM management headache described earlier (VMs won’t need hardware-specific drivers). Hypervisor control is maintained because the SR-IOV split model of VF/PF is maintained, and the hypervisor controls plug-in initialization and configuration.
The session ends with a sneak preview demonstration of a migration using the plug-in architecture and VMDirectPath, migrating a VM between an SR-IOV-enabled NIC and a non-enabled NIC on a separate host. The presenter showed how the vmxnet driver loaded the appropriate plug-in based on the underlying hardware.
Tags: Networking, Virtualization, VMware, VMworld2008
There is no general session this morning at VMworld 2008; instead, a “keynote” will be delivered about automating disaster recovery (DR) using VMware Site Recovery Manager (SRM). This is similar to the way in which other vendors have delivered various “keynotes” throughout the conference instead of all the announcements being crammed into the morning general sessions.
The speaker this morning is Jay Judkowitz, the product manager for VMware SRM. I’ve met Jay before; he’s a good guy. There’s a small technical glitch as the session begins because the slide deck doesn’t come up, but that gets resolved within only a few minutes and Jay begins his presentation.
The presentation begins with yet another overview of the VDC-OS vision; SRM is considered one of the vCenter management vServices. Jay then goes on to address all the various ways in which VMware provides application availability for applications hosted on VMware Infrastructure. This would be technologies like VMotion, VMware HA, VMware DRS, VMware FT, NIC teaming, storage multipathing, and of course Site Recovery Manager.
The traditional challenges of DR (including complex recovery processes and procedures, hardware dependence, inability to test extensively or repeatedly) are all addressed by VMware SRM. More accurately, they are addressed by the products that form a foundation underneath VMware SRM. Features like hardware independence, encapsulation, partitioning and consolidation, and resource pooling. These features have a direct play in a DR environment. It’s funny to see Jay taking this particular approach; it’s almost like he’s using the same slide deck that I’ve used in DR presentations given over the last couple of months.
That finally brings the discussion around to Site Recovery Manager specifically. Jay goes over some of the features of SRM, and discusses some “do’s and dont’s” for SRM. For example, SRM isn’t really intended to provide failover for a single VM, although you can architect it to do that (put that VM on a single LUN by itself and create a Protection Group for that LUN and VM, then craft your Recovery Plan).
It’s important to note that SRM is not a replication product, but instead relies upon replication products from supported partners. This is done via the Storage Replication Adapter (SRA), a piece of software written by the storage vendor.
When setting up SRM, there are number of steps that it goes through. First, you have to integrate with the storage replication in place already (and yes, the storage replication needs to be in place already). Next, you need to map recovery resources; this creates the link between resources used in the Protected Site to resources that will be used in the Recovery Site. Third, you need to create Recovery Plans, which is the automated equivalent of the DR runbook. That is, the Recovery Plan defines which VMs will failover, in which order, at the Recovery Site. That’s a bit of simplistic overview but it does get the point across.
At this point, I’ve decided that I’m going to try to get into a different session. I’m quite familiar with SRM, a lot of readers are probably familiar with it as well, and it doesn’t look like there is anything new that will be revealed here. For those readers that aren’t familiar with SRM, let me know in the comments. If there’s enough interest, I’ll write something separate after my return from VMworld 2008.
Tags: Virtualization, VMotion, VMware, VMwareFT, VMwareHA, VMwareSRM, VMworld2008
As I fully expected, another day at VMworld 2008 has passed and I seriously, seriously was not able to keep up with everything. I even blew off a session this afternoon that I really wanted to attend as well. Somebody, please—can you give me good session notes on TA2275, VMware Infrastructure Virtual Networking Future Directions? I’d be very grateful!
In any case, here’s a round-up of more coverage of VMworld 2008 from various places around the Internet:
Brian Madden
Alessandro Perilli
Live from VMworld 2008: Day 2 – VMware Keynote
Rich Brambley
VMworld 2008 General Session Day 2
Linux Strategy and Roadmap #TA3201
Matthias Müller-Prove
Sun Ray Connector for VMware VDM certified
Colin McNamara
Altor Virtual Network Security Analyzer (VNSA) integrated with Cisco’s Nexus 1000v for VMware
Rick Blythe
Bob Plankers
VMworld 2008 Day 2 General Session
Virtualfuture.info
VMworld 2008 – Wednesday general session
VMworld 2008 – Tech preview: vCenter Orchestrator
Virtualization.com
VMworld 2008 – VMware CTO Dr. Stephen Herrod Keynote liveblog
Bill Petro
VMworld 2008: Day 2 Review – Virtually Anything is Possible
I guess that should about do it for today. Go have a look at some of these other articles; they captured information that I missed, and many of them have photos and shots of the keynote or other information. Enjoy!
Signing off for today…
Tags: Virtualization, VMware, VMworld2008
Yesterday, September 16, 2008, the Distributed Management Task Force (DMTF) announced the release of the Open Virtualization Format (OVF) standard, along with a new management initiative called the Virtualization Management Initiative (VMAN). The full details are found here in the official press release.
<aside>Now, personally, I think they should have called it the vMan initiative so that we could continue the lowercase “v” thing that’s going on here at VMworld this year.</aside>
Anyway, a number of vendors have announced support for the VMAN initiative, including AMD, Broadcom, Citrix, Dell, HP, IBM, Intel, Sun Microsystems, Symantec, and VMware.
The DMTF site doesn’t really provide much detail about VMAN, other than to throw up some decidedly marketing-like terms:
The Virtualization Management Initiative (VMAN) from DMTF unleashes the power of virtualization by delivering broadly supported interoperability and portability standards to virtual computing environments. VMAN provides IT managers the freedom to deploy pre-installed, pre-configured solutions across heterogeneous computing networks and to manage those applications through their entire lifecycle. Management software vendors will offer a broad selection of tools that support the industry standard specifications that are a part of VMAN, thus lowering support and training costs for IT managers.
OK, but can you provide any real technical details? Exactly how is VMAN going to do this? Perhaps the PDF-based VMAN and OVF technical notes will contain more details, but until I see those this continues to look more like a marketing exercise than anything else. Sorry, I have to call it like I see it.
Tags: Citrix, Virtualization, VMware, VMworld2008, Xen
This is TA2659, Managing ESX in a COS-less World. The focus here is on tools that allow you to manage ESX without using the Service Console.
When I arrived at the session, the presenter was discussing VMware’s goal to drive parity between the “actual” CLI present in the Service Console and the Remote CLI. There is a desire to ensure that any command that can be run on ESX or ESXi can also be run on the other.
Another tool to use in managing ESX without the Service Console is the VI Toolkit for PowerShell. I’m sure that most readers are already familiar with the VI Toolkit, so I won’t go into any great detail there. There are about 120 cmdlets or so in the Toolkit today; another 50 or so are slated for release in the next version of the VI Toolkit. In addition, VI Toolkit management/compatibility is a core design facet—everything needs to be manageable via the VI Toolkit.
The VI Perl Toolkit is another scripting toolkit that can be used to manage ESX without relying upon the Service Console. This works on both Linux and Windows, where as the VI Toolkit only works on Windows. The vicfg-* tools are built on Perl.
Future directions include enhancements to the VI Perl Toolkit to expose functionality as Perl functions. A VI Java Toolkit will be available soon (within a month?). Other toolkits may become available depending upon market demand and direction.
From the perspective of server health monitoring, CIM SMASH is the direction in which VMware is moving. CIM (Common Information Model) is both a protocol and a data model representing functionality. SMASH (Systems Management Architecture for Server Hardware) is the data model for hardware health monitoring and management. An example of a tool that works with CIM SMASH is WinRM, which ships on Windows Vista and presumably Windows Server 2008. CIM SMASH profiles simply define the sensors and the values that should be retrieved for various hardware elements.
A fair amount of CIM SMASH functionality was exposed in ESX 3.5 Update 2. This is done per-host; in the future, VirtualCenter will aggregate that for multiple hosts.
An attendee asked a question about varying degrees of hardware monitoring being exposed in the initial release of ESXi and CIM support within both ESXi and the underlying hardware. The response is that this functionality is driven by both SIM providers, which are written by either VMware or the hardware vendor; in most cases, it’s VMware ESXi that needs to beef up the SIM providers.
In the future, the vision of VMware is to abstract the configuration into a configuration file. This configuration template could then be applied to multiple hosts, and the configuration can be assessed regularly to verify configuration, compliance, etc. The information required to do all this is already being handled by the web services API in VirtualCenter, and the tools necessary to perform the configuration are already present in the API (the esxcfg-* and vicfg-* commands already leverage the API to do these very tasks). Combining these two things would allow us to create a configuration template that can be applied to a host while still allowing for customization (like VM customization during cloning).
The subject of deployment is a key issue when we think about losing the Service Console. One approach to handling these issues is deploying physical machines; another would be to deploy virtual machines to handle these tasks. Partners could wrap up the agents that would typically be deployed in the Service Console as a virtual appliance, but then users could end up with numerous virtual appliances. What if VMware were to provide a virtual infrastructure management appliance? That’s what VIMA (Virtual Infrastructure Management Assistant) is.
VIMA is a virtual appliance packaged as OVF and is distributed, maintained, and supported by VMware. This is downloaded and installed by the customer according to their management procedures. This will be a well-known deployment environment that partners can rely upon being present. This will be a 64-bit Linux distribution with VMware Tools, VI Perl Toolkit, the Remote CLI (now known as the VI CLI), and a JRE already present. VIMA can be patched for updates, and it allows you to manage one or more VMware ESX hosts directly or through VirtualCenter. VIMA can enable agents to authenticate themselves, and VIMA will rotate its passwords on the hosts. Additionally, sample code and documentation will be available for programming applications to work in VIMA.
In “classic” ESX, management agents and hardware agents ran in the Service Console; with VIMA, updated management agents will talk through the VI API and hardware agents will talk through CIM SMASH. An example of this is the APC PowerChute Network Shutdown (PCNS), which is being rewritten to use the VI API and will run in VIMA.
Anyone interested in VIMA can e-mail vima_request@vmware.com and request access to pre-GA versions of VIMA. VIMA is expected for general release in the fourth quarter of this year. All VIMA releases will work with both ESX and ESXi (again, pointing to the desire to keep parity between these two products).
Future versions of VIMA may add Active Directory support; authentication through vCenter Servers; improved automation, configuration, and updates; UI integration in the VI Client; additional VMware components pre-installed. Finally, VMware Studio will be used to build future versions of VIMA.
At this point, the presentation ended and the floor was opened up for a question and answer session.
Tags: CLI, ESX, ESXi, Hardware, Virtualization, VMware, VMworld2008
This is VD2422, and the presenter is Chris Leroy from VMware.
I arrived at this session late (about 15 minutes late) after running into a customer in the Solutions Exchange. This session is about offline VDI, which is the ability for users to check out VMs and run them while disconnected from the “traditional” VI environment.
As I came in, the presenter was showing off the check-out process, in which the user uses the VDM Client to check out a VM. As part of that check out process, the VM is copied to the client. Depending upon the size of the VM, this may take some time. VI administrators will also see a variety of tasks that get spawned as a result of checking out a VM, and controls for that VM such as pause, resume, power off, power on, etc., are all disabled while the VM is checked out.
The menus in the VDM Client are context-sensitive; the menus change from “Check Out” to “Check In” depending upon the status of the VM. Other commands may also appear based on the status of the check-in/check-out process itself. For example, there is a “Cancel Check Out” during the process of checking out a VM.
VirtualCenter uses snapshots as a “checkpoint” for the check-out/check-in process. By using snapshots in this way, the check in process is incremental, meaning that only the changed data needs to be transmitted back to the VI environment.
One thing that I didn’t see during the check-in/check-out demos and description was the use of the “fast start” VMDK streaming technology that was discussed last year in San Francisco at VMworld 2007.
Next the presenter showed how to use policy to control access to checking out a VM. For example, an administrator can set a policy that prevents a user from checking in an offline VM; in this instance, the user essentially has to “throw away” changes made while the VM instance was offline.
In addition, the offline VM functionality uses encryption technology—presumably taken from VMware’s ACE product offering—to secure the data while it is outside the VI environment. Even the client-side UI looks exactly like stuff taken from VMware ACE and VMware Player. (This isn’t necessarily a bad thing, by the way; it shows that VMware is leveraging additional products, like they should.)
The presenter was using a variety of video clips to demonstrate the functionality; in the next clip, he showed the VDM Connection Server being shutdown to simulate a user actually being disconnected or away from the corporate network. In this instance, the VDM Client recognizes that it no longer has a connection to VDM and certain actions are disabled as a result.
Getting into the technical details, the offline VM is a full copy of the VM that is encrypted using 128-bit AES encryption. Authentication through VDM Client is required; you can’t run the VM in ACE, Player, or Workstation, and it can only run on the client device to which it was copied.
Access to an offline desktop is controlled via Active Directory and entitlements. VDM includes policies to control offline desktops; these policies include whether or not a VM may even be checked out, how long a VM may remain checked out until it needs to contact the VDM server, whether or not USB devices or printing is allowed, whether a user is allowed to perform a rollback, or whether Single Sign On is permitted.
Regarding VDM authentication (note that VDM authentication is required in order to run the offline desktop), the VDM client creates an offline challenge built on the last successful online authentication. I’m glad the presenter discussed that; I was wondering how that would be handled.
As expected, the VDM client will periodically try to reconnect and update policies.
When authentication occurs offline (using the offline challenge), a full online authentication may be required in order to perform sensitive operations. Authentication using RSA, for example, might be required after an offline authentication once connectivity is re-established.
Offline VDI uses a stripped down version of VMware Player, and requires the full Win32 VDM Client (you can’t use the web interface). On the server side, VMs are locked when they are checked out. VDM also knows how to speak to VI, but APIs had to be extended to allow check-in/check-out and to build logic around how to handle checked-out desktops.
Data is transferred using the same VMware internal protocol that VMware Converter and VI cloning/provisioning uses when data is transferred between the client and a VMware ESX server. Only changed blocks are transferred, although some file system optimizations are used. There is some support for data compression, can be paused or resumed, and can travel inside SSL via the VDM Secure Gateway.
When multiple transfers are in place, the load is balanced across VMware ESX server according to a calculation of “transfer slots”. VMware ESX servers can be configured with how many transfer slots they are given.
The flow of a checkout request:
- Client sends a checkout request
- VDM server validates the request (checks the policies, verifies the disk space that the client needs, qualifies the VM configuration)
- VDM then powers down the VM, takes a snapshot of the VM, enumerates the data that the client needs, and the generates a new VM configuration based on the existing VM on the VI environment
- The client merges the new offline desktop configuration with any existing configuration
- The client transfers the data it needs, as determined by the enumeration process earlier
A check-in request is a bit simpler:
- Enumerate the data in the offline desktop’s disks that need to be transferred back to the server
- Transfer the data back to the server
- Remove the lock on the desktop
There are a few limitations. Only Windows XP is supported, and small number of concurrent check-ins and check-outs are supported. There is no support for non-persistent desktop pools, and there is no support for View Composer (Scalable Virtual Image, or SVI).
For future enhancements, VMware is considering the use case when the user primarily works from the client desktop. In this instance, check-in processes are more likely to be background processes that should be initiated automatically. These are essentially considered to be restore points or for alternative access. This use case could extend the reach of VDI quite extensively.
More future work is being spent on integration between offline VDI and View Composer. Finally, consideration is being given to allowing offline VDI to work on platforms other than Windows, such as Mac OS X or Linux (note that earlier it was stated that the Win32 VDM Client is required for offline VDI).
At this point, the presenter closed the session.
Tags: VDI, Virtualization, VMware, VMworld2008
Now that the keynote has wrapped up, I just wanted to post a few very brief thoughts, perhaps questions, about the keynote and the technologies and initiatives discussed.
First off, as I have seen others point out on the VMworld Twitter broadcast channel, I wonder how well AppSpeed’s remediation functionality would work with applications other than web-based applications. Not all applications can scale using additional VMs. Sure, you can generally scale web-based applications by throwing on more web server VMs, but what about Microsoft Exchange 2007? Or SQL Server 2008? Or some other database server? I speculated in the keynote liveblog that perhaps the hot-add functionality that VMware is supposed to be adding to future versions of ESX/ESXi will help, but there’s been absolutely no discussion of that. At least, not that I’ve seen.
I also briefly mentioned in the keynote liveblog that I wonder how well some of these technologies would work in the offline VDI scenario.
Finally, there seems to be some feature/functionality conflicts between stuff like vStorage Thin Provisioning and VMware FT that have yet to be resolved. Granted, this is all prototype/pre-beta stuff so VMware has time to resolve this.
What about you? What kinds of things like this have you spotted?
Tags: VDI, Virtualization, VMware, VMworld2008
Today promises to be an easier keynote, since I actually managed to find the bloggers’ tables (they actually exist) and get good wireless connectivity. In addition, today’s keynote should be more technical and feature-focused than Paul’s keynote yesterday. Refresh this page often, as I’ll be updating this post throughout the keynote.
The keynote starts off with a series of video testimonials about VMware’s drive forward in technology, about how applications are served better, about how availability is improved, etc.
Afterwards, Dr. Stephen Herrod, CTO and Senior VP of R&D for VMware takes the stage. Stephen indicates that he’s going to follow up with technical details on VDC-OS, vCloud, and vClient. He describes VDC-OS as a set of roadmap initiatives that will drive forward technologies to achieve the goals that Paul described yesterday in his keynote.
Focusing first on the infrastructure layer, he indicates that the goal is to aggregate resources and allocate them to workloads efficiently and appropriately. In the vCompute area of the infrastructure layer, Stephen first indicates that one area is beefing up individual VMs. The goal for VM scalability in the vCompute area is to hit 8 vCPUs, 256GB of RAM, 40 Gbps of network throughput, and 200,000 IOPS.
However, extending the power of individual VMs isn’t enough. VMware needs to do even more in terms of aggregating vCompute resources, enabling clusters containing up to 64 hosts with up to 4,096 processor cores, etc. All of this will be load balanced using VMware DRS.
Dr. Herrod next discusses DPM (Distributed Power Management) to reduce power consumption. He did not indicate when DPM will move out of experimental support.
Moving on to the next infrastructure area, vStorage, the idea here is to fit VMware Infrastructure and partner storage together in a way to leverage partner-specific features. vStorage encompasses the intersection of VMware-created technologies, like VMFS and Storage VMotion, and partner-enabled technologies. New features that are being announced include thin provisioning and linked clones. These types of functionality often exist in partner storage arrays as well, and can sometimes be performed more quickly or more efficiently.
First up with more detail is vStorage Thin Provisioning. It appears that the key focus is on alerting and reporting frameworks to protect customers from overallocating. Dr. Herrod refers to the vStorage APIs; I think this is the first time I’ve heard it referenced that way, but it does make sense. Still no word on the potential interaction between thin provisioning and VMware FT.
vNetwork is up next as Stephen continues working through the infrastructure vServices. The focus here is much like with vStorage, in that VMware wants to leverage partner technologies and functionality. The discussion starts with a look at today’s networking functionality (per-host vSwitches), then moves into the vNetwork Distributed Switch. (I wish they’d make up their mind what this will be called, as I’m seeing several different names.) He brings out the first major discussion of Network VMotion, which will bring the ability to move a VM’s network state between hosts on the Distributed Switch.
Yesterday Cisco announced the Nexus 1000v yesterday, and Dr. Herrod points to this as an example of how VMware and Cisco worked together to leverage open APIs in VMware’s products to extend the functionality of the solution.
At this point, Dr. Herrod wraps up his discussion of infrastructure vServices into a discussion of application vServices, and indicates that these functions and features are intended to be provided in an application-neutral way that will work with applications today and tomorrow, unmodified.
Stephen revisits the idea of the vApp, confirming that it is based on OVF. vApps may wrap together multi-tier applications, and the metadata embedded in the vApp can be applied to all the tiers in the multi-tier application. The most commonly mentioned metadata is SLA.
Availability is a key focus out of the application vServices. Dr. Herrod walks through the various technologies that VMware has created over time to help improve availability, both from a planned and an unplanned perspective. This includes stuff like NIC teaming, storage multipathing, VMotion, Storage VMotion, VMware HA, and Site Recovery Manager. The new feature that Stephen announces is VMware Fault Tolerance (FT), which is intended to protect against unplanned server failure. He distinguishes VMware HA from VMware FT by indicating that VMware HA is stateless and reboots the workloads in the event of a failure. I discussed VMware FT in-depth in yesterday’s session notes, so I won’t bother to go into a lot of detail here. Next we’ll see a demonstration of VMware FT in action.
Mark Vaughn, of First American Corporation, takes the stage to discuss his experience with VMware FT. The demo shows an application being protected, first by showing how to enable VMware FT. Mark demonstrates turning FT on by a simple right-click operation within VirtualCenter. At this point, the secondary VM is being created using a special VMotion; all this is being represented in VirtualCenter’s Tasks pane during the demo. Once the secondary is created, vLockstep will keep the two VMs in synchronization. Mark points out the new VMware FT pane, which shows the status and the host running the secondary VM. Now that VMware FT is running, Stephen will “accidentally” power off one of the servers. As shown on the stage, the slot machine VM continues running, and VirtualCenter automatically spawns a new secondary VM and re-enables VMware FT protection for the VM.
Now we move on to security application vServices, and Dr. Herrod takes us back to the vApp and indicates that security policies may be embedded in the vApp’s metadata. VMsafe is the underlying building block that allows security vServices to be created. The functionality enabled by VMsafe and security vServices enables potentially higher levels of security, since the security VMs that are running using these APIs can see both network traffic and process activity, and can correlate that data to provide better protection.
The distributed vSwitch also enables greater security because network state is maintained after a VMotion operation (what is referred to as Network VMotion). And, of course, partners will use the VMsafe APIs (why not call them vSecurity APIs?) to build a wide variety of solutions.
That wraps up the discussion of application vServices, and now he turns to management vServices. That means a discussion of vCenter. He discusses ConfigControl, vCenter Orchestrator, CapacityIQ, and Chargeback. These solutions extend the functionality of vCenter, and all of these APIs that partners can use to build their own solutions.
vCenter AppSpeed is another application management vService that VMware will continue to develop. This is built on the B-Hive acquisition. It works by discovering workloads and applications based on network traffic, the monitor them, and remediate application performance problems when necessary. Dr. Herrod mentions remediation, but I’m skeptical because not all applications can be scaled in the way in which they demonstrate. Some applications can scale (web-based front-ends, for example), but many cannot. AppSpeed won’t really be able to do much in those cases, in my mind.
Asaf Wexler, founder of B-Hive, now takes the stage for a demo. They’re using SugarCRM, a web-based application. Asaf shows how AppSpeed dynamically discovers the various components of the SugarCRM application as he works within the application. AppSpeed is even discovering and mapping database tables and specific queries as he uses the application. Asaf next moves on to demonstrating the UI for monitoring the application within VirtualCenter, and then discusses how remediation is handled. Through the demonstration, Asaf shows how it’s not the application, not the resources allocated to the application VM, but instead the database VM. Utilizing hot-add technology that VMware is slated to include in future versions, additional resources could be applied to database VM to help resolve the issue.
Dr. Herrod points out that these features will be exposed via APIs for partners to leverage as well.
VirtualCenter Server is being ported over to Linux and being packaged and delivered as a virtual appliance. The crowd was very excited about that (lots of applause). In addition, VMware is working on multi-platform vCenter client, including Linux, Mac OS X, and other form factors. He jokes about using the iPhone’s accelerometer to trigger a DR failover.
Stephen next moves on to discussing the cloud. He does recognize that the term “cloud” is over-used and over-hyped. He describes some basics that define the cloud, and ties that to what VMware is doing with VDC-OS to address the challenges of creating a “cloud”. Those challenges include application compatibility, lack of standardization, complexity and switching costs, a the need for new flexible, efficient infrastructure. Stephen seems to believe that OVF will help remove some of these standardization issues. Multi-tenancy is another key issue. All of these issues are being addressed in VDC-OS and the vCloud initiative.
vCloud will contain various APIs that address tasks like image management, user accounts, consistent chargeback mechanisms, and mobility. Mobility isn’t necessarily about “Cloud VMotion” but also about moving between clouds, internal or external.
Stephen again revisits the vApp concept and OVF. vApp and OVF are considered to be an significant enabling technology in providing cloud federation.
Finally, he switched to the vClient initiative. The key thing here is switching the view from hardware to users and information. A user’s “desktop” is really nothing more than a collection of applications and information. This view also needs to encompasses multiple access points, and all of this needs to be managed and secured. The vClient initiative is less about new technologies and more about evolving and extending VMware’s 10 year history in client virtualization in three key areas: user experience, client virtualization, and centralized management.
With regards to user experience, the goal is to drive the user experience to the best possible level based on connectivity. VMware has been really driving user experience in the client virtualization area, where features like Unity and 3-D graphics. In the client virtualization area, VMware also wants to drive a thin hypervisor to provide bare metal virtualization, easy provisioning, and rich user experience. But this all ties back to centralized management, where we can control provisioning, image updating, and policy enforcement.
Next Jerry Chen of VMware takes the stage to discuss VMware View and the linked clones (vStorage Linked Clones). The first task in the demo is to create 25 desktops very quickly. This will be done very quickly and with tremendous storage savings.
The next task in the demo is to modify the image to include Google Chrome, as an example of updating images after they have been deployed. Jerry shows off his personal “desktop” running on the bare metal client hypervisor. Using VMware ThinApp, Jerry deploys Google Chrome, then recomposes the linked clones to include the changes he just made. His laptop gets a notification, he restarts and Google Chrome appears in his linked desktop image.
The third and final task for Jerry’s demo is to show off policy enforcement. The example is revoking access to a distributed VMs. Using View Manager, Jerry edits the policy and denies access to the desktop. A warning pops up and the VM is shut down. Access to the VM has been revoked. Note that in all these demos network connectivity to VMware View Manager was assumed; it would be interesting to discuss how these features operate in a disconnected mode.
Dr. Herrod wraps up the keynote with a summary of the three major initiatives: VDC-OS, vCloud, and vClient. At this point the keynote wraps up.
Tags: Virtualization, VMware, VMworld2008
Clearly, I am having a much harder time covering VMworld 2008 than I had covering Tech-Ed or VMworld 2007. There’s just so much going on! In an effort to try to broaden the coverage, here are some links from other bloggers and resources:
Duncan Epping
vCenter (good overview of what vCenter is)
Expand Virtual Desktops with VMware View
Chad Sakac
So, what does vStorage really mean?
Rich Brambley
New VMware VDI features enable VMware View
VMware View enables new vision of VDI with a Universal Client
VMware’s vCloud initiatives: The vision for the next 10 years
VMworld 2008 Tuesday Opening Keynote
Q&A with Paul Maritz
VirtualCenter Directions #TA3807
Joint VMware and NetApp Best Practices for Running VI3 on IP Based Storage #TA2784
Re-architecting Data Protection Processes with Data Deduplication and Virtualization Technologies #BC3819
Colin McNamara
Cisco releases Nexus 1000v virtual switch for VMware
Christofer Hoff
VMworld 2008: “Introducing Cisco’s Virtual Switch for VMware ESX…”
Bill Petro (Tech Trends)
Bob Plankers
I think that’s it for now, although I’m sure that I’m missing tons of additional coverage. Other bloggers, if I missed you—and rest assured no one was excluded intentionally—please add links in the comments below. It would be great to consolidate as many relevant links as possible. Thanks!
Tags: Virtualization, VMware, VMworld2008
Site Sponsors
Support My Books!
Additional Site Sponsors
Recent Bookmarks
- EMC Storage Product (CLARiiON|Symmetrix Series|SAN Solution|Network Attached Storage|SAN Product|Knowledge Sharing)
- VMware KB - Avoiding replication of paging files and other transient data in Site Recovery Manager
- .osx at master from mathiasbynens/dotfiles - GitHub
- VMware KB - vCloud Director 1.5 and stretched cluster architectures
- VMware KB - Enabling centralized logging of vCloud Director cell logs
- Open source anti-theft solution for Mac, PCs & Phones – Prey
- VMware KB - Fast Provisioning in VMware vCloud Director 1.5
- Tibor Karaszi's SQL Server pages
- VMware KB - Implementing vSphere Metro Storage Cluster (vMSC) using EMC VPLEX
- Useful Mac OS X Commands
Other Links
Recent Comments