Microsoft har släppt en produkt som heter Thin PC.
Tanken med Thin PC är att de flesta företag har en massa datorer som man gjort investeringar i. Om man sedan vill köra en VDI-lösning så är det inte alltid ekonomiskt försvarbart att bara slänga alla datorer och köpa in tunna klienter istället.
Det är här som Thin PC kliver in. Det är en liten installation av Windows. Hela nyckeln är att det inte krävs någon Virtual Desktop Access (VDA) licens.
Det går att köra applikationer direkt på Thin PC, men bara vissa sorters applikationer. Exempelvis, säkerhetsapplikationer (antivirus och dylikt), management agenter, Remote Desktop, webbläsare, mediaspelare, .Net framework, Java Virtual Machine och liknande.
Exempelvis Microsoft Office är inte en sådan applikation som går att köra lokalt på Thin PC (men hela idén med en VDI/Tunn klient är ju att ha applikationer typ office centralt :))
Lite mer läsning:
http://windowsteamblog.com/windows/b/business/archive/2011/06/07/windows-thin-pc-rtms.aspx
http://virtualization.info/en/news/2011/06/release-microsoft-windows-thin-pc-1-0.html
http://www.microsoft.com/windows/enterprise/solutions/virtualization/products/thinpc.aspx
2011-06-22
10 (eller kanske 11) tips för att maximera prestanda i VMware View.
Elias Khnaser har skrivit ihop artikeln My Top 10 VMware View Performance Tips.
Den har med ett par standardsaker för att optimera windows i en VDI-lösning, men en hel massa bra tips kring nätverksinställningar och liknande som är speciella för PCoIP.
rekommenderad läsning för alla som pysslar med VMware View (eller är intresserade av view)
Den har med ett par standardsaker för att optimera windows i en VDI-lösning, men en hel massa bra tips kring nätverksinställningar och liknande som är speciella för PCoIP.
rekommenderad läsning för alla som pysslar med VMware View (eller är intresserade av view)
2011-06-19
Bugg i installationen av XenServer 5.6 ServicePack 2
[EDIT 2011-06-27]
Se även denna bloggpost om en uppdatering som löser detta problem
[/EDIT]
Vid installationen av SP2 till Citrix XenServer 5.6 så finns det ett flertal olika sätt att göra detta.
Jag har skrivit om detta tidigare.
En sak som kanske inte alla känner till är att om man installerar SP2 genom att uppgradera befintliga servrar från XenCenter så kommer inte Buildnumret att öka...
I bilden ovan är det exakt samma uppdateringar installerade på båda servarna, det är också samma XenServer Version och Build date (allting är markerat med grönt)
Dock skiljer sig Build number. På den som är installerad från CD så är det 47101p och på den som är uppdaterad så är det build 39265p... Med andra ord har den som blivit uppdaterad inte bytt build number utan ligger kvar på FeaturePack 1, eller?
Detta problem finns beskrivet i CTX129546.
Vad som hänt är att båda servarna har rätt uppdateringar och rätt binärer. Men på den ena har inte text-filen som beskriver vilken build som är installerad blivit uppdaterad.
Så vad betyder detta i verkligheten?
Låt oss säga att vi har en XenServer pool med 4st servrar. Denna pool har FeaturePack 1 installerat.
För att göra uppgraderingen så enkel som möjligt så väljer vi att ladda ned uppdateringen och installera från XenCenter.
Detta gör att när uppdateringen är klar så kommer poolen att fungera alldeles utmärkt och alla servarna kör på precis som vanligt men nu på SP2 binärerna.
Ett halvår senare så behöver vi utöka poolen och köper en ny server. Den servern installerar vi så klart från CD-skivan med XenServer 5.6 SP2 eftersom att det är det enklaste sättet att installera nya servern.
Problemen uppstår när vi sedan försöker lägga med den nya serven i XenS erver poolen...
Då kommer vi att få meddelandet "This server server is a different version than the master".
Lösningen är att uppdatera BUILD_NUMBER i filen "/etc/xensource-inventory" på de fyra gamla servarna. från BUILD_NUMBER='39265p' till BUILD_NUMBER='47101p'.
Hur man gör detta lättast är beskrivet i denna artikel hos citrix.com. Kontentan är att köra nedanstående kommando:
# sed -i.backup "s/39265p/47101p/" /etc/xensource-inventory
och sedan köra:
# xe-toolstack-restart
(alternativt starta om hosten) , för att läsa in filen xensource-inventory igen.
En fördel med xe-toolstack-restart är att VMarna på hosten inte behöver startas om eller failas så det går rätt snabbt att göra.
Detta måste göras på alla 4 hostar och efter detta kommer alla att rapportera samma buildnummer och det går att lägga in den nya hosten i poolen.
Se även denna bloggpost om en uppdatering som löser detta problem
[/EDIT]
Vid installationen av SP2 till Citrix XenServer 5.6 så finns det ett flertal olika sätt att göra detta.
Jag har skrivit om detta tidigare.
En sak som kanske inte alla känner till är att om man installerar SP2 genom att uppgradera befintliga servrar från XenCenter så kommer inte Buildnumret att öka...
Dock skiljer sig Build number. På den som är installerad från CD så är det 47101p och på den som är uppdaterad så är det build 39265p... Med andra ord har den som blivit uppdaterad inte bytt build number utan ligger kvar på FeaturePack 1, eller?
Detta problem finns beskrivet i CTX129546.
Vad som hänt är att båda servarna har rätt uppdateringar och rätt binärer. Men på den ena har inte text-filen som beskriver vilken build som är installerad blivit uppdaterad.
Så vad betyder detta i verkligheten?
Låt oss säga att vi har en XenServer pool med 4st servrar. Denna pool har FeaturePack 1 installerat.
För att göra uppgraderingen så enkel som möjligt så väljer vi att ladda ned uppdateringen och installera från XenCenter.
Detta gör att när uppdateringen är klar så kommer poolen att fungera alldeles utmärkt och alla servarna kör på precis som vanligt men nu på SP2 binärerna.
Ett halvår senare så behöver vi utöka poolen och köper en ny server. Den servern installerar vi så klart från CD-skivan med XenServer 5.6 SP2 eftersom att det är det enklaste sättet att installera nya servern.
Problemen uppstår när vi sedan försöker lägga med den nya serven i XenS erver poolen...
Då kommer vi att få meddelandet "This server server is a different version than the master".
Lösningen är att uppdatera BUILD_NUMBER i filen "/etc/xensource-inventory" på de fyra gamla servarna. från BUILD_NUMBER='39265p' till BUILD_NUMBER='47101p'.
Hur man gör detta lättast är beskrivet i denna artikel hos citrix.com. Kontentan är att köra nedanstående kommando:
# sed -i.backup "s/39265p/47101p/" /etc/xensource-inventory
och sedan köra:
# xe-toolstack-restart
(alternativt starta om hosten) , för att läsa in filen xensource-inventory igen.
En fördel med xe-toolstack-restart är att VMarna på hosten inte behöver startas om eller failas så det går rätt snabbt att göra.
Detta måste göras på alla 4 hostar och efter detta kommer alla att rapportera samma buildnummer och det går att lägga in den nya hosten i poolen.
2011-06-14
Information inför val av hypervisor för stora virtuella maskiner... (VMware, Hyper-V, XenServer)
Information inför val av hypervisor för stora virtuella maskiner.pdf
Som jag ser det så finns det tre stora spelare på marknaden när det gäller hypervisors för servrar. Det är så klart VMware med vSphere, Microsoft med Hyper-V och Citrix med XenServer.
Idag är det norm att virtualisera servrar. Det är absolut inget konstigt med att virtualisera de flesta servrar idag.
Utmaningarna med att fortsätta virtualisera är de där sista 20 procenten.
Vad jag försöker säga är att typ 80% av alla servrar är sådana att de är relativt enkla att virtualisera, de har rätt liten last på sig och därför bra kandidater.
De sista 20% är servrar med höga krav på CPU, minne, disk och/eller nätverks I/O.
Eftersom att det börjar bli allt vanligare att ett företag har mer än en hypervisor så blir frågan numera inte ”skall vi virtualisera denna server?” utan mer ”på vilken hypervisor skall vi virtualisera denna server?”. Helt enkelt vilken hypervisor som är lämpligast att använda för varje server och det är där detta whitepaper förhoppningsvis kan svara på en del frågor.
Självklart är det inte så enkelt att det räcker med att titta på CPU, minne och disk. I slutet står det:
Som jag ser det så finns det tre stora spelare på marknaden när det gäller hypervisors för servrar. Det är så klart VMware med vSphere, Microsoft med Hyper-V och Citrix med XenServer.
Idag är det norm att virtualisera servrar. Det är absolut inget konstigt med att virtualisera de flesta servrar idag.
Utmaningarna med att fortsätta virtualisera är de där sista 20 procenten.
Vad jag försöker säga är att typ 80% av alla servrar är sådana att de är relativt enkla att virtualisera, de har rätt liten last på sig och därför bra kandidater.
De sista 20% är servrar med höga krav på CPU, minne, disk och/eller nätverks I/O.
Eftersom att det börjar bli allt vanligare att ett företag har mer än en hypervisor så blir frågan numera inte ”skall vi virtualisera denna server?” utan mer ”på vilken hypervisor skall vi virtualisera denna server?”. Helt enkelt vilken hypervisor som är lämpligast att använda för varje server och det är där detta whitepaper förhoppningsvis kan svara på en del frågor.
Självklart är det inte så enkelt att det räcker med att titta på CPU, minne och disk. I slutet står det:
En utmaning som jag sett på ett flertal företag är att man har servrar med stora prestandakrav. Därför köper man in jättestora och dyra servrar som sätts upp enligt konstens alla regler. Eftersom man har lagt ned rätt mycket tid på att få allting rätt får därefter dessa servrar leva rätt länge innan man byter ut dem.
Om man istället lägger dessa servrar i en virtuell miljö så får man en prestandapåverkan från hypervisorn som kan vara allt mellan 5-10% (beroende på vem man fråga och vilken typ av server det är). Den stora fördelen kommer dock när det släpps en ny processor eller en ny servermodell. Eftersom att servern är virtualiserad kan man flytta över den virtuella servern till den nya hårdvaran och dra nytta av denna prestanda höjning!
Detta i sin tur betyder att när det gått tre år så körs fortfarande servern på den bästa och modernaste hårdvaran och användarna får en bra upplevelse, istället för att ha en serverhårdvara som ligger generationer efter…
Självklart är det inte alltid så enkelt att det bara går att göra, men tanken med detta dokument är att väcka tanken, och ge lite information kring vad vi idag kan göra.
Två bilder från dokumentet:
2011-06-13
Har du en VM som tar för mycket disk i/o?
Det går att begränsa så att inte en enda vm tar alla disk iops.
http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&externalId=1038241
kortaste bloggposten hittills? :)
http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&externalId=1038241
kortaste bloggposten hittills? :)
Prenumerera på:
Inlägg (Atom)
