VS2005 és az optikai meghajtók

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

Adott helyen felmerült a kérdés, hogy egy Virtual Server-ben található vendég-géppel valami baj van.

A jelenség abból áll, hogy a gazdagép (host) optikai meghajtója van hozzárendelve, de amikor abban adathordozót cserélnek, ezt a vendég-gép nem veszi észre. A kiszolgáló naprakész, eseménynaplóban nincs hibaüzenet – a kollégák tanácstalanul álltak a jelenség előtt.

Egy ideig én sem tudtam vele mit kezdeni. Majd nekiálltam keresgélni, míg kiderült, hogy igen, a VS2005 R2 SP1-ben valóban létezik ez a hiba (örök informatikus vicc: nem bug, hanem feature :) ), de nem lesz rá javítás. Részben értem, hiszen mióta itt már van a Hyper-V – de mi van azokkal a gépekkel, amelyek különböző okok (fizikai korlát, licencelés, stb.) miatt nem tudják futtatni? Tényleg olyan nehéz lett volna kijavítani?

Megoldás tehát nincs. Szerencsére van kerülőút, ami a virtuális gép-park kezelésére szolgáló eszköztől függetlenül megvalósítható. Pl. ha a beépített, weboldalas virtuális gép-kezelőt használjuk, akkor a „No media” opciót kell kiválasztani az optikai meghajtónál, majd utána ismét a gazdagép megfelelő eszközére mutatni; míg a VMRC Plus programot használok esetén jobb egérrel a meghajtón, majd „Mount Host drive” parancs segítségével tudják frissíteni a vendég-gép optikai meghajtójának tartalmát. A „nagyobb” eszköz-kezelőkre (pl. SCVMM) most nem térek ki…

Plusz információnak még annyi, hogy bizonyos esetekben ugyanez a helyzet a csatolt ISO állományokkal is, a fenti kerülőút esetükben is megoldás.

(forrás: Asteriksz blogja)

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

HOZZÁSZÓLÁS

Ha nem hagy nyugodni az, amit a cikkben olvastál, akkor nyugodtan írd meg kérdésed vagy észrevételed kommentbe. Így szerzőnk könnyen tud neked válaszolni.

Vélemény, hozzászólás?

VS2005 és az optikai meghajtók

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

Adott helyen felmerült a kérdés, hogy egy Virtual Server-ben található vendég-géppel valami baj van.

A jelenség abból áll, hogy a gazdagép (host) optikai meghajtója van hozzárendelve, de amikor abban adathordozót cserélnek, ezt a vendég-gép nem veszi észre. A kiszolgáló naprakész, eseménynaplóban nincs hibaüzenet – a kollégák tanácstalanul álltak a jelenség előtt.

Egy ideig én sem tudtam vele mit kezdeni. Majd nekiálltam keresgélni, míg kiderült, hogy igen, a VS2005 R2 SP1-ben valóban létezik ez a hiba (örök informatikus vicc: nem bug, hanem feature :) ), de nem lesz rá javítás. Részben értem, hiszen mióta itt már van a Hyper-V – de mi van azokkal a gépekkel, amelyek különböző okok (fizikai korlát, licencelés, stb.) miatt nem tudják futtatni? Tényleg olyan nehéz lett volna kijavítani?

Megoldás tehát nincs. Szerencsére van kerülőút, ami a virtuális gép-park kezelésére szolgáló eszköztől függetlenül megvalósítható. Pl. ha a beépített, weboldalas virtuális gép-kezelőt használjuk, akkor a „No media” opciót kell kiválasztani az optikai meghajtónál, majd utána ismét a gazdagép megfelelő eszközére mutatni; míg a VMRC Plus programot használok esetén jobb egérrel a meghajtón, majd „Mount Host drive” parancs segítségével tudják frissíteni a vendég-gép optikai meghajtójának tartalmát. A „nagyobb” eszköz-kezelőkre (pl. SCVMM) most nem térek ki…

Plusz információnak még annyi, hogy bizonyos esetekben ugyanez a helyzet a csatolt ISO állományokkal is, a fenti kerülőút esetükben is megoldás.

(forrás: Asteriksz blogja)

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

HOZZÁSZÓLÁS

Ha nem hagy nyugodni az, amit a cikkben olvastál, akkor nyugodtan írd meg kérdésed vagy észrevételed kommentbe. Így szerzőnk könnyen tud neked válaszolni.

Vélemény, hozzászólás?


Warning: Unknown: write failed: No space left on device (28) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/www/clients/client0/web5/tmp) in Unknown on line 0