Script-elt OVA/OVF deploy free ESXi-n

 ( Ligend | 2018. június 4., hétfő - 12:34 )

Sziasztok!

Egy egzotikus probléma megoldásához OVF Tool-t kell futtatnom 6.5 és/vagy 6.7-es ESXi host-on, kickstart-ból.

ESXi 6.7-tel (már) nincs probléma, működik az OVF Tool 4.3.0, azonban 6.5U2 alatt kapok egy hibaüzenetet (mint látható, a 4.2.0 és a 4.1.0 fut):

[root@esxi01:/vmfs/volumes/5b112475-555add4f-64d9-005056914e87] vmware -v
VMware ESXi 6.5.0 build-8294253
[root@esxi01:/vmfs/volumes/5b112475-555add4f-64d9-005056914e87] sh ./ovftool.410/ovftool -v
VMware ovftool 4.1.0 (build-2459827)
[root@esxi01:/vmfs/volumes/5b112475-555add4f-64d9-005056914e87] sh ./ovftool.420/ovftool -v
VMware ovftool 4.2.0 (build-5965791)
[root@esxi01:/vmfs/volumes/5b112475-555add4f-64d9-005056914e87] sh ./ovftool.430/ovftool -v
./ovftool.430/ovftool.bin: error while loading shared libraries: libicudata.so.58: failed to map text segment from shared object: Error 28

Van valakinek ötlete, hogyan lehetne megoldani, vagy legalábbis debug-olni a 4.3.0 futtatását ESXi 6.5 alatt?

Megjegyzések:
- tisztában vagyok vele, hogy az OVF Tool futtatása nem támogatott ESXi-n
- OVF Tool 4.2.0 működik 6.5 és 6.7-en is, azonban...
-- ESXi 6.7 hivatalosan nem támogatott ezzel a verzióval
-- a 4.3.0 tartalmaz olyan új feature-t, amit használnom kell (link)
- egyelőre nem használhatok ESXi 6.7-et

Bármilyen, a probléma megoldására nézve konstruktív javaslatot örömmel fogadok.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"egyelőre nem használhatok ESXi 6.7-et"
vs.
"ESXi 6.7-tel (már) nincs probléma"

Úgy látom kezedben a megoldás :)

Mi a rossebet kell kickstart közben OVF-ből telepítened? :)

Szerk.: ha csak cput és/vagy memoryt kell növelned/csökkentened, azt megteheted deployment után is, nem?

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Bár ilyen egyszerű lenne...

Pontosítok; tesztelem az ESXi 6.7-et, de azzal még nem adhatom ki a megoldást, mert csak a 6.5U2 használatát engedélyezik. Célom, hogy olyan megoldást készítsek, ami alatt később csak a hypervisort kell kicseréléni, amint a 6.7 zöld utat kap. Ha nem oldható meg, akkor feladom elveimet és más sciprt lesz 6.5 alatt, mint amit majd 6.7-ben ˝alkalmazok.

Jelenleg az a helyzet, hogy:
- ESXi 6.5U2, OVTool 4.2.0, tákolt megoldás vCPU és vRAM beállításra (pl. sed a vmx-re)
- ESXi 6.7 GA, OVFTool 4.3.0, támogatott vCPU és vRAM customization

A feladat 1 db ISO elkészítése, amit több tucat, különböző szakmai felkészültségű ember ember használ a világ számos pontján. Erről húzzák fel az ESXi-t, a script pedig beavatkozás nélkül elkészíti a vSwitch-eket, port group-okat, valamint 1 db template-ből deploy-ol 5+ VM-et (amiknek más-más a vCPU és vRAM igénye). Hálózati elérés még nincs, vagy nem lehet rá számítani. Amint a remote access működik, a deploy-olt VM-ek központi konfig menedzsmentből megkapják a végleges konfigurációjukat.

A folyamatot nem én találtam ki, csak a közelgő ESXi 5.5 EoL-ra kell megoldást adnom. Sajnos nincs módom megreformálni a deploy folyamatot.

A fő kérdés az, hogy mi lehet az oka, hogy ami fut ESXi 6.5 alatt, az nem működik 6.7-en. Miért nem tudja betölteni az OVF Tool a külső library-t, mi az a hiba, ami miatt elszáll? Google barátom nem volt túl segítőkész a hibaüzenetre.

Azert az a "sed a vmx-re" workaround nem tunik tulzottan nagy takolasnak. Talan egy kicsivel elegansabb megoldas, ha meg a deployolas elott az OVF-et modositod.

Egyebkent a template honnan jon? Bele van buildelve a custom ESXi iso-ba? Ha igen, akkor mar miert nem a vegleges meretre meretezett template kerul bele?

Tákolás, mert utána reload-olni kell a regisztrált VM-eket, hogy a UI is frissítse az erőforrás allokációt.

1db generic template van az ISO-ban (ráadásul OVA, nem is OVF), minimális kezdő erőforrás-értékekkel (pl: 1 vCPU, 1GB RAM, 10GB disk). Ebből kell több, különböző célra előkészített VM-et példányosítani. Ezek más hálózatokba kapcsolódnak, más a RAM, CPU és diszk kapacitásuk. A régi OVF Tool a hálózatok kérdését kezelte a --net:"dummy"="az_en_port_groupom" kapcsolóval, és 4.3 óta a CPU és memória felüldefiniálását is (pl: --numberOfCpus:'*'=4 --memorySize:'*'=4096). Jó hír volt, hogy legalább ezeket nem kellett sed-del csereberélni, és átláthatóbb, kompaktabb marad a script.

A template-et igyekszem annyira általánosan tartani, amennyire lehetséges. Persze megoldható lenne, hogy annyi OVF állományt készítek el, ahány különböző erőforrású VM-em, és egy közös VMDK-t hivatkozik mind, de ez akkor lesz nehezen karbantartható, ha N db új VM-et kell hozzáadni. Egyszerűbbnek hangzik a deploy-ra használt script-en átírni 3-4 paraméter értékét, mint új OVF-et hozzáadni a csomaghoz.

BTW, nem ok nélkül hozta be a VMware az új OVF Tool-ba ezeket a deployment során alkalmazható testreszabásokat (vSphere-re is, mert eddig is működött, csak vCloud-ra), ahelyett, hogy a sed-et javasolná az ügyfeleknek. :)

Koztes megoldas lehet, ha egy generic.ovf+vmdk -t teszel az iso-ba, majd a kickstart soran seddel elkeszited a kulonbozo meretu ovf variaciokat (amik nyilvan ugyanarra a vmdk-ra mutatnak). Tovabbiakban is csak a generic.ovf-et kell karbantartani, a tobbi meretvarians dinamikusan kepzodik.

"Célom, hogy olyan megoldást készítsek, ami alatt később csak a hypervisort kell kicseréléni, amint a 6.7 zöld utat kap. Ha nem oldható meg, akkor feladom elveimet és más sciprt lesz 6.5 alatt, mint amit majd 6.7-ben ˝alkalmazok."

Teszteld a scriptben a verziót és futtass más parancsokat 6.5 és 6.7 esetén.

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Mivel korlátozott idő áll rendelkezésemre, valószínűleg ez lesz. Két OVF Tool-t pakolok az installerbe, és ESXi 6.5-ön 4.2-t használok utófeldolgozással, 6.7-en pedig 4.3-as OVFTool fut majd más paraméterekkel.

Na akkor várjuk megy William Lam mit mond a commentedre, azt hiszem ennél gyorsabb supportot nem fogsz kapni máshonnan se :)

Diszkméret növelésre meg vmkfstools :)
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Benne van minden reményem. ;) Ott bukhat a dolog, hogy senki nem állítja hivatalosan, hogy ESXi shell-ben fut(hat) a tool, de várjuk meg a választ.

Használom a vmkfstools-t, ahogy eddig is, ebben nincs változás. Mindössze bosszant, hogy 3 fő VM paraméterből csak 2-t lehet override-olni, immár vSphere target-nél is. Feltehetően a nagy ügyfelek a diszket nem, csak a CPU és RAM értékeket kérték konfigurálhatónak.

Ha jól tudom az OVF 2.0 szabványban tudsz megadni többvéle deployment szekciót, amit pl. tudsz egy Small/Medium/Large méretezésre használni

981 sortól
https://www.dmtf.org/sites/default/files/standards/documents/DSP0243_2.1.1.pdf

1847 sortól van példa is rá

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Ez egy jó ötlet (köszönet érte), utána fogok nézni.

Tartok tőle azonban, hogy jelen esetben nem tudni majd profitálni belőle, ugyanis:
"Although it supports OVF specifications 0.9 and 1.0, OVF Tool does not support OVF specification 2.0 (not to be confused with OVF Tool version 2.0)."

Mindenesetre adtál egy ötletet. Megnézem, a VMware hogyan oldja meg a vCenter Server Appliance különböző méretezésű telepítését, hátha tudok belőle felhasználni valamit.

Ha csak vCPU es vMEM-et kell customizalni, akkor nekem nagyon gyorsan az xmlstarlet szokott előkerülni. Mondjuk nemcsak akkor, CI-ban úgy átfazonírozom vele az ovftool-lal generált OVF-eket, hogy rá sem ismerni. :)

IN_OVF="$1"
OUT_OVF="$2"
NEW_VCPU_COUNT="$3"
NEW_VMEM_SIZE="$4"

XSD_URI_OVF="http://schemas.dmtf.org/ovf/envelope/1"
XSD_URI_RASD="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData"

xmlstarlet ed --omit-decl -S -N "ovf=${XSD_URI_OVF}" -N "rasd=${XSD_URI_RASD}" \
  --update "/ovf:VirtualSystem/ovf:VirtualHardwareSection/ovf:Item[rasd:Description/text()='Number of Virtual CPUs']/rasd:VirtualQuantity" --value "${NEW_VCPU_COUNT}" \
  --update "/ovf:VirtualSystem/ovf:VirtualHardwareSection/ovf:Item[rasd:Description/text()='Number of Virtual CPUs']/rasd:ElementName" --value "${NEW_VCPU_COUNT} virtual CPU(s)" \
  --update "/ovf:VirtualSystem/ovf:VirtualHardwareSection/ovf:Item[rasd:Description/text()='Memory Size']/rasd:VirtualQuantity" --value "${NEW_VMEM_SIZE}" \
  --update "/ovf:VirtualSystem/ovf:VirtualHardwareSection/ovf:Item[rasd:Description/text()='Memory Size']/rasd:ElementName" --value "${NEW_VMEM_SIZE}MB of memory" \
  "${IN_OVF}" > "${OUT_OVF}"

Nyilván kicsit komplikálódik a dolog, ha VirtualSystemCollection van több VM-mel, az xpath-okat kicsit át kell alakítani, de nem vészes, kb ilyesmi lesz a prefix:

/ovf:VirtualSystemCollection/ovf:VirtualSystem[@ovf:id='${VM_ID}']/ovf:VirtualHardwareSection/

Ha van manifest file is, akkor a végén egy sha1sum-mal helyre kell rakni az ovf checksum-ját.
---
Régóta vágyok én, az androidok mezonkincsére már!

Csak hogy ESXi-n nincsennek ilyen xml manipulalo toolok.

Akkor sajnos marad a sed. Vagy valami koncepcionális újratervezés, hogy mégse ESXi-n kelljen futtatni olyan dolgokat, amik nem oda lettek kitalálva.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ezen is törtem a fejem, hogy mivel lehetne kiváltani az OVF Toolt, de nem jutottam megoldásra. Mindössze azért nem szeretnék fellőni egy támogatott Linux alapú VM-et, helyben, hogy arról deploy-oljam a többi VM-et. Helyben, mert remote ugye nem érem el az ESXi-t a telepítés ezen szakaszában. Ráadásul behozza azt a problémát is, hogy ez a deploy VM hogy éri el a template-et? Bele van csomagolva, vagy egy ISO-t mount-olok be? Elég körülményes lenne ezek frissítése.

Ne is menjünk ebbe az irányba.

Nem akarok nagyon beleszólni, inkább csak perspektívába helyezném a problémát. Ahol én dolgozom ott rendszeres feladat, hogy hogyan húzzanak fel egy nagy infrastruktúrát 0-ról. Gyakorlatilag mindig van egy dedikált "install server" betervezve, ami jó esetben a folyamat végén megszűnik és a vas bekerül a clusterbe normál ESXi-ként (rossz esetben meggondolatlanul ráterveznek valami feature-t, ami miatt maradnia kell). Persze nálunk nem opció, hogy az ESXi-kkel unsupported módon mókoljunk, mert az ügyfelek agyfrászt kapnának, ha a hivatalos VMware supportot veszélyeztetnénk.

Szóval nem egy ördögtől való irány ez sem.

A deployer VM hozzá tud férni a datastore-on tárolt file-okhoz pl a vifs CLI toolal: https://pubs.vmware.com/vsphere-6-5/index.jsp?topic=%2Fcom.vmware.vcli.examples.doc%2FGUID-FAFF4E3B-AB89-4ED0-A378-E7304904DF91.html

Ha egy ISO-ból megy az egész telepítés, akkor talán be is lehet csatolni az eredeti telepítő ISO-t (host drive-ot) a deployer VM-nek.

Nyilván mindkét esetben a vswitch-eket előbb kell konfigolni, de felteszem az első OVF deployolása előtt eddig is már kellett a működő hálózat.

De nem kell feltétlen megfogadni, ahány ház annyi szokás.
---
Régóta vágyok én, az androidok mezonkincsére már!

Jelen esetben nálunk kicsit más a helyzet, de osztom a nézetedet, nagy infrát én is deploy szerverről telepítenék, amennyire lehet, automatizáltan. Itt az a baj, hogy a világ eldugott részein is használható telepítőkészlet kell, ami offline működik, és egy betanított munkás is képes végrehajtani az initial setup-ot azon az egyetlen fizikai szerveren. Boldogabb ember lennék, ha központilag tudnám kezelni ezeket a telepítéseket is, de egyes ügyfél site-ok felé irtó karcsú a sávszélesség is (50kB/sec).

Megnézem a vCLI-t, amit említettél (köszönöm a tippet). Egyelőre úgy tűnik, a vifs csak put/get módon működik, így a deploy VM-nek először le kellene tölteni a template-et, hogy OVF Tool-lal aztán telepíthesse.

Köszönöm a segítséget. :)

Egy laptop direkt kábellel a szerverhez kötve nem lenne megoldás?

Powershell minden Windows-on van.

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Szerintem neki olyan szintű telepítés kell, mint hogy amikor egy olajfúró telephelyen ledobják a szervert akkor Hans, olajfúró mester egy DVD-t bebootolva kész rendszert kapjon. Ha jól emlékszem NORDIC-on is voltak ilyen-olyan eldugott helyeken rendszerek. Persze lehet tévedek, de azt sem értem, hogy miért nem pre-installált gépeket kapnak az ügyfelek.

Köszönöm az eddigi hozzászólásokat.

Most kanyarodjunk el kicsit attól, hogy hogyan lehet install során módosítani az OVF-et és/vagy a deploy-olt VM-eket. Ennek értelmezésére és áthidalására senkinek nincs ötlete?

error while loading shared libraries: libicudata.so.58: failed to map text segment from shared object: Error 28

ESXi 6.5u1-el nem próbáltad ki esetleg? ott is van ilyen hibaüzenet?

"VMware ESXi 6.5.0 build-8294253"

Ez 6.5U2-nek tűnik nekem

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Megnéztem, sajnos ugyanaz a jelenség:

[root@esxi01:/vmfs/volumes/5b19040d-0f6e70fe-3269-005056912853] esxcli system version get
Product: VMware ESXi
Version: 6.5.0
Build: Releasebuild-5969303
Update: 1
Patch: 26
[root@esxi01:/vmfs/volumes/5b19040d-0f6e70fe-3269-005056912853] sh ovftool.430/ovftool -v
ovftool.430/ovftool.bin: error while loading shared libraries: libicudata.so.58: failed to map text segment from shared object: Error 28

Tettem egy próbát 6.5 GA-val (build-4564106) is, nincs különbség, Error 28 itt is.

Be kell másolni neki arról az ESXi-ről, amivel megy, az összes shared libet + LD_LIBRARY_PATH.

Ezzel próbálkoztam, de nem hozott eredményt. Nehezítés, hogy ESXi-n nincs ldd parancs.

A problémás "libicudata.so.58" egy statikus bináris, mellékelik az OVF Tool-hoz. A függőségi lánc:
ovftool.bin -> libgoogleurl.so.59 -> libicuuc.so.58 -> libicudata.so.58

Van némi előrelépés, de nem biztató. A hibaüzenetet a /lib64/ld-linux-x86-64.so.2 írja ki, ami symlink a /lib64/ld-2.12.2.so-ra. Ami pech, hogy ezt nem relatív, hanem abszolút path-on hivatkozza be az ovftool.bin.

[root@esxi01:/vmfs/volumes/5b191c2e-238ada9b-9a31-005056912853/ovftool] sh ../ldd ovftool.bin
librt.so.1 => /lib64/librt.so.1 (0x000000332900c000)
libgoogleurl.so.59 => not found
libcurl.so.4 => /lib64/libcurl.so.4 (0x0000003329226000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x000000332948e000)
libcrypto.so.1.0.2 => /lib64/libcrypto.so.1.0.2 (0x0000003329791000)
libz.so.1 => /lib64/libz.so.1 (0x0000003329c57000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003329e6f000)
libxerces-c-3.1.so => not found
libvmacore.so => /lib64/libvmacore.so (0x000000332a073000)
libvmomi.so => /lib64/libvmomi.so (0x000000332a844000)
libvim-types.so => /lib64/libvim-types.so (0x000000332ad2a000)
libm.so.6 => /lib64/libm.so.6 (0x000000332cfb8000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000332d23b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000332d451000)
libc.so.6 => /lib64/libc.so.6 (0x000000332d66e000)
/lib64/ld-linux-x86-64.so.2 (0x00000032e8462000)
libssl.so.1.0.2 => /lib64/libssl.so.1.0.2 (0x000000332d9da000)
libexpat.so => /lib64/libexpat.so (0x000000332dc4e000)
libssoclient.so => /lib64/libssoclient.so (0x000000332de80000)

(tekintsünk el a "not found" soroktól, itt épp nincs beállítva az LD_LIBRARY_PATH)

ESXi 5.5 és 6.5 alatt 2.12-es glibc van, 6.7-en pedig 2.17.

Azt hiszem, ennek itt a vége. Binárist nem fogok módosítani, glibálisan nem cserélem le a glibc-t.

Az ld-linux.so, az a runtime linker (leánykori nevén ld.so).

Nem lecserélni kell a glibc-t, hanem a programod mellé egy privát példányt másolni belőle, amit csak ő használ. Kellhet a glibc verzióhoz tartozó ld.so is, ez igaz.

Az, hogy abszolút útvonallal van benne, nem jelent semmit, ugyanis a programodat indíthatod úgy, hogy xxxx, és akkor magától megtalálja az abszolút útvonalon a saját ld.so-ját, vagy indíthatod úgy, hogy ld.so xxxx, ez esetben az általad választott ld.so-val fog futni (az ld.so a program, amit beindítasz, és programod pedig egy paraméter, amit ő betölt).

Ezzel az ld.so ovftool.bin módszerrel futok ma egy kört, eddig nem ismertem. Köszönöm a javaslatot, hamarosan megírom, mire jutottam.

Sikerült összeszedni a library-ket, és már fut az ovftool, de csak egy hibaüzenet erejéig:
Error: Locale initialization failed.
Completed with errors

strace-cel addig jutottam, hogy a ./env/ könyvtár tartalmát nem tudja elérni, mely tartalmazza a lokalizációs állományokat.

Ami zavarba ejt, hogy az openat() függvényre kapok "Function not implemented" üzenetet, pedig ezt a libc-2.17.so biztosítja, és tuti a helyi könyvtába másolt példányt tölti be, ami a működő rendszerről származik. Végignézve az strace kimenetet, minden .so az ovftool könyvtárából kerül betöltésre.

Mellékhatásként kiderítettem, hogy az ESXi 6.7 alapértelmezetten VMFS-6-ra formázza a datastore-t, a 6.5U2 pedig még VMFS-5-re. De nem ez okozza az eltérő működést, 6.5U2 VMFS-6-tal sem működik, de ez várható is volt.

"Mellékhatásként kiderítettem, hogy az ESXi 6.7 alapértelmezetten VMFS-6-ra formázza a datastore-t, a 6.5U2 pedig még VMFS-5-re. De nem ez okozza az eltérő működést, 6.5U2 VMFS-6-tal sem működik, de ez várható is volt."

Ez furcsa, nekem a most telepített 6.5U2 szervereim mind VMFS6-al települtek (PXE boot-os kickstart egy FC-n csatolt NetApp LUN-ra).

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

strace-eld le a jó és a rossz környezetben, és hasonlítsd össze a kimeneteket.

Igen, pont ezt tettem.

ESXi 6.5U2, libc 2.17 a 6.7GA-ból:
getcwd("/vmfs/volumes/5b1a568c-eb59c4e0-ce77-005056912853/ovftool", 1024) = 58
openat(AT_FDCWD, "./env/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOSYS (Function not implemented)
gettimeofday({1528454019, 304554}, NULL) = 0
futex(0x47f8b708c8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x47f85a63b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(1, "Error: Locale initialization fai"..., 37Error: Locale initialization failed.
) = 37
write(1, "Completed with errors\n", 22Completed with errors
) = 22
exit_group(1) = ?

ESXi 6.7GA:
getcwd("/vmfs/volumes/5b1912d2-62d0fb0a-71d5-005056914e87/ovftool.430", 1024) = 62
openat(AT_FDCWD, "./env/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
getdents(4, /* 18 entries */, 32768) = 719
getdents(4, /* 0 entries */, 32768) = 0
close(4) = 0
getcwd("/vmfs/volumes/5b1912d2-62d0fb0a-71d5-005056914e87/ovftool.430", 1024) = 62
open("/vmfs/volumes/5b1912d2-62d0fb0a-71d5-005056914e87/ovftool.430/./env/iso2psx.vlcl", O_RDONLY) = 4
read(4, "signature = \"sIgNaTuRe\"\n\n# ISO l"..., 32768) = 3011

Egy példa C kód, ami openat()-et használ, szintén így viselkedik; "Function not implemented". A dokumentáció szerint libc 2.10 óta van openat függvény, és 2 vagy 3 paramétert fogad el.

Természetesen 6.5U2 alatt az eredeti libc 2.12.2-vel működik az openat(), csak az ovftool nem. :)

Ez szopó. Az újabb glibc-t újabb kernelhez fordították, ezért próbálja használni azt a rendszerhívást, ami a régi kernelből még hiányzik.
Egy LD_PRELOAD-dal mondjuk be lehetne rántani egy alternatív openat() glibc implementációt, ami fut a régi kernellel is...

https://lwn.net/Articles/164887/

A szép, hogy ez a rendszerhívás 2005-ben nőtt...

Köszönöm a tanácsokat és az eddigi segítséget. Itt fogyott el az időm és energiám, amit a probléma megoldására szántam. Nincs kizárva, hogy majd a nyári uborkaszezonban (ha lesz ilyen) előveszem még a témát.

Marad az OVF Tool 4.2.0 és a kézi hack 6.5U2-vel.