One of the most frequently asked questions I get from my
customers is something like this:
“We have a multi-tenant environment where everything is
now software-defined, including the network by using network virtualization. As
a result of that, we can no longer provide value added services to these
customers, as we don’t have a network path into the environments”.
Last year, I wrote a blog post that talks about “Understanding
your service offerings with Azure Pack” – which you can read here: http://kristiannese.blogspot.no/2014/10/understanding-windows-azure-pack-and.html
I won’t get into all of those details, but a common
misunderstanding nowadays is that both enterprises and service providers expect
that they will be able to manage their customers in the same way as they always
have been doing.
The fact that many organizations are now building their
cloud infrastructure with several new capabilities, such as network
virtualization and self-servicing, makes this very difficult to achieve.
I remember back at TechDays in Barcelona, when I got the
chance to talk with one of the finest Program Manager’s at Microsoft, Mr. Ben
Armstrong.
We had a discussion about this and he was (as always)
aware of these challenges and sad he had some plans to simplify service management
in a multi-tenant environment directly in the platform.
As a result of that, we can now play around with PowerShell Direct in Windows Server
2016 Technical Preview.
Background
Walking down the memorial lane, we used to have Virtual
Server and Virtual PC when we wanted to play around with virtualization in the
Microsoft world. Both of these solutions were what we call a “type 2 hypervisor”,
where all the hardware access was emulated through the operating system that
was actually running the virtual instances.
With Windows Server 2008, we saw the first version of
Hyper-V which was truly a type 1 hypervisor.
In the architecture of Hyper-V – and also the reason why
I am telling you all of this, is that we have something called VMBus.
The VMBus is a communication mechanism (high-speed
memory) used for interpartition communication and device enumeration on systems
with multiple active virtualized partitions. The VMBus is responsible for the
communication between the parent partition (the Hyper-V host) and the child
partition(s) (virtual machines with Integration Components installed/enabled).
As you can see, the VMBus is critical for communication
between host and virtual machines, and we are able to take advantage of this
channel in several ways already.
In Windows Server 2012 R2, we got the following:
·
Copy-VMFile
Copy-VMFile let you copy file(s) from a source path to a
specific virtual machine running on the host. This was all done within the
context of the VMBus, so there’s no need for network connectivity to the
virtual machines at all. For this to work, it required you to enable “Guest
Services” on the target VMs as part of the integration services.
Here’s an example on how to achieve this using
PowerShell:
# Enable guest services
Enable-VMIntegrationService -Name 'Guest Service
Interface' -VMName mgmtvm -Verbose
# Copy file to VM via VMBus
Copy-VMFile -Name mgmtvm -SourcePath
.\myscript.ps1 -DestinationPath
“C:\myscript.ps1” -FileSource
Host -Verbose
·
Remote
Console via VMBus
Another feature that was shipped with Windows Server 2012
R2 was something called “Enhanced Session Mode”. This would leverage a RDP
session via the VMBus.
Using RDP, we could now logon to a virtual machine
directly from Hyper-V Manager and even copy files in and out of the virtual
machine. In addition, USB and printing would also now be possible – without any
network connectivity from the host to the virtual machines.
And last but not least, this was the foundation for the
Remote Console feature with System Center and Windows Azure Pack- which you can
read more about here: http://kristiannese.blogspot.no/2014/02/configuring-remote-console-for-windows.html
And now back to the point. With Windows Server 2016, we
will get PowerShell Direct.
With PowerShell Direct we can now in an easy and reliable
way run PowerShell cmdlets and scripts directly inside a virtual machine
without relying on technologies such as PowerShell remoting, RDP and VMConnect.
Leveraging the VMBus architecture, we are literally
bypassing all the requirements for networking, firewall, remote management –
and access settings.
However, there are some
requirements in the time of writing this:
·
You must be connected to a Windows 10 or a
Windows Server technical preview host
with virtual machines that are running Windows 10 or Windows Server technical preview
as the guest operating system
·
You must be logged in with Hyper-V Admin creds
on the host
·
You need
user credentials for the virtual machine!
·
The virtual machine that you want to connect to
must run locally on the host and be booted
Clearly, it should be obvious that both the host and the
guest need to be on the same OS level. The reason for this is that VMBus is
relying on the virtualization service client in the guest – and the
virtualization service provider on the host, which need to be the same version.
But what’s interesting to see here is that in order to
take advantage of PowerShell Direct, we need to have user credentials for the
virtual machine’s guest operating system itself.
Also, if we want to perform something awesome within that
guest, we probably need admin permission too – unless we are able to dance
around with JEA, but I have been able to test that yet.
Here’s an example on what we can do using PowerShell
Direct
# Get credentials to access the guest
$cred = Get-Credential
# Create a PSSession targeting the VMName from the Hyper-V
Host
Enter-PSSession -VMName mgmtvm -Credential $cred
# Running a cmdlet within the guest context
Get-Service | Where-Object {$_.Status -like
"*running*" -and $_.name -like "*vm*" }
[mgmtvm]: PS C:\Users\administrator.DRINKING\Documents>
Get-Service | Where-Object {$_.Status -like "*running*" -and $_.name
-like "*vm*" }
Status Name DisplayName
------ ---- -----------
Running
vmicguestinterface Hyper-V Guest Service Interface
Running
vmicheartbeat Hyper-V
Heartbeat Service
Running
vmickvpexchange Hyper-V Data
Exchange Service
Running vmicrdv Hyper-V Remote Desktop
Virtualizati...
Running
vmicshutdown Hyper-V Guest
Shutdown Service
Running
vmictimesync Hyper-V Time
Synchronization Service
Running
vmicvmsession Hyper-V VM
Session Service
Running vmicvss Hyper-V Volume Shadow Copy
Requestor
As you can see, [mgmtvm] shows that the context is the
virtual machine and we have successfully listed all the running services
related to the integration services.
Although this is very cool and shows that it works, I’d
rather show something that might be more useful.
We can enter a PSSession as showed above, but we can also
directly invoke a command through invoke-command and use –scriptblock.
#Invoke command, create and start a DSC configuration on the
localhost
Invoke-Command -VMName
mgmtvm -Credential
(Get-Credential) -ScriptBlock
{
# DSC Configuration
Configuration myWeb {
Node "localhost" {
WindowsFeature
Web {
Ensure =
"Present"
Name =
"Web-Server"
}
}
}
# Enuct the DSC config
myWeb
# Start and apply the DSC configuration
Start-DscConfiguration .\myWeb -Wait -Force -Verbose }
From the example above, we are actually invoking a DSC
configuration that we are creating and applying on the fly, from the host to
the virtual machine using PowerShell Direct.
Here’s the output:
PS C:\Users\knadm> #Invoke command, create and start a DSC
configuration on the localhost
Invoke-Command -VMName mgmtvm -Credential (Get-Credential)
-ScriptBlock {
# DSC Configuration
Configuration myWeb {
Node
"localhost" {
WindowsFeature
Web {
Ensure =
"Present"
Name =
"Web-Server"
}
}
}
# Enuct the DSC config
myWeb
# Start and apply the DSC configuration
Start-DscConfiguration .\myWeb -Wait -Force -Verbose }
cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
WARNING: The configuration 'myWeb' is loading one or more
built-in resources without explicitly importing associated modules. Add
Import-DscResource –ModuleName ’PSDesire
dStateConfiguration’ to your configuration to avoid this
message.
Directory:
C:\Users\administrator.DRINKING\Documents\myWeb
Mode
LastWriteTime Length
Name PSComputerName
----
------------- ------
----
--------------
-a----
03-08-2015 11:34 1834 localhost.mof
mgmtvm
VERBOSE: Perform operation 'Invoke CimMethod' with following
parameters, ''methodName' = SendConfigurationApply,'className' =
MSFT_DSCLocalConfigurationManager,'namespace
Name' = root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer MGMT16 with user
sid S-1-5-21-786319967-1790529733-2558778247-500.
VERBOSE: [MGMT16]: LCM: [
Start Set ]
VERBOSE: [MGMT16]: LCM: [
Start Resource ] [[WindowsFeature]Web]
VERBOSE: [MGMT16]: LCM: [
Start Test ]
[[WindowsFeature]Web]
VERBOSE: [MGMT16]: [[WindowsFeature]Web]
The operation 'Get-WindowsFeature' started: Web-Server
VERBOSE: [MGMT16]:
[[WindowsFeature]Web] The operation 'Get-WindowsFeature' succeeded:
Web-Server
VERBOSE: [MGMT16]: LCM: [ End Test
] [[WindowsFeature]Web] in 22.0310 seconds.
VERBOSE: [MGMT16]: LCM: [
Start Set ]
[[WindowsFeature]Web]
VERBOSE: [MGMT16]:
[[WindowsFeature]Web] Installation started...
VERBOSE: [MGMT16]:
[[WindowsFeature]Web]
Continue with installation?
VERBOSE: [MGMT16]:
[[WindowsFeature]Web] Prerequisite processing started...
VERBOSE: [MGMT16]:
[[WindowsFeature]Web] Prerequisite processing succeeded.
WARNING: [MGMT16]:
[[WindowsFeature]Web] You must restart this server to finish the
installation process.
VERBOSE: [MGMT16]:
[[WindowsFeature]Web] Installation succeeded.
VERBOSE: [MGMT16]: [[WindowsFeature]Web]
successfully installed the feature Web-Server
VERBOSE: [MGMT16]:
[[WindowsFeature]Web] The Target machine needs to be restarted.
VERBOSE: [MGMT16]: LCM: [
End Set ]
[[WindowsFeature]Web] in 89.0570
seconds.
VERBOSE: [MGMT16]: LCM: [
End Resource ] [[WindowsFeature]Web]
VERBOSE: [MGMT16]: [] A reboot is
required to progress further. Please reboot the system.
WARNING: [MGMT16]: [] A reboot is required to progress
further. Please reboot the system.
VERBOSE: [MGMT16]: LCM: [
End Set ]
VERBOSE: [MGMT16]: LCM: [
End Set ]
in 113.0260 seconds.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 115.028
seconds
In this example I am using one of the built-in DSC
resources in Windows Server. If I wanted to do more advanced configuration that
would require custom DSC resources, I would have to copy those resources to the
guest using the Copy-VMFile cmdlet first. All in all, I am able to do a lot
around vm management with the new capabilities through VMBus.
So, what can we expect to see now that we have the
opportunity to provide management directly, native in the compute platform
itself?
Let me walk you through a scenario here where the tenant
wants to provision a new virtual machine.
In Azure Pack today, we have a VM extension through the
VM Role. If we compare it to Azure and its new API through Azure Resource
Manager, we have even more extension to play around with.
These extensions gives us an opportunity to do more than
just OS provisioning. We can deploy – and configure advanced applications just
the way we want to.
Before you continue to read this, please note that I am
not saying that PowerShell Direct is a VM extension, but still something useful
you can take advantage of in this scenario.
So a tenant provision a new VM Role in Azure Pack, and the
VM Role is designed with a checkbox that says “Enable Managed Services”.
Now, depending on how each service provider would like to
define their SLA’s etc, the tenant has now made it clear that they want managed
services for this particular VM Role and hence need to share/create credentials
for the service provider to interact with the virtual machines.
I’ve already been involved in several engagements in this
scope and I am eager to see the end-result once we have the next bits fully
released.
Thanks to the Hyper-V team with Ben and Sarah, for
delivering value added services and capabilities on an ongoing basis!
