While SCVMM 2007 had good integration with Ops Manager, SCVMM 2008 has gone to the next level with our Performance and Resource Optimization feature (PRO). In a nutshell, PRO allows you to tie specific Ops Manager alerts to actionable remediation actions. For example, you might want to load balance VMs between physical hosts when specific thresholds are exceeded (transactions per second, CPU utilization, email message delivery SLA etc.). Alternatively, you might want to migrate VMs when a hardware failure is detected, like a fan failure for example. PRO is fully extensible since PRO itself is simply an extension of the existing Operations Manager management pack infrastructure. Once PRO finds an opportunity for optimization, it generates a PRO tip which comes complete with the remediation script baked in. Admins can manually approve the PRO tip for implementation or set PRO up to automatically implement tips on all or a subset of your environment.
Furthermore, we wanted to ensure that the person in front of the SCVMM console didn't have to go to the Ops Manager console every time a PRO tip is generated to provide a more seamless user experience. We wanted admins to get access to this information directly through the SCVMM UI which is what you see when you click on "PRO Tips" in SCVMM 2008 - Ops Manager generates the PRO tip and publishes it back to SCVMM. Of course, the Ops Manager UI will show the corresponding alerts as well so the information remains consistent.
In the beta release of SCVMM 2008, the initial configuration of PRO was a little bit more cumbersome than we liked so in the final release, we've simplified this by incorporating a "Configure Operations Manager" option to our setup splash screen. When you run our setup on your Ops Manager machine and select this option, SCVMM installs the our admin client and Powershell infrastructure locally, configures security and also imports the required management packs required to run PRO. You then run the Ops Manager client installation on the VMM box and voilà, you can now share information securely between the two systems and take full advantage of PRO.
You'll see tighter integration between the System Center family as a common theme in future System Center releases, this is just the tip of the iceberg.
Rakesh
Big day for us today as Hyper-V hits the (virtual) shelves! Just a quick note about Hyper-V RTM and SCVMM beta - to date, we haven't found any major issues with compatibility between the two releases provided you're using the SCVMM patch that we put out for Hyper-V RC1 compatibility. If you do find issues, please let us know through our beta site at connect.microsoft.com or send me a note directly.
Thanks!
Rakesh
Last week we held the "super bowl" (or "world cup" depending upon which flavor of football you prefer) of IT Pro conferences at Tech Ed held in Orlando. If you were there, you know that virtualization and our investments across the board were a central theme. I had the privilege of demonstrating SCVMM 2008 with Hyper-V during Bob's opening keynote. You can watch the keynote video here - the SCVMM demo is at the 42:30 mark of the session.
We're coming down the home stretch of getting this puppy out the door. We've received plenty of positive feedback from the beta and have incorporated some of the feature requests and many of the bug fix requests. While the beta version was technically "feature complete", we did put some time in our schedule to add some customer feature requests and as we get closer to the final release, I'll start sharing some of them with you. (One that we heard more than a few times was support for disjoint DNS name spaces which we'll support in the final release)
Rakesh
Many of you probably are already aware of this but in case you missed it, you can get the SCVMM patch that enables RC1 Hyper-V compat. The bits are available through our connect site. Key thing to keep in mind before applying the patch is that you must upgrade *all* of your Hyper-V hosts to RC1. The patch is not backward compatible with RC0.
Rakesh
It's been a couple of weeks since my last post but just wanted folks to know that we're almost ready with a patch that makes SCVMM beta compatible with Hyper-V RC1. We're "dogfooding" it (we're using it ourselves) internally for the next couple of days and barring any showstoppers, we should have a public patch available by Monday. Thanks for hanging in there. I know this is somewhat painful but the change to hyper-V was necessary and ultimately the final release of both products will be better.
Rakesh
The Hyper-V team has released RC1 of our virtualization platform (you can ready more about it here). Due to some necessary and important interface changes made by the Hyper-V team, the recently released beta of SCVMM 2008 doesn't work correctly with Hyper-V RC1. Needless to say, we're working on a patch and plan to fully support RC1 and I'll update everyone on time lines once we have them nailed. Our goal is to make an update available within a couple of weeks once we get a chance to fix some of the breaking bugs and re-test a bunch of our functionality. Rest assured that our test team is on top of this.
We could have "held" the Hyper-V RC1 release until these SCVMM issues were addressed but in the interest of ensuring our partners (who are also dependent upon the interfaces) get equal and sufficient time to address the changes, we pulled the trigger. It also allows you to begin testing the latest RC and as you get ready to roll it out more broadly, SCVMM will be ready to support you.
Thanks!
Rakesh
In case you missed the announcement last week at the Microsoft Management Summit in Las Vegas, the beta for VMM VNext (now called VMM 2008) is publicly available - you can download the software here: http://www.microsoft.com/systemcenter/scvmm/default.mspx
The beta is nearly feature complete meaning that in one form or another, we have implemented all of the new functionality including Hyper-V support and VMware support. Of course, good ol' Virtual Server is still fully supported as well. It is of course a beta so it's still a little rough around the edges so you can expect the final version to have better overall performance, reliability and scale but the beta should get you pretty good mileage in the mean time. I was able to demo VMM 2008 in front of 4000 IT Professionals last week and was interrupted several times for spontaneous applause. Assuming that wasn't just our team, people liked what they saw :-)
While the beta has nearly all of the features baked in, there are a few things that we're still working on for the final release later this year so stay tuned and I'll run some of them by you in future posts. Until then, download the beta and don't be shy, give us honest and direct feedback.
Rakesh
Not necessarily a glamorous topic I know, but absolutely essential as part of any deployment.
Contrary to popular belief (or what other vendors might have you believe) you don't need to re-engineer your backup infrastructure or license new technology if you're using virtualization. One of the benefits of virtualization with Windows as the host OS is that we have 20+ years of partners who have worked with us to ensure you get a well integrated backup and recovery solution. That's not to say that virtualization doesn't provide new opportunities for efficiencies, it most certainly does, but our philosophy is that you should be able to back up physical and virtual machines with a single tool (one you probably already have) while still taking advantage of the new benefits.
One of the things that virtualization makes easier is what is commonly called "bare metal recovery". This is the recovery situation you'd find yourself in if you wanted to completely rebuild a server after hardware failure or a disaster. With physical servers this can be tricky since the server that you backed up might not be identical to the server that you're restoring to. In addition, unless you're using an imaging tool, recovery typically involves laying down a fresh copy of the OS before you can even begin to get your application and data back which can kill your SLA. With VMs, you have the opportunity to back up the entire virtual machine (at the VHD level) so that bare metal recovery simply involves copying your VHDs to any host server. There's a not so subtle catch here though - how do you ensure that your VHDs are in a "consistent" state so that recovery will actually work? You could shut down the VMs before backup or save state but that's not particularly appealing for obvious reasons. You could just grab the VHDs while the VM is running and hope that the recovery works....which is equally unappealing. What you really need is a way to back up the VMs at the host (VHD) level but ensure that that the data within the VHDs is consistent and recoverable without downtime.
The Windows platform provides just such a mechanism and it's called the Volume Shadow Copy Service or VSS. VSS allows for application-coordinated backups using snapshot technology. Every one of our server applications and subsystems (SQL, Exchange, Sharepoint, registry, DNS etc.) comes with a VSS plug-in known as a "VSS Writer". When a backup system asks for a snapshot of a server, the VSS infrastructure goes through all of the VSS writers on a system and asked them to get their on-disk data into a consistent state (flush buffers, finish or rollback mid-flight transactions etc.) so that backup applications can grab the files. There's a much more orchestration than that involved but for the purposes of this discussion, the simplification I've made is sufficient. We actually use the same infrastructure on our desktop OS versions starting with XP....if you're really bored, open a command prompt and type "vssadmin list writers" and you'll get back a list of VSS writers installed on that system. The reason we have application vendors build the writers is because only the application knows how to get itself into a consistent state and every application is different.
Starting with Virtual Server R2 SP1 and also available in Hyper-V, we've included a VSS writer for virtual machine backup. This has allowed products like System Center Data Protection Manager (DPM) and products from our partners to install a single agent on the virtual machine host and ensure that you get consistent, recoverable copies of your VMs. Using the VSS framework and the application-specific writers, when the backup agent initiates a backup request, the host OS automatically communicates with all of the applications running inside of the VMs to ensure that they get themselves into a consistent state so that the data contained within the VHD is application consistent. That way, the recovery is not only guaranteed to work but you won't have to sit through a 2 hour chkdsk or consistency check session.
DPM has a pretty slick UI to make backup and recovery easy and includes the ability to backup to disk and tape in an integrated way. If you've got SCVMM, you're already licensed for DPM so give it a try. If you're not using DPM, check with your backup vendor to see if they include support for virtual machine backup on Virtual Server and Hyper-V, most of them already do.
Bottom line - if you're virtualizing on Windows, backup and recovery will snap into place seamlessly with your existing infrastructure.
Rakesh
Sorry for the large gap between posts here folks but as you might imagine, we've been pretty heads down working on the next release of SCVMM. Our immediate goal is to get the beta out so that you all can start managing your Hyper-V deployments and also start consolidating your management.
A few weeks ago we had a customer event here in Redmond for our Windows Server early adopters to give them the first glimpse of VNext and some of the functionality that we're going to support. The number one piece of feedback was "I need this yesterday". Point taken.
Aside from the VMware and Hyper-V support, there are a bunch of other things we're adding to the product so I thought I'd run through a few.
Resource Optimization - With VNext we've taken integration with Operations Manager to the next level. You'll be able to take a subset of application specific alerts that Operations Manager has generated while monitoring your environment and surface them directly into the SCVMM console (no more "alt-tabbing") in a feature we call "Physical Resource Optimization" or "PRO" for short. As Ops Manager finds opportunities for optimization within your data center, the alert is forwarded to SCVMM where you can view these "PRO tips". You can even have SCVMM automatically implement PRO tips based on rules that you can defined. The really cool part about PRO is that it is extensible and we're working with our industry partners (hardware and software) so that you get the best data available to make a fully informed decision when you go to optimize your data center. Even on VMware's hypervisor, PRO will help you make better decisions resulting in fewer mistakes and less reconfiguration.
Host Clusters - I know that lots of you will cluster your Hyper-V hosts and we wanted to simplify the management experience around clustering. Server 2008 has plenty of improvements with respect to clustering that make it easier to configure. Once you have configured a host cluster, SCVMM recognizes this and lets you manage this group of servers as a unit within your host group. You can then specify how many node failures you want the cluster to be able to withstand while keeping the VMs running and SCVMM's intelligent placement system will ensure that you don't over commit the resources on your cluster so that this SLA is maintained. In addition, when you deploy a new VM and want it to be highly available, you simply specify this requirement by checking a check box and we configure the appropriate cluster settings and resource groups for you. We wanted to keep things simple while ensuring that we maintain your SLA.
Delegated Administration - In SCVMM V1, we basically had two types of users - self-service users and administrators. Customers have been telling us that their virtualization deployments are getting very large and they need the ability to sub-delegate chunks of their environment to regional or departmental administrators. With SCVMM VNext, we've included this capability so now you'll be able to use a single SCVMM server to manage very large enterprise environments in a flexible way. You'll also find that our published scale numbers for SCVMM V1 are roughly double that of our competition. We've heard you loud and clear - fewer management servers and consoles is better. As a guy who builds management consoles and servers, that took a second to digest ;-)
There are plenty of additional features as well and I'll be blogging about them over the coming weeks. In addition, we'll have lots of sessions and discussion about the product at the upcoming Microsoft Management Summit (more info about that here) which I encourage you to attend.
Rakesh
Since we announced a few months back that our next release of VMM (VNext) would manage VMware, I've received lots of questions with respect to why we made this decision and what "manage VMware" really means. Let me walk you through some of the reasoning and thinking.
1) Customers - The primary reason that we decided to manage VMware was, quite frankly, because customers were asking for it. Personally I take this as a compliment to our management suite given that most if not all VMware customers are already using VMware's management tools. The fact that they want our tools to work on top of VMware's OS platform tells me that there's a definite opportunity to innovate and do a better job and we're fully committed to doing this....which leads to my next point.
2) We think we can do a better job - At the end of the day, it's not about managing virtual machines. It's about managing applications and services and today, many if not most of those run on Windows. Understanding the application in detail is absolutely critical to making intelligent management decisions. For example, migrating a VM when the CPU spikes to 80% for 10 minutes is not a particularly smart way to make that decision but if the VM is a 'black box' to you, it's the only choice that you have. With our management tools, you'll be able to set policies and rules based on application specific criteria. For example, if the average amount of time it takes for your order entry system to process an order exceeds 10 seconds and CPU is the reason, add more CPU capacity to the VM. Our customers are telling us that this is much more powerful and relevant. We feel strongly that with Hyper-V, our platform and our management tools provide an excellent end to end solution. With that said, we know that you have investments in VMware but even in that case, our management 'engine' can make better decisions on the VMware platform. In addition, the System Center family of products gives you the ability to manage physical servers right alongside your virtual machines with a single set of integrated tools rather than creating a new silo or island within your organization.
3) Flexibility in Hypervisors with a single management solution - As I said above, we feel very confident that our hypervisor provides the best platform in the vast majority of customer use cases (that's for you to decide of course) but regardless, customers want to use a single management tool in mixed environments. You'll also be able to automate across hypervisors using a single Powershell interface that we provide. VMM will abstract the difference in hypervisor APIs for you. You simply run the "Stop-VM" cmdlet and we make sure that regardless of the hypervisor platform, the VM is stopped. No more code blocks that read "If (VMware)....elseif (VirtualServer)......elseif (Hyper-V)......"
Finally, I want to emphasize that when we say "manage VMware", we mean that day to day, you'll be able to use our console and command line interface to fully manage your Virtual Infrastructure environment (including live migration), Virtual Server and Hyper-V environments seamlessly. In addition, we'll be able to extend the management capabilities that VMware offers today so you'll get an enhanced solution even on a non-Windows OS.
We'll share more details, screenshots and demos very soon....
Rakesh
I've been getting lots of questions about SCVMM and the recently announced Hyper-V beta (more info about that here).
The version of SCVMM that we released a couple of months back supports Virtual Server running on Windows Server 2003 only. Support for Hyper-V and Windows Server 2008 is being worked on as we speak and we plan to have a beta out in the second quarter of 2008 and the final release will coincide with the final release of Hyper-V. We're working as fast as humanly possible to release the Hyper-V support (and the VMware support) . You don't need to wait though, start kicking the tires on Hyper-V now and when you're ready to set up a large Hyper-V environment, I promise that we'll have your back with a sweet management solution that snaps seamlessly into place. We will of course continue to support Virtual Server so you'll be able to manage Hyper-V, VMware and Virtual Server with a single management tool and a single Powershell scripting interface. Our engine will abstract the differences between the platforms but will still allow you to take full advantage of the distinguishing features of each.
If you're wondering why the beta of SCVMM isn't available at the same time as the Hyper-V beta, let me give you some background. We had two options with respect to delivering SCVMM to the market:
1) Deliver a V1 based on Virtual Server and then a V2 roughly a year later with Hyper-V support
2) Deliver a V1 aligned with the Hyper-V schedule (which includes both Virtual Server and Hyper-V support)
Had we chosen option 2, we probably could have aligned the betas of SCVMM and Hyper-V more closely. That's because we could have kept writing more code for longer chunks of time instead of stabilizing the product and running the vigorous test processes that are required at the tail end of the software release cycle. There is a fixed cost associated with the "end game" or "home stretch" of a release (particularly with Enterprise software) and the more releases you do in the same period of time, the fewer features you ultimately can include since you have less time to write new code. We ultimately decided to chose option 1 because, frankly, customers were screaming for a management solution and they couldn't afford to wait an extra year so neither could we. Also, we're still aligned very well with the final Hyper-V release but unfortunately the betas don't align as nicely as we would have liked. With that said, I haven't heard too many people complaining about Hyper-V beta being release earlier than expected ;-)
Bottom line - we're working on it and nothing is higher in priority for our team than to deliver a world-class management solution for Hyper-V so stay tuned.
Rakesh
One of the things we heard fairly early on while planning VMM was that offline storage of VHDs was going to become an increasingly large management task. Based on this need, we created the "VM Library" feature to allow users to save virtual machines that weren't currently running to a managed location. As we developed the requirements for this feature, we quickly realized that people wanted to store more than VMs, they wanted to store all of the stuff that they used to create VMs as well (ISOs, templates, OS profiles, Hardware profiles etc.) so we changed the feature's name to "library" instead of "VM library". Before defining the feature in detail, we had to make some key design decisions and at the risk of boring you, I'll walk through some of that decision making process.
Does the library contents reside in the file system or in a database?
This is an age old debate and ultimately we decided to keep meta data in our SCVMM database but we kept all of the VHDs, ISOs etc. on file shares. While this made our life a little bit harder (we were now responsible for designing a system that kept meta data and the file system data in sync) it gave customers more flexibility. They could continue to use existing file replication technology and still had the ability to use Windows explorer or other file management tools to organize the information in any way that they wanted. It also made it easier to integrate with existing systems.
Is the library a physical thing or just a logical thing?
We decided that the answer to this question was "both". If you go to the library section of our UI, you'll see that you can either view the library as a logical collection of items (my favorite view is to click on the library server tree-node on the left and then group by "type") or you can view the actual physical folder hierarchy within the library share. Logical views are very convenient but sometimes the physical location of a file is important as well so you can use either view interchangeably. Templates, OS profiles and hardware profiles are all purely logical constructs so you won't find those items on disk, they're in our database. It's likely that we'll ultimately have on disk representations of those objects as well in the future though.
SCVMM Library Logical View
SCVMM Library Physical View
Does the library contain every object the SCVMM knows about or just stuff physically in the file shares that the library is comprised of?
This one we went back and forth on but ultimately decided that the library isn't really an "inventory" of everything in the world that we manage, it's where you keep stuff that is not running or associated with a host. You can think of it as a virtual 'shelf' to store stuff that you're not currently using. With this decision, there are only two places an object can live and be managed by SCVMM - either registered to a host or stored in the library. If you put something in a random folder or unmanaged file share, you're on your own.
What about co-location of library objects with the host for rapid deployment?
This decision was pretty easy. We decided to allow a host server to also be a library server. In this manner, you can store templates or other library objects local to a physical host so that deployment from the library to that host would be very fast.
Do we build Powershell cmdlets to organize library contents?
We initially started working on "move" and "copy" and "create" cmdlets to help users organize the library directly from our UI but that turned into a very slippery slope. One of the benefits of providing direct access to our library files via the file system is that you can organize directly through the Windows explorer interface (create directories, copy, move etc.). Aside from being a lot of extra work for us to expose all of that through our UI as well, it was unlikely that we'd get parity with the full set of file system operations. As a result, we made the call to cut this functionality from our UI but we added some requirements to ensure that as stuff was moved around in the file system, SCVMM would track the changes and have them reflected in our UI. By default we "refresh" the library share every hour but you can change this value or just refresh manually in the library UI or via cmdlet. We also tag each of objects in the library with GUID so that if you move things between shares, we just update the path property since we recognize the object even as the location changes.
Once we made these decisions, the rest of the functionality worked itself out pretty seamlessly but some of our beta feedback showed that we had overlooked one key scenario.
Throughout the design process, we had assumed that customer would typically have a handful of library servers (probably less than five) but lots of hosts (probably tens or hundreds). This is true for most data centers as admins like to consolidate and it wasn't uncommon to see large library servers attached to SAN arrays with fast storage for rapid deployment. With retail customers however, it was a different story. These guys had thousands of stores worldwide and needed to have a library server, often the same physical machine as the host computer, in each location so they effectively had at at least as many library servers as hosts. Some customers had library servers attached to regions of world and again they ended up with many more libraries than we had designed for. Typically, each of the library servers had the same file content replicated to across many sites (in the same way that they published software installation files or content).
Taking this feedback into consideration, we did a couple of things:
1) Began testing the system with lots and lots of library servers :-)
2) Added the "Library Group" concept.
If you right click on a library server in the library section of our UI, you'll see a property called "library group" which lets you associate a library server to a host group. Now, when you go to create a new virtual machine and you want to chose a base VHD from the library to start with, you can have the SCVMM UI scope your choices to library servers associated with the host group that you want to put the VM into.
As an example, you might create 25 geographic regions and assign a host group to each region. If you are creating a VM for the "Pacific northwest" region/host group, you'll want to use library objects from the library server associated with that region to prevent large file copy operations across very long distances. To enable this use case, you right click on the library file share and set the "library group" equal to "Pacific northwest". Now, when you launch the new VM wizard, you'll notice that when you select a library object to build a VM, you can scope the objects down by "library group" to ensure you use the closest copy of the file you need. In my example, you'd select "Pacific northwest" for this value. Similarly, from the command line, you can query for a library object and filter by library host group to ensure that you use the closest copy of the file.
The rest of the library concepts are pretty self-explanatory and there is plenty of additional content on the SCVMM library here as well.
Rakesh
P.S. - Happy Holidays!
Sorry for the gap between posts. I was on the east cost for the thanksgiving holiday and then stayed for the week to talk to some customers about our future road map and get their feedback. Anyhow, today we're gonna talk about checkpoints.
One of the things that I personally used to find confusing about virtual server was the usage of both differencing disks and undo disks. Both were used to do pretty much the same thing - roll back a VM to a previous state - but neither were particularly easy to use. After some deliberation with customers, we decided we'd only support one of the two in SCVMM and we decided on differencing disks since they provided a general superset of the functionality of undo disks. If you try to important a VM with differencing disks into VMM, it will prompt you to either discard the undo disk or merge it first.
The second key decision we made was with respect to granularity of creating of the differencing disks. Although virtual server allows you to create a differencing disk at the VHD level, we decided to allow creation of differencing disks only at the VM level. This simplifies much of the management and frankly, if you create a differencing disk on only a subset of the VHDs associated with a VM and then try to delete/recover a subset of the VHDs, you're taking your life into your own hands. The whole point of reverting a VM back in time is to revert the entire system state, application state and data. If you recover a subset of your drives, you have a high probability of these three components being out of sync and the VM won't run properly.
The last thing we had to figure out (and probably the most important thing) was how to make differencing disks easier to use. Managing them the the virtual server web UI isn't particularly easy and you as an administrator need to create and migrate the differencing disks on your own through the file system. To simplify this experience, we created the UI concept of a "checkpoint". A checkpoint is a logical entity that refers to a set of differencing disks associated with a VM and SCVMM manages the disks and their relationships for you. If you right click on a VM and click on "manage checkpoints", this opens up our checkpoint management dialog.
When you create a new checkpoint in our UI or use the the New -VMCheckpoint cmdlet, underneath the covers, SCVMM creates a set of differencing disks for each of the VHDs associated with the VM that you are checkpointing. If you actually go to Windows explorer and take a look, you'll see that the new disks are there and the naming convention that we use is the parent VHD name + the Date/Timestamp + VHD sequence number. SCVMM stores the fact that a new checkpoint exists in our database but it can also parse back the VHD name to figure out that the differencing disk is actually associated with a checkpoint object. (If you import VMs that already have differencing disk, SCVMM won't recoginize them as checkpoints since the metadata is missing.)
With virtual server, the VM needs to be stopped in order for checkpoints to work. If the VM is running and has VM additions installed, SCVMM will perform a shutdown for you, otherwise it is stopped directly. With the upcoming hypervisor, the VM can be checkpointed even while running which is a nice improvement. The hypervisor UI will call checkpoints "snapshots" but in order to be consistent and compatible with our first version, we decided to keep the term 'checkpoint' so we can use the same cmdlet names and the same UI.
You can also 'merge' checkpoints in our UI. We called this 'delete' in our beta since technically it removes the differencing disk chain by merging all changes into a single VHD but for obvious reasons, this caused users to think that data would actually be lost. If you merge a checkpoint, all future checkpoints must also be merged and you'll get that warning if you try this in the UI.
Restore has similar semantics to merge but it actually does delete the differencing chain thus reverting the state of a VM to the point in time represented by the checkpoint. When you restore to a checkpoint, we keep the diff disk/checkpoint for the point you restored back to. This enables training lab scenarios where you build a set of VMs, have students run through their training and then revert back to the original VM over and over again.
One thing we know from customers about restores is that typically people restore to the most recent checkpoint (not always but this is by far the most common case). Taking this into account, we add a '-MostRecent' parameter to the Get-VMCheckpoint cmdlet so you can have easy script access to the most recently created checkpoint. If you want to restore a VM to the most recent checkpoint, you'd run something like this:
Get-VMCheckpoint -MostRecent | where { $_.VM -eq "VM01" } | Restore-VMCheckpoint
Of course you'd change the name of the the VM to the one you're targeting.....if you don't specify a particular VM, this cmdlet will restore all of your VMs to the most recent checkpoint so be careful.
One of the parameters for New-VMCheckpoint that we regrettably didn't get time to include in V1 is the -RunAsynchronously flag. This means that in a script, VMCheckpoint operations run serially. As a workaround, the UI does let you select multiple VMs and create a new checkpoint which launches several checkpoint jobs in parallel. Such is the nature of shipping software though, you try to get everything in but ultimately you need to make some tough calls. Given that the hypervisor has a much improved mechanism for differencing disk creation, this feature will get even better in our next release but it's already proved to be pretty popular in V1.
Rakesh
Even though I'm writing a lot about V1, the engineering team here in Redmond is hard at work on the next release of SCVMM slated for next year. In V1 we had a lot of 'plumbing' code to write including a task infrastructure, the Powershell integration model, WS-Man etc. etc. I feel really good about the product we delivered and the early customer feedback has been tremendous. One of the things we didn't have a lot of time in the schedule for is what I would characterize as "polish" and we're gonna spend a few more cycles on that in this release. As some new screens come to life in the product, I'll post screenshots here on the blog.....keep in mind none of the screens are final and are subject to change (or being cut completely).
This is a screenshot of what our next autorun screen might look like.....internally we call the next release "Carmine VNext" (Carmine was the codename for V1). In case you're curious, we chose Carmine because it's a complimentary color to Viridian which is the codename for our new hypervisor.
The marketing people will ultimately slap the proper branding and name on the product. They tend to change their minds often so we just throw placeholders into the UI. Personally I think 'Carmine' sounds better than "Microsoft System Center Virtual Machine Manager 2007" but I digress....
Well I'm off to IT Forum in Barcelona for the rest of the week. If you're at the show, drop by our booth or attend one of our sessions and introduce yourself to me or one of my team members.
Rakesh
