[ESXi 6.5] Ova op datstore krijgen

[battler]

De disks in mijn server waren te klein. Aangezien het in een raid 1 opstelling stond had ik het volgende in gedachte:

1) 1 disk vervangen voor een grotere
2) Synchroniseren
3) 1 disk vervnagen voor een grotere
4) Volume uitbreiden in raid controller
5) Volume uitbreiden in Esxi 5.5
6) Partities uitbreiden op de guests.

Zo makkelijk ging het allemaal niet want met de Dell Perc H200 kan je geen volumes uitbreiden. Uiteindelijk zat er niets anders op dan het volume volledig verwijderen en opnieuw aanmaken.

1) Exporteren van VMs
2) Nieuwe schijven erin
3) Nieuwe volume/raid set aanmaken
4) VMs importeren

Ook dit ging weer fout want halverwege had ik een corrupte ESXi. Op zich geen probleem ik dacht een goed moment om over te stappen naar ESXi 6.5. Nu de installatie is afgerond probeer ik de OVAs op de datastore te zetten of te importeren maar dit gaat tergend traag.

In de nieuwe esxi 6.5 is er alleen nog maar een webinterface. Een kans op crash/refresh etc. van die webpagina tijdens de import van een ova is vrij groot. Het lukt mij daarom al twee dagen niet om die Ova's uberhaupt op de datastore te krijgen. Het duurt gewoon ontzettend lang.

Er zijn drie VMs (Router 20GB, Management 26GB, Server 226GB).
Wat ik heb geprobeerd:
Via de webinterface gewoon weer importen (Duurt extreem lang ongeveeer 1MB/s per VM). Voor de Server OVA zou dit dus ongeveer 64 uur moeten duren. Ondertussen is de browser/website al twee keer gecrashed.
Een andere optie is via SCP direct op de datastore zetten en dan lokaal importeren. Ook deze snelheden zijn tergend traag Het begint met 1MB/s en zakt af naar de helft. Veeam FastSCP is niet compatible met Esxi 6.5 en ik weet niet in hoeverre dit sneller zou zijn (SCP = SCP denk ik?)
Ik een test gedaan met een 1GB random file en die via de webinterface geupload naar de datastore. 1GB deed er 7 minuten over, wat neerkomt op 2,35MB/s . Dezelfde test maar dan een upload via SCP komt uit op 2,5MB/s.

Wat voor andere opties heb ik nog?
Ik kan een disk van de raid set eruit halen, lokaal proberen aan te sluiten en te kopieren. Maar VMFS is niet op een gemakkelijke manier te lezen in Windows.
Dit moet toch gewoon via het netwerk kunnen, waarom duurt het dan zo lang

De source (laptop met OVAs) en destionation (Server met datastore) zitten aangelsoten op een Gigabit switch via Cat6A kabels (gekocht). Het is een huis tuin en keuken switch maar ik haal sowieso snelheden boven de 100Mb/s en dus ook zeker boven de 1MB/s. Source is een 512GB SSD, destination zijn twee HGST 7200 RPM schijven in Raid 1 op een Hperc 200 Raid controller. Het is een dramatische raid controller maar zo slecht CPU/Mem/netwerk en disk useage blijven allemaal extreem laag tijdens de file transfer. Ik heb geen VMware support dus ik kan de vraag niet aan ze stellen

bedankt!

UPDATE
Het leek me verstandig om uit te sluiten of het aan de schijven lag of aan esxi/netwerk. Een DD via SSH:

code:

[root@localhost:/vmfs/volumes/5885d42c-fc9ddaf8-7e27-d4ae52d1fb04] time dd if=/dev/zero of=/vmfs/volumes/datastore1/b
ar3.bin bs=100M count=1
1+0 records in
1+0 records out
real    0m 37.65s
user    0m 0.11s
sys     0m 0.00s

Wat neerkomt op 2.7MB/s Het ligt dus echt aan de schijven. Nu nog kijken waarom het zo traag is.

Ik heb de raidcontroller er tussenuit gehaald, vmware opnieuw geinstalleerd.

code:

[root@localhost:~] time dd if=/dev/zero of=/vmfs/volumes/datastore1/bar3.bin bs=100M count=1
1+0 records in
1+0 records out
real    0m 2.24s
user    0m 0.15s
sys     0m 0.00s

Ruim 15 keer sneller dus

[ Voor 16% gewijzigd door battler op 24-01-2017 12:10 ]

[Kavaa]

Je raid controller was wellicht nog de raidset aan het bouwen?

En je kunt met Winscp bestanden uploaden naar je ESX server als SSH aan staat
Dat zou dus de timeout van de webinterface moeten voorkomen.