From Geekwire a little fun phone competition at CES…

For this script I created two custom properties 1. Target Removal Date and 2. Owner Contact Info that will be populated with data that the script will consume to generate an email notification that the VM has reach expiration.

# This script was written for VMM 2012 RC

#This script will gather data from 2 custom attributes that have been created called Target Removal date and Owner Contact Information

#Once the data is gathered the date will be compared to the preset values of  +5 days and today. If any of  the dates match #an email notification will be sent to the information listed in the owner contact information notifing them that thier VM will be removed.

import-module virtualmachinemanager

# Get the VMM server.

$VMMServer = Get-SCVMMServer -ComputerName “YourVMMServerName”

#Sets the email server information $EmailServer = “YourEmailRelay”

$allVM=get-vm

# Get the e-mail address of the Self-Service Administrator.   $SSAdmin = $VMMServer.SelfServiceContactEmail

# Calculate expiration dates at today plus 5 days, today, yesterday, and 30 days ago.

# We will compare these dates to the expiration date in the custom 1 property   # of the virtual machines.

$Expiry1 = (Get-Date).AddDays(+5)

$Expiry2 = Get-Date

$Expiry3 = (Get-Date).AddDays(-1)

$Expiry4 = (Get-Date).AddDays(-30)

#Get value of custom property Owners Contact Info and target removal date, you may have different attributes

$PropDate = (Get-SCCustomProperty -Name “target removal date”)

$propcontact = (Get-SCCustomProperty -name “Owner Contract Info”)

foreach ($VM in $allVM) {

$DValue = get-sccustompropertyvalue -inputobject $VM -customproperty $propdate  $contact= get-sccustompropertyvalue -inputobject $VM -customproperty $propContact

if ($Dvalue -ne $null)   {

#write-host $vm.name,$dvalue.value,$contact.value

}

# If the expiration date is 5 days from now, send the owner an e-mail.

If ($dvalue.value -eq $Expiry1.ToShortDateString())

{

#Write-Host $VM.Name “will expire in 5 days”

Send-MailMessage -To $Email -From $SSAdmin -Subject “Your virtual machine will expire in 5 days” -Body “Your virtual machine will expire today. “  -SmtpServer “$EmailServer”

}

ElseIf($dvalue.value -eq $Expiry2.ToShortDateString())

{

#Write-Host $VM.Name “will expire in today”

Send-MailMessage -To $contact.value -From $SSAdmin -Subject “Your virtual machine  will expire today” -Body “Your virtual machine  will expire today. -SmtpServer “$EmailServer”

}

}

http://www.geekwire.com/2011/microsoft-holodesk-project-takes-closer-star-trek

My little man decided to break it down for us one night and thought this was funny….

http://blogs.msdn.com/b/b8/archive/2011/09/07/bringing-hyper-v-to-windows-8.aspx

Whether you are a software developer, an IT administrator, or simply an enthusiast, many of you need to run multiple operating systems, usually on many different machines. Not all of us have access to a full suite of labs to house all these machines, and so virtualization can be a space and time saver.

In building Windows 8 we worked to enable Hyper-V, the machine virtualization technology that has been part of the last 2 releases of Windows Server, to function on the client OS as well. In brief, Hyper-V lets you run more than one 32-bit or 64-bit x86 operating system at the same time on the same computer. Instead of working directly with the computer’s hardware, the operating systems run inside of a virtual machine (VM).

Hyper-V enables developers to easily maintain multiple test environments and provides a simple mechanism to quickly switch between these environments without incurring additional hardware costs. For example, we release pre-configured virtual machines containing old versions of Internet Explorer to support web developers. The IT administrator gets the additional benefit of virtual machine parity and a common management experience across Hyper-V in Windows Server and Windows Client. We also know that many of you use virtualization to try out new things without risking changes to the PC you are actively using.

An introduction to Hyper-V

Hyper-V requires a 64-bit system that has Second Level Address Translation (SLAT). SLAT is a feature present in the current generation of 64-bit processors by Intel & AMD. You’ll also need a 64-bit version of Windows 8, and at least 4GB of RAM. Hyper-V does support creation of both 32-bit and 64-bit operating systems in the VMs.

Hyper-V’s dynamic memory allows memory needed by the VM to be allocated and de-allocated dynamically (you specify a minimum and maximum) and share unused memory between VMs. You can run 3 or 4 VMs on a machine that has 4GB of RAM but you will need more RAM for 5 or more VMs. On the other end of the spectrum, you can also create large VMs with 32 processors and 512GB RAM.

As for user experience with VMs, Windows provides two mechanisms to peek into the Virtual Machine: the VM Console and the Remote Desktop Connection.

The VM Console (also known as VMConnect) is a console view of the VM. It provides a single monitor view of the VM with resolution up to 1600×1200 in 32-bit color. This console provides you with the ability to view the VM’s booting process.

For a richer experience, you can connect to the VM using the Remote Desktop Connection (RDC). With RDC, the VM takes advantage of capabilities present on your physical PC. For example, if you have multiple monitors, then the VM can show its graphics on all these monitors. Similarly, if you have a multipoint touch-enabled interface on your PC, then the VM can use this interface to give you a touch experience. The VM also has full multimedia capability by leveraging the physical system’s speakers and microphone. The Root OS (i.e. the main Windows OS that’s managing the VMs) can also share its clipboard and folders with the VMs. And finally, with RDC, you can also attach any USB device directly to the VM.

For storage, you can add multiple hard disks to the IDE or SCSI controllers available in the VM. You can use Virtual Hard Disks (.VHD or .VHDX files) or actual disks that you pass directly through to the virtual machine. VHDs can also reside on a remote file server, making it easy to maintain and share a common set of predefined VHDs across a team.

Hyper-V’s “Live Storage Move” capability helps your VMs to be fairly independent of the underlying storage. With this, you could move the VM’s storage from one local drive to another, to a USB stick, or to a remote file share without needing to stop your VM. I’ve found this feature to be quite handy for fast deployments: when I need a VM quickly, I start one from a VM library maintained on a file share and then move the VM’s storage to my local drive.

Another great feature of Hyper-V is the ability to take snapshots of a virtual machine while it is running. A snapshot saves everything about the virtual machine allowing you to go back to a previous point in time in the life of a VM, and is a great tool when trying to debug tricky problems. At the same time, Hyper-V virtual machines have all of the manageability benefits of Windows. Windows Update can patch Hyper-V components, so you don’t need to set up additional maintenance processes. And Windows has all the same inherent capabilities with Hyper-V installed.

Having said this, using virtualization has its limitations. Features or applications that depend on specific hardware will not work well in a VM. For example, Windows BitLocker and Measured Boot, which rely on TPM (Trusted Platform Module), might not function properly in a VM, and games or applications that require processing with GPUs (without providing software fallback) might not work well either. Also, applications relying on sub 10ms timers, i.e. latency-sensitive high-precision apps such as live music mixing apps, etc. could have issues running in a VM. The root OS is also running on top of the Hyper-V virtualization layer, but it is special in that it has direct access to all the hardware. This is why applications with special hardware requirements continue to work unhindered in the root OS but latency-sensitive, high-precision apps could still have issues running in the root OS.

As a reminder, you will still need to license any operating systems you use in the VMs.

Here’s a quick run-through of how the Hyper-V works in Windows 8.

Download this video to view it in your favorite media player:
High quality MP4 | Lower quality MP4

Supporting VM communication through wireless NICs

As you saw in the demo, creating an external network switch is as simple as selecting a physical network adapter (NIC) from a drop-down list and clicking OK. This already worked well for Windows Server Hyper-V, but to have similar results in Windows 8, we needed to get it working with wireless NICs, a new challenge.

The problem

The virtual switch in Hyper-V is a “layer-2 switch,” which means that it switches (i.e. determines the route a certain Ethernet packet takes) using the MAC addresses that uniquely identify each (physical and virtual) network adapter card. The MAC address of the source and destination machines are sent in each Ethernet packet and a layer-2 switch uses this to determine where it should send the incoming packet. An external virtual switch is connected to the external world through the physical NIC. Ethernet packets from a VM destined for a machine in the external world are sent out through this physical NIC. This means that the physical NIC must be able to carry the traffic from all the VMs connected to this virtual switch, thus implying that the packets flowing through the physical NIC will contain multiple MAC addresses (one for each VM’s virtual NIC). This is supported on wired physical NICs (by putting the NIC in promiscuous mode), but not supported on wireless NICs since the wireless channel established by the WiFi NIC and its access point only allows Ethernet packets with the WiFi NIC’s MAC address and nothing else. In other words, Hyper-V couldn’t use WiFi NICs for an external switch if we continued to use the current virtual switch architecture.

Figure 1: Networking between VM and external machine using wired connection

The solution

To work around this limitation, we used the Microsoft Bridging solution, which implements ARP proxying (for IPv4) and Neighbor Discovery proxying (for IPv6) to replace the virtual NICs’ MAC address with the WiFi adapter’s MAC address for outgoing packets. The bridge maintains an internal mapping between the virtual NIC’s IP address and its MAC address to ensure that the packets coming from the external world are sent to the appropriate virtual NIC.

Hyper-V integrates the bridge as part of creating the virtual switch such that when you create an external virtual switch using a WiFi adapter, Hyper-V will:

1. Create a single adapter bridge connected to the WiFi adapter
2. Create the external virtual switch
3. Bind the external virtual switch to use the bridge, instead of the WiFi adapter directly

In this model, Ethernet switching still happens in the virtual switch, and MAC translation occurs in the bridge. For the end user who is creating an external network, the workflow is the same whether you select a wired or a wireless NIC.

Figure 2: Networking between VM and external machine using WiFi connection

In conclusion, by bringing Hyper-V from Windows Server to Windows Client, we were able to provide a robust virtualization technology designed for the scalability, security, reliability, and performance needs of most data centers. With Hyper-V, developers and IT professionals can now build a more efficient and cost-effective environment for using and testing across multiple machines.

 VM Limited

We are pleased to announce the release of the new Linux 3.1 Integration Services and support for the following Linux distributions as supported guests within Hyper-V:

• Red Hat Enterprise Linux 6.x (x86 & x64)
  • Red Hat Enterprise Linux 6.0 (x86 & x64)
  • Red Hat Enterprise Linux 6.1 (x86 & x64)
• CentOS Linux 6.x (x86 & x64)
  • FYI, CentOS has only released 6.0 presently

 This announcement is happening today at the Open Source Convention 2011.

The new Linux ISs are available here:

http://www.microsoft.com/download/en/details.aspx?id=26837

 The following features are included in the Linux 3.1 Integration Services release:

Driver support for synthetic devices: Linux Integration Services supports the network controller and the IDE and SCSI storage controller developed for Hyper-V.

Fastpath Boot Support for Hyper-V: Boot devices take advantage of the block Virtualization Service Client (VSC) to provide enhanced performance.

Timesync: The clock inside the virtual machine will remain synchronized with the clock on the virtualization server and utilize the pluggable time source device.

Integrated Shutdown: Virtual machines running Linux can be shut down from either Hyper-V Manager or System Center Virtual Machine Manager using the Shut Down command.

Symmetric Multi-Processing (SMP) Support: Supported Linux distributions can use up to 4 virtual processors (VP) per virtual machine.

Heartbeat: Allows the virtualization server to detect whether the guest is running and responsive.

Key Value Pair Exchange (KVP): Information about the running Linux virtual machine can be obtained by using the Key Value Pair exchange functionality on the virtualization server.

The article below by Brian Madden provides incite to the changes…….

http://www.brianmadden.com/blogs/brianmadden/archive/2011/07/14/Is-vmware-screwing-the-non_2D00_view-vdi-community-with-the-vsphere-5-licensing-changes.aspx

by Brian Madden

Yesterday VMware announced Version 5 of their main product, vSphere. (In other words, they announced ESX 5.) While vSphere 5 has tons of new features, it also has a new licensing model. Early reactions from the community are that the change in licensing will lead to much higher costs, in some cases 2x-3x more cost for the same hardware when moving from vSphere 4 to 5.

While many people are speculating that this is going to be a showstopper for a lot of customers, it’s exacerbated in VDI environments where servers typically have very high memory-to-processor ratios. So what does this new licensing mean for VDI? Will VMware create a special SKU just for virtual desktops? Will this SKU apply to all virtual desktop environments, or just VMware View? Let’s dig in to find out.

Understanding VMware’s new licensing model for vSphere: introducing “vRAM”

The first thing I read about vSphere’s new licensing model is that it’s based on the total memory of your vSphere environment, which VMware is calling “vRAM.” While I initially confused that with “VRAM,” I spent time yesterday reading VMware’s 12-page white paper which explains the details of the new pricing and licensing.

If you don’t want to read the whole paper, the gist of it is that instead of licensing based on physical servers, processors, and cores, vSphere 5 has a giant virtual pool of RAM that’s shared between as many hosts, CPUs, cores, and VMs as you like. So if you have licensed 128GB of vRAM, you can run a single VM with 128GB, or 32 VMs with 4GB each, or 128 VMs with 1GB each. You can run them on one huge host or lots of smaller hosts. You can have as many vCPUs and cores as you want. (Pools can even span multiple vCenters.) And when you want to add more RAM capacity for your entire environment, you just pop in another license key which enables more RAM that you can distribute however you see fit. You only pay for the memory which is allocated to actively running VMs–not the total memory you have in the a machine.

The only weird thing is that you still buy these vRAM licenses in the form of physical processor license packs, each with comes with an entitlement for a certain amount of vRAM. You need one processor license for each physical processor in your environment. For example, the “base” level of vSphere 5 is $999 for a processor license which includes 24GB of vRAM. So if you have a server with 4 processors and 192GB RAM, you’d actually need to buy 8 of those base processor licenses (192/24) to get the RAM coverage to fill it up, even though you only have 4 processors.

I guess they do that just to ensure they still get their money even in environments that have a lot of CPU but don’t need much memory, although frankly that weird purchasing method is probably the reason they need a 12-page white paper to explain licensing instead of a tweet. (Speaking of twitter, @JeroenvStokkum pointed me to a cool PowerShell script for calculating your vSphere 5 licensing options based on a total RAM / Processor combination.)

What does this licensing model mean for VDI?

The general reaction of the community towards this new licensing methodology is what you might classify as “negative.” A thread about the changes on VMware’s community site has 178 replies and counting, and twitter’s burning up with a new #vtax twitter hashtag.

And while it appears that no one outside of Palo Alto cares for the changes, early back-of-the-napkin math seems to show that VDI environments will be particularly hard-hit. This is due to the fact that VDI hosts typically have very high memory-to-processor ratios as well as high utilization. (Typically servers like dual six-core processors with 192GB, etc.) While these types of servers running at full capacity would only require two standard licenses ($995 each, $1990 total) in vSphere 4, they’ll require 8 licenses for vSphere 5 ($995 each, $7960 total). Yikes!

VMware, for their part, points out that in vSphere 5 you’re only paying for the memory that’s actually allocated to running VMs. So if you base your vSphere pricing on the total memory of all physical vSphere 4 servers you have, you’ll end up buying too much. (And this is their response to everyone who thinks their costs are going to double or triple.) But while that might make sense for general datacenter/cloud/server workloads, VDI desktop workloads are different. VDI host servers are typically very highly utilized. And that’s the real catch. If you have 1,000 desktop VMs running Windows 7 with 2GB RAM each, you need 2,000 GB worth of vRAM licenses for vSphere 5, which will run you about $84k. Assuming 90 desktops per physical host, your entire existing vSphere 4 environment would have only cost you $24k for 12 servers. (Ok, make it $26k for 13 servers so you have some spare capacity for HA.)

This leads to a big question: For your VDI environment, are you using vSphere, or VMware View? While you might think that’s an inappropriate “apples to oranges” comparison, remember that if you’re using VMware View then you buy View licenses which also include vSphere licenses. But if you’re using a non-VMware VDI product (like Citrix XenDesktop or Quest vWorkspace), then you’re buying vSphere licenses on your own (in addition to whatever licenses you buy from Citrix or Quest).

Here’s why that matters: VMware View is sold on a “per user” basis. You pay $150 (for VDI only) or $250 (for VDI plus local, ThinApp, and image sharing) per concurrent connection. That $150 or $250 that you pay includes the licenses needed to run vSphere (and vCenter) on as many physical hosts as you need for your VDI desktops and related View components. So if you’re a View customer, the new vSphere 5 licensing cost and method is totally irrelevant to you since you get your vSphere licenses with View. But if you’re planning to use Citrix XenDesktop or Quest vWorkspace on vSphere, then you don’t get vSphere in a per-user way (since that only comes with View). XenDesktop and vWorkspace customers have to buy vSphere on their own. And if they plan to upgrade to vSphere 5, then they’re potentially looking at a huge price increase.

What’s interesting is that the version of vSphere that a customer gets with View (called “vSphere Desktop Edition”) is functionally identical to vSphere Enterprise Edition, except from a legal standpoint you’re only allowed to use it to run VMs associated with your View environment. This means desktop OSes only, and servers only if they have a specific dedicated role in your View environment. (Connection brokers, View Manager, etc.)

What will “vSphere 5 Desktop Edition” look like?

The fact that there was a special “vSphere Desktop Edition” in the vSphere 4 days was very straightforward and non-controversial. VMware View customers got their vSphere licenses bundled into their $150-$250 concurrent View connection licenses, and XenDesktop and vWorkspace customers who still wanted to use vSphere just bought normal vSphere licenses.

But now that we know that “traditional” vSphere licenses could potentially quadruple in price for vSphere 5 based on typical VDI host hardware, what will current VDI customers do? We can assume that View itself will be updated so that the bundled vSphere Desktop Edition licenses can be used for vSphere 5. So View customers will be fine.

But non-View customers who still want to do VDI on vSphere? They have a few choices:

• Migrate off of vSphere and onto XenServer or Hyper-V.
• Keep running vSphere 4 forwever.
• Upgrade to vSphere 5 and pay the huge price increase.
• Throw away XenDesktop or vWorkspace and move to View.
• Buy View licenses just to get the special “vSphere Desktop Edition” that lets them run desktop OSes on vSphere, but continue using their existing VDI platform and throw the View licenses in the trash
• Hope that VMware releases a general-purpose “vSphere 5 Desktop Edition” product which they can purchase without having to buy View

Obviously the last two options are the most interesting.

If the regular vSphere 5 licenses are too expensive for VDI, will customers instead buy View connection licenses just to get the right to use vSphere and vCenter for their desktops, but then still install XenDesktop or vWorkspace? Based on the quick cost analysis from the top of this article with 90 users per dual-proc 192GB server, that would be $13.5k in View licensing per server instead of $8k for straight vSphere 5, so actually that looks worse. Of course the vSphere Desktop Edition SKU you’d get by buying View licenses is the like vSphere Enterprise, so maybe comparing the more expensive Enterprise Edition of vSphere 5 is the way to go, which would total $17.2k for your 192GB server. But really most VDI desktops probably don’t need the features of vSphere Enterprise, (HA and vMotion are both Standard Edition features), so it’s probably more accurate to compare $8k for vSphere 5 Standard to $13.5k for View licenses.

So while vSphere 5 will be four times more expensive than vSphere 4 for those 90 VDI desktops, it’s still cheaper (in this specific use case) to just pay for the regular vSphere 5 rather than trying to buy View licenses just to get access to vSphere Desktop Edition.

This could all change if VMware decides to release a standalone “vSphere Desktop Edition” that’s available for a lower cost without having to buy View. (Maybe $50 per desktop connection?) In fact blogger Brian Knudtson wrote that a separate SKU for this use case would be available, writing, “This was quietly added on the partner SKU list for non-View VDI implementations. This provides a low cost hypervisor for XenDesktop implementations (a fairly common occurance).”

No one else is saying anything about that, and we don’t know whether that SKU will exist. (Or if it does, whether it is an actual standalone SKU or just the vSphere Desktop Edition SKU you get when you buy View.)

[UPDATE AS OF 9am EST: Commenter ermac318 posted a link to this paper from VMware confirming that there WILL be a vSphere 5 Desktop Edition available for non-View customers. Yay! It will be sold in 100 concurrent desktop packs for $6500, with unlimited vRAM entitlements. (As long as you're running desktop OSes.) The feature level will be equivalent to vSphere Enterprise Plus. The only weird catch is that you can only buy vSphere 5 Desktop Edition for new vSphere licenses. If you have existing vSphere 4 licenses that you're using for desktops, you have to upgrade those to their equivalent regular vSphere 5 licenses.

So this is cool. Why VMware doesn't mention this at all in their 12-page vSphere 5 licensing paper is beyond me?? Look for a full analysis tomorrow.]

The aftermath

We’ll see how this shakes out. It’s important to remember that vSphere 5 isn’t even out yet, so this is all hypothetical at this point. And we’ll surely learn more about VMware’s View licensing on vSphere 5 soon.

That said, there’s a few final interesting tidbits that have come out of this discussion:

First, maybe this is VMware’s attempts to drive everyone towards enterprise agreements? If you just buy for your whole enterprise, then maybe you aren’t getting into the nitty-gritty details of RAM, processors, and cores?

One of the commenters on that huge community thread also asked whether VMware’s new licensing model would respect Moore’s law. “If not,” he wrote, “our VMware license cost will double every 18 months!”

The final silver lining, however, might be that this causes everyone to wake up and realize that the THE DATACENTER IS FREAKING EXPENSIVE! RUNNING YOUR DESKTOPS THERE WILL COST YOU MORE MONEY THAN RUNNING THEM ON YOUR DESKTOP. Not that that’s a bad thing. Just something to keep in