Monday, September 27, 2010

“After all, VMs is nothing but a set of files in a folder”

There are many ways to describe virtualization. You can either describe it in a very complex
and confusing method, or just simplify it and say that VMs is nothing but a set
of files in a folder.
Anyhow, it`s important to know the concept of virtualization, what you want to achieve,
and how.
Even though the machines are virtualized, you have to think and consider them as
Example: If your physical SQL server needs dedicated
controllers/disks for its data and log files, your VM need that as well.
Virtualization is supposed to simplify administration. Virtualization adds flexibility and efficiency to the IT infrastructure. Its potential to reduce overall footprint in the data center by making better use of server resources benefits the entire IT organization by trimming costs and freeing up money and people to perform revenue-producing work. But to reach these goals, you also need to obtain some new knowledge.
I will have a walk-through in my next post since I`m going to install and configure a
brand new lab-environment, and try to show some pros and cons about
virtualization vs. physical.

Thursday, September 23, 2010

P2V – Part One

Everybody knows that the ideal machine, is a clean machine where the workload are newly installed and configured.
But sometimes you need to do a conversion of a physical server to a virtual server (P2V).
It`s supposed to be a simple process, but it can result in late nights and a lot of coffee if you skip the planning process.

Conversion tip 1:

Prepare for downtime since the conversion is making a copy of your Physical machine.
Even though you could run an Online conversion, you should not let the source be ‘online’ for connections during the conversion. In practical, you are running an online backup of your physical machine, so if its accessible for your users, the data you convert will be outdated.
If you convert a machine running SQL server in your network, you might want to stop your SQL server engine during conversion, or simply deny the traffic with the firewall.

Conversion tip 2:

Have you checked your network and storage requirements ?
If you don’t have enough storage for your vm, you will have a problem. Check the disk size on the source before conversion.
The conversion brings a heavy load to your network, even though it`s using BITS. Do not run a conversion during peak performance. Consider performing the conversion on a dedicated network.
Also consider if you can convert your physical machine to a virtual machine with dynamic disks, and convert the disks to Fixed afterwards. This will result in a quicker conversion. (But the conversion from dynamic to fixed can only be performed when the vm is off. Again: prepare for some downtime)

Conversion tip 3:

Select your migration candidates in order of importance. Test the conversion on your non-business-critical workloads before your LOB server. You will get the experience, and clear some ‘gotchas’ before the ‘real’ conversions starts.

Conversion tip 4:

Assign more resources to your vm. The great benefit of virtualization, is that you can assign extra ‘hw’ to your vms more easily.  

Wednesday, September 22, 2010

My young apprentice !

I`ve just ordered a new test environment, so I can test and educate my young apprentice, students, collegues, and also my friends at the MS forums.

The test environment will include:

A two-node Hyper-V Failover cluster
A simple storage with iscsi-target
One SCVMM 2008 R2 server
One Domain Controller
Networks for cluster heartbeat, live migration, iscsi, and LAN.

The Hyper-V hosts will be running Windows Server 2008 R2 SP1.

My young apprentice !

Self-Service Portal - Ideal for exposing your test VMs

Want to be able to share your isolated test machines without connecting them to your corporate network ?
It`s possible with SCVMM 2008 R2 and the Self Service Portal.

Let`s assume that everything is installed, and the VMs need to be accessible over the network without being physical (or virtual) attached.

In SCVMM, you create a new user role, so you can assign the VMs to the portal.

1. Navigate to the administration view
2. Click 'User Role'
3. Click 'New User Role' from the actions pane to get to the 'Create User Role Wizard'

After providing a name for your new user role (And selected the Self-Service User profile), click next to add members to this user role.
Add a user or a group from Active Directory.

On the the 'Select Scope' page, check the host groups to which you want this new user role to have access (This is very important. If you`re not checking the host group where the VMs will be placed, they will not appear in the Self-Service portal).

On the Virtual Machine permission page, you can specify what action this new role can take on the VMs in the scope. I would recommend that you uncheck the 'Checkpoint' if you are running the VMs in Failover Clustering, since it will  create a differencial disk (.avhd).

The next page shows the Library Share.This is where you allow users to store virtual machines in the library which this user role has access.

The next page is the summary of what you`ve been up to.

After you`ve finished, you have to assign an owner to the VMs that you want to expose in the Self-Service Portal.

Navigate to 'Virtual Machines' in SCVMM, right click the VMs, select 'Properties', and select the same group from Active Directory that you assigned the newly created User Role.

You can now log on to your Self-Service Portal, and see the selected VMs.
The reason why you can log on to your VMs without connecting them to your network, is that your SCVMM connects to the Hyper-V host through VMConnect.exe (default on port 2179).
(Also make sure your VMs have the intergration services installed prior to this)

When you now log on to your Self-Service Portal, you should see the selected VMs.

Tuesday, September 21, 2010

Considering Guest Cluster in Hyper-V

Since you have a High Availability solution available in Hyper-V with Failover Clustering, why should you consider Guest Clusters ?

Some reasons for considering a guest cluster, is when you need a High Available solution for your SQL servers.

Example: When SQL server is installed in a two-node Failover Cluster, the SQL Server service is installed on both nodes of the cluster. When one of the nodes fails, the remaining node will quickly take over the processing that was being done on the dead node.
If you only had a single SQL server VM in a Hyper-V Failover Cluster, the SQL Server would restart on the remaining node in the cluster, having time consuming tasks to be completed before beeing able for client requests.

Requirements for Guest Cluster:
You can only use ISCSI for guest clusters.
To build a guest cluster, you should follow the same steps as you would do for a 'normal' cluster, using ISCSI.

Quick Migration vs. Live Migration

Why should you use Quick Migration if Live Migration provides more uptime ?

Live Migration can place a heavy burden on networking resources to accomplish the VM move.
Since there is a heavy load, only one vm can migrate at a time using Live Migration, and if the load are really heavy, the migration might fail.
Quick Migration saves the mamory state of VMS to be moved, and are capable of moving multiple VMs from one node to another at the same time. The VMs are 'frozen', and might not be acceptable for some organizations, so be sure to select the right migration.


I`ve decided to translate my blog to english to help me to reach out to a larger community.
But for those who have a request about some information, tutorials, and so on in norwgian - just ask :-)

Sunday, September 19, 2010

Hyper-V og nettverk (DMZ)

Q: Hva bør man tenke på dersom man skal kjøre virtuelle maskiner i DMZ. Og krever dette dedikerte hosts ?

A: Tja.

Man bør aller helst ha en dedikert host til dette. Men dette gir også andre behov, som eget domene i DMZ, og ekstra hardware spesielt dersom man skal benytte Failover Cluster.

Dersom man verken har penger eller infrastruktur (gjerne begge deler)  som ikke støtter dette, kan man fortsatt oppnå en sikker måte å eksponere disse vmene.

La oss ta utgangspunkt i følgende konfigurasjon:

·         1 Active Directory domene
·         2 Hyper-V noder i Failover Cluster. Begge disse har 6 nettverkskort hver
·         1 iscsi SAN

Man bør begynne med å konfigurere nettverkskortene på Hyper-V hostene.

Siden vi bruker Failover cluster og iscsi SAN, konfigurerer vi 4 av nettverskortene på hostene til å gå mot dette da det er viktig med ytelse og eventuelt failover her. Man kan enten velge å teame disse dersom det er støtte for det, eller bruke MPIO som er innebygd i 2008 R2. Disse er på eget nettverk, adskilt fra LAN.

Vi står da igjen med 2 nettverkskort.
Kort 1 dedikerer vi til LANet + cluster kommunikasjon (bør helst ha eget NIC/nettverk til dette), og konfigurerer et ‘External’ nettverk til dette.
Kort 2 dedikerer vi til DMZ. Også her må vi konfigurere et ‘External’ nettverk slik at disse maskinene er tilgjengelige i nettverket.

Dersom vi nå setter kablene i server, der kabel 1 fra Lanet går til LAN-kortet på server, og kabel 2 fra DMZ-nettverket går til DMZ-kortet i server, har man segmentert to forskjellige nettverk på en og samme host.

(Det er viktig at nettverkene har nøyaktig samme navn, siden man skal benytte hostene i failover clustering. Dersom Node1 feiler, så vil ikke vmene bli migrert til Node2 siden den da ikke har de samme nettverkene tilgjengelig) 

Dette virker nok ganske enkelt, og det er det. Men det man bør tenke på, er å sikre hosten ytterligere mot maskinene som går til DMZ.

Dersom man i Hyper-V Manager går til Virtual Network Manager, så vil man finne nettverkene man har konfigurert til de virtuelle maskinene på hosten.
La oss markere nettverk ‘DMZ’, og ta en nærmere kikk her.

Her ser man at man har standard haket av for ‘Allow management operating system to share this network adapter’

Dette haken bør man ta vekk i denne konfigurasjonen, og heller la den være på på kort 1 som er tildelt LANet. (Slik at man fortsatt kan nå hosten på nettverket) 

Dette var et (kort) eksempel på hvordan man kan segmentere DMZ og LAN på samme Hyper-V host.
Hva du velger å gjøre til slutt, er uansett noe som krever flere vurderinger mtp sikkerhetspolicyen i ditt nettverk. Men dette er en konfigurasjon som blir benyttet av mange der ute, og har vært i bruk i flere år.

Friday, September 17, 2010

Snapshot – fantastisk eller skummelt ?

Hyper-V har støtte for å ta snapshots. – En ‘bilde’ av hele den virtuelle maskinen som inkludererer status, data, og hardware konfigurasjonen.

Snapshots er en enkel og rask måte å reverse 'ståa' på en virtuell maskin.

Man installerer en applikasjon på en vm, som igjen viser seg å være katastrofal.
Dersom man har tatt et snapshot i forkant her, kan man legge dette tilbake med to museklikk som om ingenting har hendt. Dermed kan man legge inn applikasjonen på riktig måte om nødvendig.

Hva skjer når man tar et snapshot av en VM som kjører  ?
Når man tar snapshot av en vm, så blir det som nevnt tidligere tatt et ‘bilde’ av status, data, og hardware konfigurasjon. Rent teknisk skjer følgende:
1.       Filer blir opprettet i samme mappe som den virtuelle harddisken.
·         NY GUID: En mappe som inneholder .vsv og .bin filer (Dette blir ikke opprettet dersom maskinen er AV når man tar snapshots. Husk at man ikke kan ta snapshot av maskiner som har status ‘Pause’)
·         En (ny) .avhd fil i F:\VM mappen som er en differensiell disk av .vhd filen. Dette blir nå den fungerende harddisken til den virtuelle maskinen.
2.       En kopi av den virtuelle maskinens .xml konfigurajon er lagret med det nye GUID navnet

Dersom man nå tar enda et snapshot vil samme process oppstå, der den nye .avhd filen som blir opprettet vil bli en differensiell disk av den forrige .avhd filen. Dette repeteres hver gang man tar et snapshot.

Hva skjer dersom man reverserer et snapshot ?
Når man velger å reversere et snapshot til en VM, så blir det også opprettet en ny .avhd fil, som igjen blir differensiell av .avhd filen som du nettopp reverserte og all data vil dermed bli skrevet til denne fra nå av.
Dersom maskinen kjører når man reverserer et snapshot, blir også .vsv og .bin filen lagt tilbake.
Dersom maskinen er av blir ikke disse med, og maskinen forblir av etter man har lagt tilbake snapshot.

Snapshots – best practices:

Man bør ikke bruke snapshots på maskiner i produksjon. Spesielt ikke på domenekontrollere.
Dersom man reverserer et snapshot på en domenekontroller, kan man ødelegge for andre domenekontrollere, da disse replikerer kritiske data i din infrastruktur.

Snapshots er best egnet for utvikling og test, da det ikke er fare for datatap av kritiske tjenester og applikasjoner.
Man skal også være litt obs på diskplass når man jobber med snapshots, og alltid huske på at det ikke er en erstatning for backup !

Hvordan blir man kvitt .avhd filene ?

Dersom  man ønsker å gå tilbake til det opprinnelige, nemlig en .vhd fil, må man slette alle snapshots fra den virtuelle maskinen.
Dette gjøres best ved å slette alle snapshots, slå av maskinen, og vente 1 minutt.
Prosessen som kjøres da, blir kalt for ‘merging’ (fletter sammen dataene til en fil). Da blir .avhd filene ‘merget’ tilbake til den opprinnelige .vhd filen, og man er tilbake til utgangspunktet med en (eller flere) .vhd disk(er).

Live migrate to...Windows Azure?

Hvordan ser morgendagens IT-administrasjon ut?

I disse nettsky-dager kan man falle for fristelsen å fantasere over fremtidens IT-administrasjon.
Vi har fått Windows Azure, AppFabric, og SQL Azure fra Microsoft. Alle disse er tilrettelagt PaaS og Saas. Men hva skjer med IaaS ?

Jeg venter på mulighetene til å kombinere private – og public cloud når det gjelder infrastruktur.
Det ideelle hadde vært (dersom man har en privat cloud basert på Hyper-V og SCVMM) å utvide Active Directory med  Windows Azure. Da kunne man administrert alt fra SCVMM, og det hadde gitt følgende muligheter:
1.       Live Migration til og fra Azure
2.       Eliminerer kanskje behovet for DR-site
3.       Gir en skalerbarhet som ikke har sammenligning
4.       Langt bedre nattesøvn

Punkt 4 er ikke bare avhengig av akkurat dette, men iallefall et supplement.

Spørsmål: Er det noen grunn til at dette ikke skal gå ?
Pr dags dato mangler vi selvsagt støtte for dette, men rent teknisk er det mulig, - på lik linje som å ha flere datasentre.
I dette yrket kan man heldigvis si at ‘alt går an’.
Derfor kan også IT-administratoren glede seg over  fremtiden, - ikke bare utvikleren.

Wednesday, September 15, 2010

Hyper-V og prosessorer

Hvordan kan man prioritere prosessorkraft til en vm i Hyper-V ?

Prosessorregelen i Hyper-V 2008 R2 er 1:8
Dvs, at en logisk prosessor = 8 virtuelle prosessorer.

Man kan kjøre forskjellige OS instanser som vm i Hyper-V,  og det varierer i antall prosessorer som er støttet ( )

Max pr vm er 4 CPU`er.
Så dersom man har 2 logiske prosessorer, og to virtuelle maskiner som begge har 4 CPU`er tildelt, hvordan kan man da angi prioritet ?

I Hyper-V manager, høgreklikk på maskinen du vil prioritere, og velg 'Settings'.

Klikk 'Processor', og konfigurer.

Virtual Machine reserve (percentage): Spesifiserer prosenten som er resververt for denne vm. Denne innstillingen garanterer at prosenten du setter er tilgjengelig for denne vm.

Virtual machine limit (percentage): Spesifiserer maximum prosent som kan bli bruk av denne vm.

Relative weight: Angir hvordan Hyper-V allokerer ressurser til denne vm når flere vm konkurrerer om samme ressurs.

Så ved hjelp  av disse innstillingene, kan man angi prioritet på en vm.

SCVMM 2008 R2 og domene kontroller

SCVMM 2008 R2 installert på en domenekontroller ?

Dersom man har et stramt budsjett, manko på hw, men alikevel har behov for SCVMM (naturligvis) i din virtuelle infrastruktur, kan man installere denne på en domene kontroller.
Jeg vil selvsagt ikke anbefale dette, men vil gi dere et tips her, som kan virke ganske logisk til slutt.

Under installasjonen, kan man støte på følgende melding:
"Error (2927)
A Hardware Management error has occurred trying to contact server DC.testnett.local.
(Unknown error (0x80338104))
Recommended Action
Check that WinRM is installed and running on server DC.testnett.local. For more
information use the command "winrm helpmsg hresult"."

Årsaken til denne meldingen er fordi maskinkontoen DC ikke er lagt til gruppen 'Local Administrator' på server, og siden denne gruppen ikke eksisterer på maskinen siden det er en domene kontroller, må man legge til maskinkontoen i "testnett.local\Builtin/Administrator via Active Directory konsollet.
Da vil installasjonen gå som smurt.

Jeg benytter anledningen til å gjenta meg selv: Jeg vil ikke anbefale å installere scvmm på en domene kontroller.

Tuesday, September 14, 2010

Slå av HA på vm i Failover Clustering ?

Forleden ble jeg spurt om hvordan man kan 'skru av' HA på en VM i Failover Clustering.
Årsaken til dette, var fordi at brukeren ikke ville at disse vmene skulle bli flyttet over til en av de andre nodene (node 2 og 3), siden node 1 skulle få installert ekstra RAM.

First thing first: Hele hensikten med Failover Clustering, er at man har tjenster/maskiner tilgjengelig via High Availability. Når man oppretter en vm i et failover cluster, bør man gjøre dette enten via Failover Cluster Manager, eller via SCVMM, dersom man har dette tilgjengelig. Dersom man ikke ønsker at en vm skal være HA, må man opprette denne via Hyper-V manager på en av nodene, og gjerne spesifisere storage til DAS, og ikke shared.

Tilbake til problemstillingen: 'Slå av' HA på vm i Failover Clustering.
For å komme i mål her, må man ta ressursen(e) offline i clusteret, og bruke export/import i Hyper-V manager.
En annen måte å gjøre det på, er å bruke 'Migrate' i SCVMM, til å migrere over nettverket til DAS på en av nodene.

Dersom man først har merket en maskin for HA, er det ingen måte utenom å reversere dette på.