VirtualBox: hoe hanteer je .vdi bestanden?

[aawe mwan]

Sinds kort ben ik op een oude Intel NUC aan het virtualiseren met VirtualBox onder Ubuntu. Misschien kunnen jullie me helpen aan wat „best practices” voor wat betreft de .vdi bestanden.

Grootte?
Ik dacht dat ik genoeg zou hebben aan 15GB voor OpenSuse en een applicatie, maar het bleek niet te passen. Toen het .vdi bestand ging groeien, was ook meteen de lokale storage op de NUC vol.
Natuurlijk kan je beter vooraf uitrekenen hoeveel ruimte je nodig hebt, maar wat is een handige manier van werken om toch flexibel te blijven?

Verplaatsen?
Je kunt een virtuele machine gemakkelijk draaien op verschillende systemen, maar hoe komt de hardware een beetje snel bij de .vdi bestanden? Ik zou het .vdi bestand op de NAS kunnen zetten, maar via een 100Mbps netwerk draait de virtuele machine dan niet echt snel, lijkt me (nog niet geprobeerd). Kopiëren naar de lokale SSD kan, maar die is dan zo vol, plus dat je elke keer -tig GB op die SSD schrijft en via een 100Mbps netwerk kost een 15GB bestand kopiëren een half uur.

Backups?
De virtuele machines die ik in elkaar getweakt heb, wil ik natuurlijk niet zomaar verliezen. Al start je de virtuele machine maar een keer op, dan verandert er een byte in het .vdi bestand en een traditionele backup zal dan de volle 15+ GB meenemen in de backup. Of je moet de backup regelen vanuit elke individuele virtuele machine zelf, maar dat lijkt me niet handig. Is er een andere oplossing?

[unezra]

Even los van de rest, maar VirtualBox is niet echt bedoeld voor servervirtualisatie wat jij doet. Het kan, het werkt en ik weet dat het zelfs in professionele toepassingen gedaan word. Het is er alleen niet echt voor bedoeld. Wellicht loont het dus sowieso om te kijken naar een platform dat wel meer bedoeld is voor server virtualisatie. (Op kantoor hebben we een tool genaamd CryptShare, tot mijn grote verrassing gebruikt dat VirtualBox. Waarvoor weet ik helaas niet.)

Grootte
15G lokale storage is heel erg weinig. Dat red je net met je OS en een enkele VM, maar dan moet je echt al serieus gaan letten op wat je installeert. Ik ga zelf uit van rond de 50G per VM voor wat basistaken en een OS, meer als ik er veel data op wil zeggen. (Bijvoorbeeld foto's of andere mediabestanden.) Op kantoor ga ik geloof ik uit van minimaal 100G per vm, thin provisioned. De vm zelf ziet dus 100G maar op disk zie je zo veel ruimte als er maximaal gebruikt is. Die bestanden groeien mee. (Ze krimpen alleen NIET als er minder data op staat.)

Centrale opslag
Je spullen centraal opslaan (op een NAS) is handig. 100MBit is alleen wel heel erg krap. Ik zou je netwerk upgraden naar GBit. Daar kom je een heel stuk verder mee. (1x GBit is in de regel prima om thuis wat zaken op een NAS te zetten waarbij de hypervisor op een andere machine staat. Kom je daaraan te kort, kun je altijd nog meerdere GBit verbindingen leggen.)

Backups
Kun je zo moeilijk en makkelijk regelen als je zelf wil. Ik doe het zelf op 1 machine met ZFS, waarbij juist enkel de gewijzigde bits worden verzonden naar een externe lokatie. Op die machine draaien images (ik werk met Proxmox), maar juist omdat enkel de gewijzigde bits worden overgezonden, vraagt dat niet veel bandbreedte. Qua tooling hebben we daarvoor SanOid ingezet. https://github.com/jimsalterjrs/sanoid

Thuis maak ik vooralsnog OOK gebruik van BackupPC, dat ik in de vm's zelf draai. BackupPC syncht ook op basis van delta's, dus alleen de gewijzigde data. (Het werkt in de regel met rsync, maar andere protocollen zijn ook mogelijk.) http://backuppc.sourceforge.net/

[CMD-Snake]

aawe mwan schreef op zaterdag 14 januari 2017 @ 14:47:
Verplaatsen?
Je kunt een virtuele machine gemakkelijk draaien op verschillende systemen, maar hoe komt de hardware een beetje snel bij de .vdi bestanden? Ik zou het .vdi bestand op de NAS kunnen zetten, maar via een 100Mbps netwerk draait de virtuele machine dan niet echt snel, lijkt me (nog niet geprobeerd). Kopiëren naar de lokale SSD kan, maar die is dan zo vol, plus dat je elke keer -tig GB op die SSD schrijft en via een 100Mbps netwerk kost een 15GB bestand kopiëren een half uur.

Ik heb zelf een externe SSD die ik verbind met een USB 3 aansluiting. Zo deel ik ook mijn VM's tussen mijn laptop en mijn desktop. Deze oplossing werkt voor mij lekker snel, als een VM draait hoeft alleen de aansturing te gebeuren over de USB verbinding, al het werkt gebeurt op de SSD.

Schijfruimte heb je aardig wat van nodig als je veel VM's draait. Ik heb een 1TB SSD, dan heb ik genoeg ruimte alhoewel dat ook nog vrij snel op gaat.

[Hero of Time]

15 GB zou ruim voldoende moeten zijn. Mijn fysieke installaties zijn niet eens zo groot. Als het te weinig is voor je, moet je eens gaan kijken wat er allemaal extra erop wordt gezet. Denk aan hele multimedia suites, libre office, etc wat je helemaal niet nodig hebt. Leert ook op de grootte van de swap partitie.

Voor de vraag zelf. Lokaal is het beste uiteraard, maar via het netwerk kan, mits deze snel genoeg is. 100 Mbps is dat niet. USB 3 is een goed alternatief.

[aawe mwan]

Ik was van plan om in de virtuele machines de /home directory via NFS te gaan koppelen naar een directory op de hostmachine, want dan:

• hoef ik voor data geen ruimte te reserveren in de .vdi
• kan de data meelopen met een centrale backup op de host (de .vdi's backup ik dan handmatig)
• staat de data gewoon op de lokale SSD, dus dit blijft snel

Dat laatste punt lijkt niet te kloppen; een NFS share is traag, nog niet eens Gigabit. Hieronder test ik achtereenvolgens schrijven naar de NFS share, naar een Virtualbox „Shared folder” en naar de .vdi:
 

code:

sudo mount 192.168.178.44:/home/VM /mnt/test -o rsize=8192,wsize=8192

dd if=/dev/zero of=/mnt/test/magweg bs=1M count=1024 conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 35.6584 s, 30.1 MB/s

dd if=/dev/zero of=/media/sf_suse1011/magweg bs=1M count=1024 conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.75002 s, 187 MB/s

dd if=/dev/zero of=~/magweg bs=1M count=1024 conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.3356 s, 804 MB/s

Ik zou eigenlijk betere prestaties binnendoor via NFS verwachten dan wat je hierboven ziet, of is dat niet realistisch? Rechtstreeks op de host haal ik 430 MB/s met dit dd commando.

[ Voor 4% gewijzigd door aawe mwan op 15-01-2017 11:30 ]

[Hero of Time]

Hoe snel wil je een document kunnen openen? Wat neemt nou de meeste tijd om te laden? Het documentje van een paar honderd KB, of de hele suite om het bestand te kunnen bewerken? Je /home van de Guest naar een locatie op je host te verwijzen voor snelheid is onnodig en je wint er geen klap mee. Belangrijke data deel je dan weer via NFS of Shared Folders zodat het op je host staat en daarmee niet kwijt bent in geval de VM corrupt raakt. Die paar gebruikersinstellingen is niet belangrijk. Op m'n fysieke machines doe ik wel een aparte /home, maar in een VM niet, juist om deze reden. Allemaal onbelangrijke data, die paar instellingen.

Waarom het zo 'traag' gaat met NFS moet je eens uitzoeken. Ga na wat het zou kunnen zijn. CPU beperking? Tuning van NFS export of mount opties? NFS Caching dat mogelijk in de weg zit?

[CAPSLOCK2000]

Het zou aan die rsize/wsize kunnen liggen, tegenwoordig wordt die meestal veel hogere gekozen, al verwacht ik niet dat dit zo veel impact heeft. NFS kan in principe probleemloos gbit vullen, daar heb je geen snelle hardware voor nodig.

Als je veel RAM hebt dan is een langzaam netwerk helemaal niet zo erg. De meeste systemen hoeven namelijk helemaal niet zo vaak iets naar hun OS-disk te schrijven. Als je data-intensieve applicaties hebt dan wordt dan zal het toch over het netwerk heen moeten.

Maar eh, heb je echt nog 100mbit netwerk of is het toch gigabit? Als je echt nog met 100mbit werkt dan gebruik je waarschijnlijk ook nog een hub en dan gaat je performance al snel onderuit als het een beetje druk wordt.

[Hero of Time]

TS heeft wel gbit netwerk, anders kom je niet op 30 MB/s, maar zou je blijven hangen op 10-12 MB/s.

[aawe mwan]

Hero of Time schreef op maandag 16 januari 2017 @ 19:53:
TS heeft wel gbit netwerk, anders kom je niet op 30 MB/s, maar zou je blijven hangen op 10-12 MB/s.

Wat ik misschien niet duidelijk genoeg opgeschreven had, was dat de genoemde bottleneck niet in het fysieke netwerk zat, maar in het virtuele netwerk tussen de host en de client.

De oplossing van dit probleem bleek simpel te zijn: ik had voor de virtuele machine uit de beschikbare opties een mooie gigabit netwerkadapter gekozen, maar als je dat doet dan wordt deze hardware geëmuleerd. In plaats daarvan is de juiste keuze "Paravirtualized Network (virtio-net)" en door dit aan te passen is netwerkverkeer tussen de client en de host naar ongeveer 110MB/s gegaan.