Archívum

Archive for the ‘Virtual Server/Hyper-V’ Category

VM migráció 2008 R2-ről 2012 R2-re

június 11, 2015 Hozzászólás

Adott helyen a kollégák át akartak mozgatni egy 2008 R2-es rendszeren futó virtuális gépet egy 2012 R2 gazdagépre. Nos, ebben az esetben a javasolt megoldás (ha nincs SCVMM) a VM export-import elvégzése. Igen ám, de a 2012 R2-re történő import során hibaüzenetbe futottak:

Hyper-V did not find virtual machines to import from location ‘E:\VM’

Ugyanez a gép csont nélkül importálható volt egy tesztelésre felhúzott „sima”, R2 nélküli Windows 2012-re, így egyértelműen nem az export során keletkezett hiba – de a továbblépéshez a segítségem kérték.

Anélkül, hogy túlzottan belemennénk, a történet csak annyi, hogy míg Windows 2012-ben „csak” elavult technológiának lett minősítve a „WMI root\virtualization namespace v1” névtér (ezt használja a Hyper-V), s mellé be lett vezetve a v2, az R2-ben előbbi eltávolításra is került. Az export viszont még természetesen a v1-el készült, amit a 2012 R2 már nem tud értelmezni. Elég sok kerülő megoldás létezik, ebből talán a legegyszerűbb, ha az eredeti virtuális gép .xml állományát (ami maga a gépet írja le) bemásoljuk az exportot tartalmazó mappába – s máris sikeres importnak lehetünk tanúi.

Igen ám, de hol találjuk ezt az .xml-t? Nos, ha nem konfiguráltuk szét a rendszert (mint a kollégák), akkor ott, ahol a többi VM állománya is van, ezt akár grafikus felületen is meg tudjuk nézni (a Hyper-V gazdagép tulajdonságainál). Ha viszont már rengeteg módosítás történt, szanaszét szórták a Snapshot, Smart Page, merevlemez állományok helyét, akkor valószínűleg grafikusan már nem tudjuk megállapítani. Windows 2012-től ezt több módon is lekérdezhetjük, például PS segítségével, ahol emelt szinten futtatva a

$Config = (Get-VM VirtuálisGép).ConfigurationLocation

parancsot a $Config változóba megkapjuk a hőn áhított útvonalat. Ugyanezt le tudjuk kérdezni grafikus felületen is, ahol a virtuális gép „Move…” utasítását kiadva, „Move the virtual machine’s storage” opciót választva, majd azon belül „…different locations” lehetőségével élve tudjuk elég részletesen szabályozni a tárolandó adatok helyét.

2008/2008 R2-nél még nincs ez a lehetőségünk, sem PS-utasítások, sem a grafikus felület nem áll rendelkezésünkre egy szétkonfigurált rendszer adatainak összeolvasásához. Ekkor talán a legegyszerűbb, ha a kályhától kezdjük: a Hyper-V konzol az alábbi mappából olvassa be a virtuális gépeket a kezelőfelületbe:

C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines

Abban az esetben, ha az .xml nincs az előbbi mappában, akkor létrehoz ide egy szimbólikus linket, amely a virtuális gép „valódi” .xml-jére mutat, tehát a szimbólikus link tulajdonságait megnézve, sőt, az „Open folder location”-t megnyomva máris megnyílik a kívánt mappa.

Integration Services reloaded

április 3, 2015 7 hozzászólás

Megint belefutottam ebbe a kérdésbe, viszont az aktuális verziókkal. Ennek következtében folytatom ezt a listát, ami a virtuális vendéggépek Integration Services verzióját illeti (teljesség igénye nélkül):

6.0.6001.17101 – 2008 RTM

6.0.6001.18016 – 2008 + KB950050

6.0.6001.22258 – 2008 + KB956710

6.0.6001.22352 – 2008 + KB959962

6.0.6002.18005 – 2008 + SP2

6.0.6002.22233 – 2008 + KB975925

6.1.7600.16385 – 2008 R2 RTM

6.1.7600.20542 – 2008 R2 + KB975354

6.1.7600.20683 – 2008 R2 + KB981836

6.1.7600.20778 – 2008 R2 + KB2223005

6.1.7601.16562 – 2008 R2 + SP1 Beta

6.1.7601.17105 – 2008 R2 + SP1 RC

6.1.7601.17514 – 2008 R2 + SP1 RTM

6.2.8250.0 – 2012 Beta

6.2.8400.0 – 2012 RP

6.2.9200.16384 – 2012 RTM

6.2.9200.16433 – 2012 + KB2770917, de itt csak akkor, ha a vendég OS verziószáma >6 (Vistától felfele)

6.3.9600.16384 – 2012 R2 RTM

6.3.9600.17415 – 2012 R2 + KB3000850

Egy futó gépre telepített összetevőket talán a legegyszerűbb a gazdagépról lekérdezni, pl. PS-segítséggel: Get-VM | ft Name, IntegrationServicesVersion

Amennyiben több infóra van szükségünk, újabb lehetőségek előtt állunk, pl. a gazdagépen telepített komponensek verziójának lekérdezése:

  1. a %Windir%\System32 könyvtárba települő driver, tipikusan a C:\Windows\System32\drivers\vmbus.sys verziója
  2. előbbi lekérdezése parancssorból:

wmic datafile where name=”C:\\windows\\system32\\drivers\\vmbus.sys” get version

3. registry megtekintés (ez kicsit többet árul el, mint az előzőek): HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\GuestInstaller\Version\Microsoft-Hyper-V-Guest-Installer-Win6x-Package (esetleg Win5x) értéknek a Data adata (MS)

A vendégeken található komponens lekérdezésére szintén alkalmas az előbb felsorolt első két lehetőség, de járható még az Eszközkezelő/Virtual Machine Bus/Tulajdonságok/Driver fül/Driver verzió útvonal is.

VmWare konverzió

június 6, 2014 6 hozzászólás

Bár arra számítottam, hogy kissé utolérem magam (bloggolásban is), egy közepes projekt esett rám (Scale-Out Fileserver-ek, fürtök), így lehet, hogy továbbra is marad a ritka bejegyzés-sűrűség (persze, ha belefutok egy-két nyalánkságba, kiteszem).

Kezdjük mindjárt az elejével. Megszüntetjük a VmWare virtualizációt, teljesen áttérünk Hyper-V-re, viszont van még néhány Windows 2000 (igen, még létezik 🙂 ), amelyeket ideiglenesen nem szabad kiütni. Nos, ezek konverziója nem sikerült teljesen zökkenőmentesen. Figyelembe kellett venni, hogy SCSI-lemezeket használtak rendszer-lemezként – ezt pedig csak a 2012 R2 (Gen2) tudja, de Win2012-től a Windows 2000 már nem támogatott vendég.

A kollégák ettől függetlenül megpróbálták konvertálni – s a legtöbb konverziós módszer elvérzett (pl. eleve a Disk2vhd kiesett, a VSS hiánya miatt), a kapott hiba: 0x0000007B, Inaccessible_Boot_Device.

A megoldás során csatoltunk egy IDE-lemezt (ez lehet akár üres is), így indítva a virtuális gépet „rendesen”* települ az IDE-driver is. Ezután már akár jó lehetne – esetünkben nem volt elég, át kellett tükrözni a C: tartalmát az IDE-lemezre (pl. Paragon, Acronis), s arról bootolni.

* A neten természetesen vannak módszerek, hogy miként lehet offline módon, akár konverzió után is betenni az IDE-meghajtót, de amíg van működőképes VmWare-gépünk, jobb előre felkészülni.

Az, hogy a támogatás hiánya miatt a 2008 R2-s Hyper-V integrációs komponenseket kell telepíteni, már csak legyintésre volt méltó… – még mindig jobb, mint a Win98-as integrációs komponensei (amit egy Virtual Server 2005-ből kellene venni) 🙂

Windows 8 „XP Mode”

július 19, 2013 Hozzászólás

Igaziból nem is tudom, miért nem lett publikálva, itt maradt piszkozatként…

Bár ebben a cikkben azt mondtam, hogy nem lesz XP Mode, azt nem említettem, hogy attól még van „utód”, a RemoteApp formájában. Igaziból ez sem számít akkora újdonságnak, hiszen már Windows 2008 óta létezik, most viszont kliens-gépen fogjuk tudni élesíteni: elő fogjuk varázsolni a Hyper-V alatt futó gép alkalmazásait, ehhez ennek a cikknek a tudását is felhasználjuk.

Mielőtt belefognánk, természetesen fontos tisztázni, hogy a licencelésre vonatkozóan helytáll a múltkori kijelentésem, magyarul a virtuális gép jogtisztaságát is meg kell oldani.

Ha a hagyományos értelemben vesszük, akkor a távoli alkalmazások beállításait, a RemoteApp and Desktop Connections testreszabását a Vezérlőpulton találjuk. Mivel viszont itt nem egy kiszolgálóhoz csatlakozunk, sőt a vendég-operációs rendszer sem „mai gyerek”, így ezt máshonnan közelítjük meg.

A lépések nagy vonalakban (mindezt a vendég gépen):

–       engedélyezzük a távoli asztali kapcsolatot

–       telepítjük és engedélyezzük az integrációs összetevőket

–       feltelepítjük a RAIL (Remote Applications Integrated Locally) komponenst (ez a KB961742-v3 nevű foltot jelenti)

–       újraindítás után a Registry-ben módosítjuk az alábbi értéket: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList kulcsnál az fDisabledAllowList értéket 1-re.

A gazdagépről ezután ellenőrizzük az RDP-kapcsolatot a célgép irányába, esetleg elmentjük a kapcsolódási felhasználónév/jelszó párost, majd létrehozunk egy „célzott” RDP-állományt (az alábbiakban pl. VirtualXP nevű géphez csatlakozunk, majd egy IE6-ban betöltjük a Google kezdőoldalát):

full address:s:VirtualXP
remoteapplicationmode:i:1
disableremoteappcapscheck:i:1
alternate shell:s:rdpinit.exe
prompt for credentials on client:i:1
remoteapplicationname:s:Régi IE
remoteapplicationprogram:s:C:\Program Files\Internet Explorer\iexplore.exe
remoteapplicationcmdline:s:http://www.google.hu
redirectclipboard:i:1
redirectposdevices:i:0
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
span monitors:i:1
use multimon:i:1
allow font smoothing:i:1

Bár előkészítettünk mindent, az .RDP állomány aláíratlan volta miatt megkapjuk a sárga ablakot, de ezen továbblépve betöltődik a kért program.

Amire érdemes figyelni, hogy ha szükséges mentés, akkor az hova történjen – simán megtehetjük, hogy a szokásos hálózati meghajtókat csatoljuk (ha RDP-vel sem tudunk meghajtót csatolni, akkor értelemszerűen RemoteApp-al sem fogunk).

Windows 8/2012 vs. Hyper-V 2.0

december 25, 2012 Hozzászólás

A blogomon már felmerült egy olyan zavaró hiányosság, ami nagyobb negatívumot jelent számomra, mint a Start menü átalakulása. Most egy másik ilyen dologról szeretnék írni: az újabb rendszerekről (Win8/2012) nem lehet régebbi Hyper-V rendszereket kezelni.

Megpróbálhatjuk telepíteni a Windows 7-es RSAT-ot, de ez egyrészt nem javasolt (nem hiába adnak ki minden OS-hez külön RSAT-ot), másrészt hibára is fog futni (Error 0x80096002). Ha pedig feltesszük a saját eszköztárat, akkor azzal nem fogunk tudni csatlakozni régebbi Hyper-V rendszerekhez (The operation on computer „Computer” failed).

Az ok itt van leírva. Van néhány kerülő-megoldás (távoli asztal használata, egy „régebbi” op-rendszert futtató virtuális gép, illetve a nagyágyú, az SCVMM 2012 SP1), de ha belegondolunk, akkor első esetben pont az a kényelem szűnik meg, ami jelen rendszerekben került végre bevezetésre (egy gépről vezéreljük a kiszolgálóinkat); második esetben újabb licenc szükséges; míg harmadik esetben nem kis kiadásba keveredhetünk…

Az előző gondolathoz annyi pontosítás illik, hogy mondjuk egy Windows 7/2008 R2-es rendszerről vezérelhetjük a Hyper-V 3.0 rendszereket (a cikkben is leírt, kompatibilitás megvalósított volta miatt), de jelen bejegyzésem ennek fordítottját próbálja taglalni.

Bár Windows 8-ra nem használható, de ha mondjuk egy Windows 2012 kiszolgálóról szeretnénk elérni Hyper-V 2.0 kiszolgálóinkat, létezik egy 3rd party, ingyenes alkalmazás: 5nine Manager for Hyper-V 3.0. Ezt telepítjük a kiszolgálóra, s amennyiben a kezelendő platform teljesíti a feltételeket, szinte ugyanazokat a műveleteket tudjuk végrehajtani, mint a beépített Hyper-V Manager-el. Van néhány dolog, amit csak a Full, fizetős verzióval tudunk végrehajtani (pl. csatlakozni a virtuális géphez), de az alapfeladatok ellátására teljesen alkalmas.

Client Hyper-V

október 8, 2012 1 hozzászólás

Miután már úgy éreztem, hogy a Win8 alap-funkcióit körbejártam, a kliens-oldali virtualizációt vettem górcső alá. Ennek, megkülönböztetendő a kiszolgáló oldaltól, Client Hyper-V a neve, s szinte mindenben megegyezik a Windows 2012-ben található Hyper-V 3.0-val.

Felsorolásszerűen, ami hiányzik az ügyfél-oldali virtualizációból: GPU teljes körű virtualizálása (távoli FX-képesség), virtuális gépek élő mozgatása (live migration), Hyper-V replika, SR-IOV hálózatvirtualizáció támogatás és Fibre Channel virtualizáció.

Ugyanakkor van egy másik különbség, ami nem a képességekre, hanem a hardver-követelményre vonatkozik: kiszolgáló-oldalon nem követelmény (de pl. Remote-FX használatához szükséges), kliens oldalon viszont kötelező a processzor SLAT-támogatása.

A SLAT képesség, más néven Rapid Virtualization Indexing (RVI), a két különböző gyártó esetén különböző néven szerepel. Az Intel esetén Extended Page Tables (EPT), míg az AMD esetén Nested Page Tables (NPT) kódnévvel is illetik.

Az, hogy a központi egységünk tudja-e a kívánt képességet, nem mindig egyértelmű. Intel oldalon minden „i” jelzésű proci tudja, AMD esetén pedig egy listára mutató link található a SLAT általános leírásáról szóló leírásban. Aki nem tudja, hogy milyen központi egysége van, nem akar listákat böngészni, az segéd-programok futtatásával tudja lekérdezni, pl. a cikkben is szereplő, Mark Russinovich nevével fémjelzett CoreInfo, ami – természetesen emelt szinten futtatva – kijelzi ezt. Ugyanakkor – mint béta-tesztelő –  jeleztem Fiery-nek, az Aida64 vezető fejlesztőjének is az igényt, így az előbb említett programban is bővítésre került a detektálás, sőt, most már csoportosítva lettek a virtualizációs technológiák (itt gondolok a Windows Virtual PC-hez eleinte szükséges VMX (Intel)/ SVM (AMD) támogatásra is, valamint egy Hypervisor sorra, ami a virtuális környezetet jelzi). A teljességhez még érdemes megemlíteni azt is, hogy a Client Hyper-V-hez elvárás a 64 bites processzor – dehát manapság ez ugye már „triviális”.

Amennyiben olyan egységünk van, amelyik nem tudja a SLAT-ot, akkor – egyelőre – nincs sok alternatívánk. Vagy felteszünk egy Win2012-t (járható út, de kissé túlzásnak tartom), vagy maradunk a Win7-nél – vagy váltunk ugyan Win8-ra, de más virtualizációs eszközt használunk. Azt sem zárom ki teljesen (pontosabban reménykedem), hogy a Win7 virtualizációs alkalmazásához hasonlóan itt is majd lesz egy olyan folt, aminek telepítése után (még ha csökkentett sebességgel/képességekkel is, de) elérhetővé válik a Client Hyper-V régebbi gépeken is.

Aki olyan szerencsés, hogy van SLAT-ja, ott is érdemes pár dologra figyelni a frissítés során. Az XP-mód eltűnik (végül is, „átmeneti” megoldás volt, amíg a programok W7-kompatibilisek lesznek), ezáltal a Start menüből is eltűnnek a virtuális gépbeli alkalmazások. Természetesen a virtuális gép megmarad (mint bármelyik „hagyományos” társa), de az eddigi „ingyenes” (értsd: Win7 licenc árába épített) XP licenc megszűnik, így mostantól azt is megfelelően kell licencelni.

Szóval ez ismét egy olyan pont, ahol nem felhőtlen a tapasztalatom az új rendszerrel…

SCVMM update to 2012

május 25, 2012 Hozzászólás

A napokban jutottam el odáig, hogy sikerült adott helyen egy SCVMM 2008 R2-t frissíteni SCVMM 2012-re. Mivel helyben történt a frissítés, nem tűnt nagy kunsztnak a történet. Természetesen kérte az új WAIK (2.0) telepítését (ami „természetesen” csak akkor ment fel, ha az elődjét eltávolítottam), de utána csont nélkül felment.

A következő lépés, a gazdagépeken az ügynök frissítése sem okozott nagyon nagy gondot, simán vette az akadályt.

A dolgok akkor kezdtek bonyolódni, amikor átnéztem a konzolt. 4 host, 30 virtuális gép – darabra megvoltak, de… A virtuális gépek állapotánál inkonzisztens, ellentmondásos adatok voltak: Status: Running, Virtual Machine State: Stopped.

Akárhányszor frissítettem, ugyanezt tapasztaltam. Némileg változott a helyzet, miután egyik hostot eltávolítottam a VMM konzolból, majd ismét felvettem – ekkor már az adott gazdagép virtuális gépeinek nagy részének státusa Unsupported VM Configuration-ba váltott, ami végül is bármelyik állapottal „kompatibilis” J.

Ez az állapot annak köszönhető, hogy a virtuális gépekhez csatlakoztatott telepítő ISO-k útvonala nem volt megfelelő számára. Hiába volt az adott útvonalon ott az ISO, hiába voltak meg a megfelelő jogosultságok, neki nem tetszett.

Ilyenkor két lehetőségünk van:

       felvesszük az SCVMM saját könyvtárába (Library) az ISO-t. Ekkor átmásolja a teljes telepítőt erre a kiszolgálóra

       hozzáadjuk a Library szerepkört a másik kiszolgálóhoz, amelyik tárolja a virtuális telepítő-médiákat (így).

A gond ott folytatódott, hogy a másolás is hiábavalónak bizonyult. Hiába próbáltam a konzolról beállítani az új telepítőt, egy sima „failed”-el eldobott. Pontosabban arra hivatkozott, hogy nem támogatott állapotban van a virtuális gép, előbb ezt az állapotot szüntessük meg. Az, hogy pont azt akartam tenni (magyarul: megszüntetni a neki nem tetsző állapotot), távolról sem érdekelte. Ha a Hyper-V kezelőből állítottam át, akkor előbb jogosultsági problémákra hivatkozott, majd azok megoldása után már át tudtam állítani – de a VMM-ben még mindig a régi útvonalat láttam, valamint még mindig nyafogott a konzol.

Ezek után történt a már fent említett host eltávolítás, illetve újrafelvétel. Ekkor már csodálkoztam volna, ha még mindig a régi útvonalat mutatja (ez megoldódott), ellenben legnagyobb csodálkozásomra a „riasztás” nem tűnt el – gyakorlatilag nem tetszett neki az új útvonal sem L

Egy ideig nem foglalkoztam a problémával, de végül mégiscsak segítségül hívtam az internetes keresőt… S megfelelően célzott kereséssel végül is kiderült, hogy a leírt jelenség ismert, javítása a jövőben várható: KB2690619.

Boot.wim szívatás

december 2, 2011 1 hozzászólás

A feladat: Offline módon konvertálni egy fizikai kiszolgálót, SCVMM segítségével (online működik, de most az nem volt megfelelő).

A jelenség: a konvertálandó gép bebootol WinPE-be, lefuttatja a wpeinit alkalmazást, majd ott „megáll”, gyakorlatilag visszakapjuk a parancs-sori vezérlést, úgy, hogy közben nem kezdi el másolni a merevlemez(ek) tartalmát a Hyper-V kiszolgálóra.

A nyomozás: ebben a cikkemben megemlítettem, hogy mennyire megörültem, amikor az SCVMM varázsló elkiabálta magát, hogy nincs hálózati-kártya meghajtó. Az öröm azért volt, mert noha több gépet is próbáltam offline módon konvertálni, a kezdeti (éles és teszt) gépeken nem jelzett semmi hibát a varázsló, de mindeniknél előjött a fentebb leírt hiba. Gyanakodtam, hogy nem a meghajtókkal van a hiba, hiszen az adott gépről hálózaton mindent láttam, oda-vissza lehetett pingetni, sőt, a helyi meghajtókat szintén láttam (akár Sata lemezekről, akár Raid-tömbökről volt szó). Ettől függetlenül, hiába másoltam a (természetesen VMM-host op-rendszer specifikus) meghajtóit a megfelelő helyre, mivel nem változott semmi, nem tudtam biztosan kijelenteni, hogy nem-e a meghajtókkal van mégis a gond.

A hibaüzenet alapján pedig mindenki ebbe az irányba indulna el:

 Error (13230)

Virtual Machine Manager encountered an error while connecting to the agent after restarting the computer *** into Windows PE. This error may be due to missing WinPE drivers for local storage on the source machine. 

 Recommended Action

Create a new folder under NO_PARAM on the VMM machine and copy all of the storage or networks drivers for *** to the new folder.

Ha a bootolás után nem vártam ki a kb. 30 perces time-out időszakot (ami alatt amúgy sem történik semmi), s megszakítottam a folyamatot, akkor egy másik hibaüzenetetet vágott a fejemhez:

 Error (2910)

VMM does not have appropriate permissions to access the resource  on the *** server.

 (Access is denied (0x80070005))

 Recommended Action

Ensure that Virtual Machine Manager has the appropriate rights to perform this action.

Ne tévesszen meg senkit, természetesen semmilyen jogosultsági probléma nem áll fent.

Sok helyen utalnak rá, hogy ilyenkor futtassuk le a virtualizálandó gépre vonatkozóan a VMM CA-t. Ezt lefuttatva, az eredeti W2k3 gépen semmi hibát nem talált, míg a magyar nyelvű Windows 7 esetén kifogásolta a WinRM szolgáltatás leállított állapotát. Elindítva a net start WinRM parancsot, kiderül, hogy magyarul a szolgáltatás neve Rendszerfelügyeleti webszolgáltatások (mondtam már, hogy imádom a magyar fordításokat? Grr…)

A másik, amivel kötözködött, hogy állítólag a WMI-store nem teljesen ép, s hogy futtassuk le a winmgmt /salvagerepository parancsot. A visszaadott eredmény („A WMI-tárház konzisztens”) természetesen kiakasztotta.

A továbbiakban kaptam egy olyan ötletet, hogy lehetséges, miszerint a boot.wim állomány hibás, másoljam egy W2k8 R2 Sp1 telepítő Sources könyvtárából a C:\Program Files\Microsoft System Center Virtual Machine Manager 2008 R2\VMMData\ helyre.

Az erre adott hibaüzenet sem örvendeztetett meg:

 Error (2919)

The destination file C:\Windows\TEMP\SCVMM.a17537cea4\VMM\vmmAgentPE.exe already exists or the destination device is not ready on the *** server.

 (The system cannot find the path specified)

 Recommended Action

Ensure that you have specified a valid path, delete the file if it exists, and then try the operation again.

 Ha a telepítő médiáról másoltam át a wim állományt, akkor meg:

 Error (2903)

VMM could not locate the specified file \\***\C$\SCVMM_boot\scvmm_bcd on the VMM server. This file might be required as part of another object. 

 Recommended Action

Ensure that you have specified a valid path parameter, and that all necessary files are present. Try the operation again.

 (A hibakódok megfejtését itt találjuk.)

Újabb próbálkozásként jött az ötlet, miszerint ne dinamikus lemezként, hanem fix lemezekkel dolgozzak. Nem segített.

Természetesen kipróbáltam azt is, hogy egy szűz rendszerre feltettem csak az SCVMM-et, s onnan próbálkoztam – sikertelenül.

Következett az utolsó mentsvár: MS. Itt előbb el akartak hajtani azzal, hogy a W2k3 R2-nek már lejárt a támogatási életciklusa – de mivel szerencsére kipróbáltam W7-el, s ugyanúgy sikertelen volt, fordítottam egyet a gyerek fekvésén, s így vetettem fel velük a hibát.

Első körben a logot elemeztük, s az sem segített, hogy a WinPE-ben az X: meghajtón található Wpeinit.log utolsó soraiban ezt találjuk:

Info      Successfully executed command ‘net start vmmp2vagent’ (exit code 0x00000002)

Info      STATUS: FAILURE (0x80070002)

Info      ==== Executing Asynchronous User-Provided Commands ====

Info      STATUS: SUCCESS (0x00000001)

Info      ==== Applying Shutdown Settings ====

Info      No shutdown setting was specified

Info      STATUS: SUCCESS (0x00000001)

Warning   Applying WinPE unattend settings failed with status 0x80070002; ignoring shutdown settings

A többi log, elemzés, stb. elküldése után következett egy hosszabb szünet, amikor a mérnökök összedugták a fejüket, majd egyszer csak kaptam egy levelet, amelyhez egy crc volt csatolva.

A megoldás: kiderült, hogy az eredetileg letöltött .iso telepítőben hibás volt a boot.wim. Hogy mennyi esélye van ennek, hogy pont az legyen hibás – nem firtatom (méret, verzió, minden más egyezett). Miután ismét letöltöttem, s átmásoltam a VmmData könyvtárból a helyes crc értékkel rendelkező wim-et a már említett helyre, máris lehetett offline konverziót is végezni…

XP Mode programs „Start in” folder

november 3, 2011 Hozzászólás

A múltkori cikkem kapcsán felmerült az a kérdés, hogy miként tudunk futtatni úgy XP Mode-ban programokat, hogy azok indítási helye adott mappa legyen. Konkrétan a különböző banki programokra irányult a kérdés, ahol a magyar piacon létező néhány keretprogramot olyanok, hogy úgy kell őket futtatni, hogy azok az indítás helyéről töltsenek be alap-adatokat.

Erre egy megoldás lehet az, ha az indítás helyén létrehozunk egy kötegelt állományt (.bat vagy .cmd), amely egyetlen sorban tartalmazza az indítandó programot (pl. @C:\WELECTRA\BIN32\electra.exe). Mivel alapértelmezés szerint a futtatható állományok mindig azt a könyvtárat tekintik alapnak, ahonnan elindítottuk őket, ez megoldja a problémánkat. Létrehozunk egy parancsikont, ami az előbb elkészített kötegelt állományra mutat, s ezt betesszük az All Users/Start menu-be, aminek köszönhetően kis várakozás után megjelenik „kint” is. Ha mégsem, indítsuk újra a virtuális gépet – ekkor biztosan megjelenik a W7 megfelelő menüpontjában.

Eddig tart az elmélet. A valóság viszont néha ennél sokkal durvább. Ugyanis valamilyen agyament programozó azt gondolta, hogy adott bank esetén a könyvtár nevében zárójel is szerepeljen – nos, ezt a RAIL komponens nem minden esetben szereti (még nem találtam egy rendszerességet). Ilyenkor előbb érdemes tisztába tenni az állomány-rendszert (pl. átnevezéssel).

A fenti feladatsort szinte minden bank esetén el kell játszani: létrehozni a futtatható állományt, majd arról egy parancsikont a Start menübe. Ezután még a jogosultságokat érdemes ellenőrizni, majd jöhet az éles tesztelés.

VMM 2008 R2 SP1 vs. Error 3140

október 4, 2011 1 hozzászólás

Adott probléma kapcsán (erről majd a későbbiekben fogok írni, ha megvan a megoldás) le akartam tesztelni az SCVMM terméknek a P2V konverzióját – de nem a már jól bevált, kipróbált online konverziót, hanem az offline változatot.

Erre egy nemrég frissen telepített Windows 7 fizikai gépet szemeltem ki. A P2V varázsló lépésein végigmenve, örömmel vettem észre, hogy már a varázsló figyelmeztet arra, ha a konvertálandó gép hálókártya-meghajtója nincs az általa ismert listában, s a megoldást (másoljuk a „%ProgramFiles%\Microsoft System Center Virtual Machine Manager 2008 R2\Driver Import” könyvtárba) is helyben közli.

A varázsló sikeres lefutása után viszont a feladat futtatása dobta be a törölközőt. Konkrétan elindult, majd az 1.3.1 lépésnél, 40%-nál kiírta, hogy Error 3140. Ennyi. A hivatalos fórumon a VMM CA (Configuration Analyzer) futtatása van javasolva, de tovább keresgélve, egy cseh kolléga oldalán olvasható a helyes megoldás.

A probléma gyökere ott rejtőzik, hogy a VMM által offline konverzióra használt rendszerindító nem fér bele a W7 telepítése során létrehozott 100 MB rendszerpartícióra. (Angolul a System és a Boot, magyarul Rendszer és Rendszerindító feladatkörrel jelölt partíciók esetén előbbi tartalmazza a rendszer indításához szükséges boot mappa, bootmgr elemeket, míg az utóbbi magát a Windowst.)

A megoldás a következő lépésekből áll:

  1. Emelt szintű jogokkal futtassuk le az alábbi parancsot: bcdboot c:\windows /s c:

Ekkor megtörténik a rendszerindító állományok C: meghajtóra másolása, létrejön a rejtett boot mappa és bootmgr állomány.

  1. Jelöljük meg a C: partíciót aktívként
  2. Indítsuk újra a gépet, majd ezután ellenőrizzük le, hogy a C: meghajtó lett a Rendszer feladatkörrel ellátott partíció

Ha ezután ismét futtatjuk a P2V konverziót, akkor már nem fogunk az említett hibába ütközni – esetemben más gond jelentkezett, de az már más történet J