Het grote thuis-virtualisatie topic

[FireDrunk]

Proxmox met Ceph. oVirt is erg groot en log, proxmox is veel kleiner, en Ceph is sneller

[CAPSLOCK2000]

Kijk eens naar Ganeti, dat is low-tech clustersoftware die weinig zelf doet en vooral vertrouwt op de bestaande Linux-kernel en tools. Het configureert (bijvoorbeeld) KVM en DRBD en zorgt voor hot-migration enzo.

In vergelijking met een tool als VMware is het maar een dwerg, maar wel heel makkelijk, toegankelijk en overzichtelijk.

[26779]

@tim427 Ik zou, zoals Firedrunk ook al aangeeft zeker voor ProxMox + Ceph gaan.... Daar ga je gewoon erg blij van worden..

[tim427]

FireDrunk schreef op woensdag 4 april 2018 @ 17:44:
oVirt is erg groot en log,

Naast eerder genoemde setup heb ik ook nog 2x R320's liggen voor eventuele oVirt Engine.

Dat oVirt wat groter en wat logger is, kan ik mee inkomen Maar dat is met deze setup niet echt een issue toch?

Betreft Ceph: ik zie overal dat de RAID functionaliteit uitgeschakeld dient te worden; IT-mode/ HBA-mode, RAID-0 met 1 disk is ook geen optie. Is dit echt een show-stopper?

[FireDrunk]

Nee, het is gewoon niet nodig. Ceph kan dat zelf regelen. Maar je kan prima Ceph op RAID draaien thuis. Niet super geschikt voor productie, maar het kan.

[Sandor_Clegane]

Volgens mij is dit de juiste plaats.

Ik gebruik een tweede GPU doorgelust in een Windows VM, deze GPU wordt door vfio-pci beheert en KVM zet deze netjes door.

Nu is deze GPU een redelijk snelle en aangezien ik sinds kort met Blender werk en Cycles kan renderen op de GPU vond ik het best zonde dat ik niets aan deze GPU heb als Linux is opgestart. Nu had ik Blender op mijn Windows VM geïnstalleerd en deze als slave aangemerkt zodat hij netwerk render jobs kan ontvangen, maar dit is niet helemaal zo elegant als ik zou willen.

Het mooiste zou zijn dat ik de GPU kan unbinden van vfio-pci en deze kan rebinden aan de nvidia drivers binnen Linux zelf en andersom.

Lo and behold: dat kan! Het is echt briljant.

Hoe werkt dat:

Linux start altijd op met de tweede GPU beheert door vfio-pci. Ik heb geprobeerd dit niet te doen en het on the fly te doen maar dit leidt tot problemen met X die van alles met de videokaart wil doen. Ik heb busnummers toegevoegd en de option ignore maar dit lijkt allemaal niet te werken.

Als je dan lcpci -nnk doet zie je dus:

code:

08:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1080] [10de:1b80] (rev a1)
        Subsystem: Gigabyte Technology Co., Ltd GP104 [GeForce GTX 1080] [1458:3717]
        Kernel driver in use: vfio-pci
        Kernel modules: nvidiafb, nouveau, nvidia_384_drm, nvidia_384
08:00.1 Audio device [0403]: NVIDIA Corporation GP104 High Definition Audio Controller [10de:10f0] (rev a1)
        Subsystem: Gigabyte Technology Co., Ltd GP104 High Definition Audio Controller [1458:3717]
        Kernel driver in use: vfio-pci
        Kernel modules: snd_hda_intel

nvidia-smi geeft:

code:

root@hepheastus:~# nvidia-smi 
Sun Apr 15 17:03:50 2018       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.130                Driver Version: 384.130                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 108...  Off  | 00000000:43:00.0  On |                  N/A |
| 34%   47C    P0    62W / 250W |   1337MiB / 11158MiB |      5%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      1348      G   /usr/lib/xorg/Xorg                           456MiB |
|    0      1738      G   kwin_x11                                      46MiB |
|    0      1741      G   /usr/bin/krunner                               2MiB |
|    0      1743      G   /usr/bin/plasmashell                         684MiB |
|    0      5069      G   ...-token=A4EDB8AD06A2280F6B630504857D21E3   117MiB |
|    0      7449      G   ...ngGlass/client/bin/looking-glass-client    26MiB |
+-----------------------------------------------------------------------------+

Nu kan KVM deze netjes aan de Windows VM geven en alles is ok met de wereld.
Probleem is nu dus wel dat hij voor Linux niet zichtbaar is.
Als ik nu de VM uitzet en dus de GPU in bijvoorbeeld Blender wil gebruiken moet je hem afmelden van vfio-pci en aanmelden bij de NVidia driver:

code:

#!/bin/sh
#vfio-pci.ids=10de:1b80,10de:10f0

stop()
{

    echo "Unbinding GPU from VFIO-PCI"
    echo -n 0000:08:00.0 > /sys/bus/pci/drivers/vfio-pci/unbind || echo "Failed to unbind gpu from vfio-pci"
    echo -n 0000:08:00.1 > /sys/bus/pci/drivers/vfio-pci/unbind || echo "Failed to unbind gpu-audio from vfio-pci"
    echo -n 10de 1b80 > /sys/bus/pci/drivers/vfio-pci/remove_id
    echo -n 10de 10f0 > /sys/bus/pci/drivers/vfio-pci/remove_id
    echo "Rescanning PCI bus"
    echo -n 1  > /sys/bus/pci/rescan
    echo "Unloading vfio-pci kernel module"
    modprobe -r vfio-pci
    echo -n 0000:08:00.0 > /sys/bus/pci/drivers/nvidia/bind || echo "Failed to bind nvidia gpu"
    echo -n 0000:08:00.1 > /sys/bus/pci/drivers/snd_hda_intel/bind || echo "Failed to bind nvidia hdmi audi"
}


start()
{
    echo "Binding GPU to VFIO-PCI"
    echo -n "0000:08:00.0" > /sys/bus/pci/drivers/nvidia/unbind || echo "Failed to unbind gpu from nvidia"
    echo -n "0000:08:00.1" > /sys/bus/pci/drivers/snd_hda_intel/unbind || echo "Failed to unbind hdmi audio in gpu"
    modprobe vfio-pci
    echo "Loaded vfio-pci kernel module"
    echo -n "10de 1b80" > /sys/bus/pci/drivers/vfio-pci/new_id
    echo -n "10de 10f0" > /sys/bus/pci/drivers/vfio-pci/new_id
}

echo  

case $1 in
    start|stop) "$1" ;;
esac

Door dit script te runnen wordt de GPU weer aan Linux teruggegeven en geeft nvidia-smi:

code:

root@hepheastus:~# nvidia-smi 
Sun Apr 15 17:09:07 2018       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.130                Driver Version: 384.130                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1080    Off  | 00000000:08:00.0 Off |                  N/A |
|  0%   38C    P5    24W / 200W |      0MiB /  8114MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 108...  Off  | 00000000:43:00.0  On |                  N/A |
| 40%   52C    P8    19W / 250W |   1280MiB / 11158MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    1      1348      G   /usr/lib/xorg/Xorg                           426MiB |
|    1      1738      G   kwin_x11                                      46MiB |
|    1      1741      G   /usr/bin/krunner                               2MiB |
|    1      1743      G   /usr/bin/plasmashell                         684MiB |
|    1      5069      G   ...-token=A4EDB8AD06A2280F6B630504857D21E3   117MiB |
+-----------------------------------------------------------------------------+

Alles werkte al naar behoren (lspci gaf alleen dat de juiste kernel drivers gebind waren) , alleen de PCI rescan bleek nodig te zijn om de Nvidia driver weer te laden/verversen.
Ik weet niet of dit gesneden koek is voor iedereen hier, maar ik vind het wel handig om beide GPUs binnen Linux te kunnen gebruiken. Misschien heeft iemand er wat aan.

Ik weet niet of het ook kan met een mix van AMD/Nvidia, maar twee Nvidia kaarten gaat prima.

[HashIT]

Dit is mijn huidige projectje, waarbij ik nog aan het zoeken ben naar de beste oplossingen.

Hypervisor

Ik ben nog op zoek naar de beste oplossing, maar overweeg KVM en/of LXC te gaan gebruiken. Hypervisor wordt dan een kale Ubuntu LTS of Debian, hoewel een andere distro ook nog een optie is.

Hardware

#	Product	Prijs	Subtotaal
1	Gigabyte GA-J3455N-D3H	€ 86,-	€ 86,-
1	Inter-Tech IPC SC-4100	€ 83,50	€ 83,50
1	Kingston HyperX Impact HX318LS11IBK2/16	€ 141,50	€ 141,50
Bekijk collectie Importeer producten		Totaal	€ 311,-

Op het moment heb ik er twee wat oudere 2TB WD schrijven in zitten. Achteraf gezien had ik even iets langer moeten zoeken naar een MiniITX bord met hardwarematige RAID of een PCI Express slot. Ik heb nu gekozen voor een redelijke hoeveelheid CPU power die passief gekoeld is en vast zit op het bord.

Virtuele machines

Ik ben nog aan het uitzoeken wat beter is, KVM of LXC. Mogelijk dat ik ze ga combineren. Ook de Linux distro's die ik wil gebruiken ben ik nog naar aan het kijken, maar waarschijnlijk wordt dat Ubuntu LTS of Debian.

OS/Appliance	Functie
Linux	Plex Media Server
Linux	Logitech Media Server
Linux	Fileserver (NFS en SMB/CIFS)
Linux	Unifi Controller

Motivatie

Hoe mooi alle standaard NAS oplossingen ook zijn, ik ben graag iets meer in controle en ik wil graag een overzichtelijk systeem. Het idee is om alle diensten te virtualiseren, inclusief de 'NAS' functies.

Op het moment heb ik twee identieke 2GB SATA schijven, met daarop een Linux software RAID 1 (MD), met daarin dan weer een LVM2 volume group.

[Sandor_Clegane]

HashIT schreef op woensdag 18 april 2018 @ 14:38:
snip

Ik zou van de HyperVisor ook de NAS maken, als je dan een VM wilt snapshotten doe je dat gewoon met het host OS. Lekker simpel.


Alles wat op Linux draait zou ik in een container gooien, misschien niet als je een speciale kernel nodig hebt. Daar zou ik een VM van bakken.

Heb zelf een TS440 staan met Ubuntu waar ZFS, LXC en KVM op draaien. Gitlab draait in een container en PFsense draait in een VM met een doorgeluste hardwarematige netwerkkaart.

[ocf81]

Ik heb een vraagje voor degenen die W10 in een VM draaien. Welke licentie hebben jullie? Gaat een OEM licentie werken?

[Sandor_Clegane]

ocf81 schreef op vrijdag 20 april 2018 @ 22:41:
Ik heb een vraagje voor degenen die W10 in een VM draaien. Welke licentie hebben jullie? Gaat een OEM licentie werken?

Volgens mij is een OEM licentie gekoppeld aan de hardware. Als je een VM draait op een machine waar deze licentie bij hoort zie ik geen probleem. Als thuis gebruiker die een OEM licentie op de kop tikt ergens, ook niet.

Volgens de EU is het helemaal niet mogelijk voor MS om dit af te dwingen: https://www.theregister.c...g_oem_windows_copies_you/

Is al wel uit 2002, zo YMMV.

[Anoniem: 444127]

Ik heb begrepen dat het bij het klonen van virtuele machines problemen kan geven omdat er dan iets verkeerd kan gaan aan de kant van MS.
Hoe zit dat technisch precies volgens de voorwaarden van die licentie? Windows in een virtuele machine en niet dual booten geeft natuurlijk geen probleem maar wat als je en dual boot en Windows in een virtuele machine draait met 1 licentie (OEM of retail, dat maakt in dit geval niets uit).

Missen jullie ook Neelie Kroes en haar voorganger als commissaris van de EU? Zij konden MS zo lekker aanpakken en ook Intel werd rond dezelfde tijd aangepakt (de boete van €1miljard staat nog open) , de huidige commissaris lijkt een pushover te zijn, je hoort er nooit meer iets over.

[ Voor 6% gewijzigd door Anoniem: 444127 op 26-04-2018 00:29 ]

[ThinkPad]

Vrije ruimte terugclaimen door 'hole punching' van VMDK

Met ESXi (en andere hypervisors wellicht ook?) heb je het issue dat wanneer een virtuele disk groeit en er weer ruimte vrijkomt, dit niet weer wordt teruggegeven aan je datastore. De VMDK van een VM blijft daardoor vrij groot waardoor in mijn geval de datastore (250GB SSD) redelijk vol liep. Vooral merkbaar nadat een VM updates heeft geïnstalleerd.

Hieronder wat stappen om weer ruimte te winnen op je datastore. Helaas is er wel downtime van de VM benodigd (10 - 15 min.):

• Inloggen op Linux VM daarna root worden (sudo su -)
• cat /dev/zero > /zero.fill;sync;sleep 1;sync;rm -f /zero.fill
  om de vrije ruimte op te vullen
• VM afsluiten

In ESXi 'hole punchen' in de VMDK:

• vmkfstools -K Router.vmdk (de normale VMDK, niet de -flat)
• VM unregisteren en opnieuw importeren

Datastore zou nu een stuk meer ruimte vrij moeten hebben doordat de VM een stuk minder ruimte inneemt. Voor een Windows VM kun je 'sdelete' gebruiken i.p.v. het Linux commando. Het ESXi stukje met vmkfstools zou zelfde moeten zijn.

Een drietal Ubuntu VM's gingen bij mij hiermee van 15-18GB naar zo'n 5-8GB.

[ Voor 7% gewijzigd door ThinkPad op 30-04-2018 13:08 ]

[FireDrunk]

Dit is dus best gevaarlijk op bijvoorbeeld een ZFS installatie, en kan sneller als je een andere blocksize gebruikt.

code:

dd if=/dev/zero of=/zero.fill bs=16M; sync; sleep 1; sync; rm -f /zero.fill

Verder goede tip

[squaddie]

ThinkPadd schreef op maandag 30 april 2018 @ 12:36:

Vrije ruimte terugclaimen door 'hole punching' van VMDK

Met ESXi (en andere hypervisors wellicht ook?) heb je het issue dat wanneer een virtuele disk groeit en er weer ruimte vrijkomt, dit niet weer wordt teruggegeven aan je datastore. De VMDK van een VM blijft daardoor vrij groot waardoor in mijn geval de datastore (250GB SSD) redelijk vol liep. Vooral merkbaar nadat een VM updates heeft geïnstalleerd.

Hieronder wat stappen om weer ruimte te winnen op je datastore. Helaas is er wel downtime van de VM benodigd (10 - 15 min.):

• Inloggen op Linux VM daarna root worden (sudo su -)
• cat /dev/zero > /zero.fill;sync;sleep 1;sync;rm -f /zero.fill
  om de vrije ruimte op te vullen
• VM afsluiten

In ESXi 'hole punchen' in de VMDK:

• vmkfstools -K Router.vmdk (de normale VMDK, niet de -flat)
• VM unregisteren en opnieuw importeren

Datastore zou nu een stuk meer ruimte vrij moeten hebben doordat de VM een stuk minder ruimte inneemt. Voor een Windows VM kun je 'sdelete' gebruiken i.p.v. het Linux commando. Het ESXi stukje met vmkfstools zou zelfde moeten zijn.

Een drietal Ubuntu VM's gingen bij mij hiermee van 15-18GB naar zo'n 5-8GB.

Ander risico als de datastore zeer vol zit is dat de virtuele disk eerst wordt opgeblazen tot maximum grootte en pas bij de tweede stap vrije ruimte gaat terugwinnen.

In principe zou deze workaround niet meer nodig hoeven zijn. Indien het OS Windows server 2012 R2 of hoger is is unmap ondersteunt vanaf esxi 6.0. In 6.5 is SPC-4 support toegevoegd hiermee kunnen Linux distributies die dit ondersteunen unmap commands sturen. Voor beide type besturingsystemen geld dat unmap alleen functioneert bij thin provisioned disks.

[Compizfox]

FireDrunk schreef op maandag 30 april 2018 @ 13:06:
Dit is dus best gevaarlijk op bijvoorbeeld een ZFS installatie, en kan sneller als je een andere blocksize gebruikt.

code:

dd if=/dev/zero of=/zero.fill bs=16M; sync; sleep 1; sync; rm -f /zero.fill

Verder goede tip

Waarom is dat gevaarlijk op ZFS-setups?

[vso]

squaddie schreef op maandag 30 april 2018 @ 22:06:
In principe zou deze workaround niet meer nodig hoeven zijn. Indien het OS Windows server 2012 R2 of hoger is is unmap ondersteunt vanaf esxi 6.0. In 6.5 is SPC-4 support toegevoegd hiermee kunnen Linux distributies die dit ondersteunen unmap commands sturen. Voor beide type besturingsystemen geld dat unmap alleen functioneert bij thin provisioned disks.

Unmap of Trim hangt heel erg af van het OS en de opties available, een paar key features zijn pas available als je disk gezien word als SCSI of SSD disk,

[...]
Ander risico als de datastore zeer vol zit is dat de virtuele disk eerst wordt opgeblazen tot maximum grootte en pas bij de tweede stap vrije ruimte gaat terugwinnen.

Dit is zoiezo een gevaar van overcommitment, alleen met juist onderhoud en opzet heb je hier echter niet veel last van.

leuk leesvoer
https://support.purestora...anagement_and_Reclamation
en
https://support.purestora...rations/Space_Reclamation

Overgens thin provisioning, heeft meer zin als je deduplication en bv zero detection (misschien een feature van intel Optane?) geactiveerd hebt. nu zal je bv op 250gb ssd niet veel winst hebben maar als elke kb winst is .. hmmm

[ Voor 8% gewijzigd door vso op 01-05-2018 00:02 ]

[FireDrunk]

Compizfox schreef op maandag 30 april 2018 @ 23:36:
[...]

Waarom is dat gevaarlijk op ZFS-setups?

Omdat je bij een ZFS setup, vanwege het copy on write mechanisme, na het het schrijven van de file, deze niet meer weg kan gooien. Bij 0 bytes free mag je geen files meer verwijderen..

[Compizfox]

FireDrunk schreef op dinsdag 1 mei 2018 @ 07:02:
[...]

Omdat je bij een ZFS setup, vanwege het copy on write mechanisme, na het het schrijven van de file, deze niet meer weg kan gooien. Bij 0 bytes free mag je geen files meer verwijderen..

Houdt ZFS om die reden geen "slop space" in acht?

[FireDrunk]

Nog niet gezien, misschien lig ik wat updates/upgrades achter. Laatste keer dat ik mijn Filesystem vol had, was nogal k*t

[Barryke]

Ik gebruikte thuis voorheen VMs en nu vooral Docker.
Het leek mij wel leuk om deze invalshoek aan deze lijst toe te voegen.


Wat gebruik ik thuis
Een server.. voor uitzoek-projectjes, storage, en de magie die in de achtergrond Plex laat werken als een vol-automatische prive Netflix. Ik had vroeger NASjes, maar storage+compute in 1 bak bevalt mij stukken beter (sneller en goedkoper).

Op welke hardware draai ik het

• Shuttle sx58h7 + Intel i7 920 cpu + 6GB ram
• 3x HDD 6TB (storage)
• SSD 512GB (storage cache)
• Unraid draait in RAM en boot van USB stick

Een kleine, stille, en energiezuinige ex-PC dus. ..maar doet alles met 2 vingers in neus. Zeker nu ik dockers gebruik.

Wat virtualiseer je eigenlijk
Ik heb dockers voor Plex, Sonarr, Radarr, Jackett, Deluge, Cardigann, Plexpy, Domoticz, Headphones, Musicbrainz, oscam, netwerk en device monitoring, en meer dockers van linuxserver.io. Ik draai ook dockers voor backup en file management, transcode en crunchjobs, voip en gameservers, maar die dockers staan niet standaard aan.

Waarom heb ik gekozen voor dit platform?
Ik heb mijn Windows server ooit vervangen door een Linux server met VM waarin Windows draaide, als overgang. Op die server draait Unraid als OS. Ook experimenteerde ik daarop met andere software in VMs.

Inmiddels heb ik alle VMs vervangen door dockers. Die zijn ook te starten/stoppen (commandline of webinterface) en ben er zeer tevreden over. Nog heb ik VMs klaarstaan om aan te zwengelen op die server maar hiervoor heb ik eigenlijk geen noodzaak meer voor.

De hardware blijkt ruim afdoende. Dat had ik niet verwacht, en de setup blijft mij verbazen. Of een proces iets in 0.010 ms of een halve seconde kan regelen maakt mij niet uit, als ik er toch pas 3 minuten of dagen later naar kijk.
Ik moet hard mijn best doen om deze setup over de zeik te krijgen, dat lukt me alleen met een onrealistische IO piek, en zelfs dat herstelt zichzelf weer in 10 seconden. De cache SSD van Unraid is hierin een grote factor. Daarnaast blijkt deze CPU nog steeds erg goed in transcoden, ook vergeleken met hedendaagse cpu modellen.

[Anoniem: 524929]

Ik zie hier KVM en LXD/LXC vaak voorbij komen voor servertjes. Mijn vraag is waarom niemand kijkt naar OpenVZ 7? Waarom alleen LXD voor thuisservers?

Op het gebied van efficientie en stabiliteit komt LXC niet eens in de buurt van OpenVZ. Afgelopen 2 weken heb ik met LXD gespeeld op een servertje met 18.04 en het komt niet in de buurt qua performance, stabiliteit en mogelijkheden.

LXC/LXD is leuk voor storage zoals Ceph, maar het is toch wel interessant om dit eens goed te bekijken. De KVM-optie in OpenVZ 7 werkt geweldig en bevat zelfs de virtuozzo guest agent. Maar voor Linux gebruik je de KVM-optie natuurlijk niet .

Met deze guide kun je alles opzetten en inrichten: Klik
ISO: Klik

Comparison:
https://openvz.org/Comparison

Daarnaast is Virtuozzo een veel veiligere optie dan LXC, mocht je de containers het internet op sturen d.m.v. van je homeserver. Iets met ervaring en kernel isolatie etc.

Mocht je hulp nodig hebben, dan hoor ik het natuurlijk graag

[ Voor 7% gewijzigd door Anoniem: 524929 op 05-05-2018 09:33 . Reden: Links ]

[Sandor_Clegane]

Omdat OpenVZ volgens mij altijd betaalde software was? Staat me zoiets van bij.

Dat is een beetje hetzelfde als dat Solaris Zones niet veel gebruikt wordt, dat is ook elegante software helemaal in combinatie met Crossbow.

[ Voor 47% gewijzigd door Sandor_Clegane op 05-05-2018 11:13 ]

[Anoniem: 524929]

Sandor_Clegane schreef op zaterdag 5 mei 2018 @ 11:11:
Omdat OpenVZ volgens mij altijd betaalde software was? Staat me zoiets van bij.

Dat is een beetje hetzelfde als dat Solaris Zones niet veel gebruikt wordt, dat is ook elegante software helemaal in combinatie met Crossbow.

OpenVZ is helemaal gratis (altijd al geweest), je hoeft nergens voor de betalen. Alle features kun je gebruiken en het werkt beter dan alle andere alternatieven. Zeker m.b.t. Linux systemen.

In Solaris en OVZ zitten grote verschillen. Maar ik wil OVZ hier benoemen, omdat ik vaak VMware voorbij zie komen voor Linux only systemen, terwijl OVZ minimaal 75% efficienter is. Dan nog het feit dat OVZ zeer stabiel is en meelift op Virtuozzo, de betaalde variant. Dus zeker interessant voor de Tweaker die een stabiele onderlaag wilt hebben met daarin een stukje software in een geïsoleerde container. In een container is het mogelijk om Ubuntu, CentOS, Fedora etc. te draaien.

[ Voor 3% gewijzigd door Anoniem: 524929 op 05-05-2018 13:05 ]

[wopie]

Ik ben het met je eens dat het vaak over VMWare gaat. OpenVZ ken ik persoonlijk niet, gezien de comparison-table die je geeft lijkt het mij persoonlijk minder interessant als bijv Proxmox (die ik zelf ook eerder als open-source/freeware concurrent voor ESXi zou zetten).

Zelf maak ik gebruik van SmartOS (een Solaris afgeleide) en daarbinnen van Zones en je hebt ook de mogelijkheid om KVM te gebruiken (men is daar nu bezig met het beschikbaar maken van BHyve, dit is de hypervisor die door FreeBSD is ontwikkeld maar nog erg jong is, de techniek is echter veelbelovend en het feit dat de mannen achter SmartOS dit aan het integreren zijn geeft ook aan dat deze de toekomst heeft voor SmartOS virtualisatie).

SmartOS biedt je naast solaris-zones ook LX-zones, dit zijn containers waarbij de Linux system-calls vertaald worden naar Solaris system-calls en hierdoor near-native speed halen, je kunt zo gewoon je Linux-applicaties in een LX-Zone draaien. Zoals Sandor_Clegane al aangaf heb je voor networking een ERG sterke networking-laag door middel van Crossbow, hiermee kan je prioriseren/scheiden/virtualiseren van netwerken wat je maar wilt.
Afgezien van je type virtualisatie werk je voor je storage in SmartOS met ZFS, hier is al genoeg over genoemd denk ik, maar wanneer je draaiende container/vm's wilt snapshotten/clonen/backuppen en meer van dit soort geavanceerde zaken dan maakt ZFS dit grotendeels out-of-the-box mogelijk.

SmartOS is ook gratis, gemaakt door Joyent die inmiddels zijn opgekocht door Samsung-Mobile, zij moeten Samsungs cloud-infra naar de toekomst tillen. Wanneer je geïnteresseerd bent in de techniek achter onder andere SmartOS kan ik je aanraden wat video's van Bryan Canthrill te gaan kijken (een van de masterminds achter SmartOS), hij kan erg vermakelijk vertellen en je krijgt een goed beeld van hoe zaken zijn ontstaan.

[Anoniem: 524929]

wopie schreef op zondag 6 mei 2018 @ 18:23:
Ik ben het met je eens dat het vaak over VMWare gaat. OpenVZ ken ik persoonlijk niet, gezien de comparison-table die je geeft lijkt het mij persoonlijk minder interessant als bijv Proxmox (die ik zelf ook eerder als open-source/freeware concurrent voor ESXi zou zetten).

Zelf maak ik gebruik van SmartOS (een Solaris afgeleide) en daarbinnen van Zones en je hebt ook de mogelijkheid om KVM te gebruiken (men is daar nu bezig met het beschikbaar maken van BHyve, dit is de hypervisor die door FreeBSD is ontwikkeld maar nog erg jong is, de techniek is echter veelbelovend en het feit dat de mannen achter SmartOS dit aan het integreren zijn geeft ook aan dat deze de toekomst heeft voor SmartOS virtualisatie).

SmartOS biedt je naast solaris-zones ook LX-zones, dit zijn containers waarbij de Linux system-calls vertaald worden naar Solaris system-calls en hierdoor near-native speed halen, je kunt zo gewoon je Linux-applicaties in een LX-Zone draaien. Zoals Sandor_Clegane al aangaf heb je voor networking een ERG sterke networking-laag door middel van Crossbow, hiermee kan je prioriseren/scheiden/virtualiseren van netwerken wat je maar wilt.
Afgezien van je type virtualisatie werk je voor je storage in SmartOS met ZFS, hier is al genoeg over genoemd denk ik, maar wanneer je draaiende container/vm's wilt snapshotten/clonen/backuppen en meer van dit soort geavanceerde zaken dan maakt ZFS dit grotendeels out-of-the-box mogelijk.

SmartOS is ook gratis, gemaakt door Joyent die inmiddels zijn opgekocht door Samsung-Mobile, zij moeten Samsungs cloud-infra naar de toekomst tillen. Wanneer je geïnteresseerd bent in de techniek achter onder andere SmartOS kan ik je aanraden wat video's van Bryan Canthrill te gaan kijken (een van de masterminds achter SmartOS), hij kan erg vermakelijk vertellen en je krijgt een goed beeld van hoe zaken zijn ontstaan.

Het is wel veel interessanter dan Proxmox, juist omdat zij gebruik maken van LXC en niet meer van OpenVZ. Daarom gebruik ik Proxmox zelf niet meer. Virtuozzo als organisatie is geen kleine jongen en hebben natuurlijk veel meer ervaring met isolatie en ontwikkelingen van Containers. Als je volledig gebruik wilt maken van alle Proxmox updates etc. moet je een abonnement aanschaffen en dat is bij OpenVZ niet het geval.

SmartOS ziet er ook leuk uit. Enig idee hoelang dit (supported) open-source blijft? Ik weet niet in hoeverre het echt vergelijkbaar is met LXC en OVZ qua OS-container isolatie etc.. Zal dit later eens bekijken. Als mensen overweg kunnen met LXC via de terminal, dan is OVZ helemaal makkelijk met de guide erbij.

[wopie]

Anoniem: 524929 schreef op zondag 6 mei 2018 @ 21:02:
[...]


Het is wel veel interessanter dan Proxmox, juist omdat zij gebruik maken van LXC en niet meer van OpenVZ. Daarom gebruik ik Proxmox zelf niet meer. Virtuozzo als organisatie is geen kleine jongen en hebben natuurlijk veel meer ervaring met isolatie en ontwikkelingen van Containers. Als je volledig gebruik wilt maken van alle Proxmox updates etc. moet je een abonnement aanschaffen en dat is bij OpenVZ niet het geval.

SmartOS ziet er ook leuk uit. Enig idee hoelang dit (supported) open-source blijft? Ik weet niet in hoeverre het echt vergelijkbaar is met LXC en OVZ qua OS-container isolatie etc.. Zal dit later eens bekijken. Als mensen overweg kunnen met LXC via de terminal, dan is OVZ helemaal makkelijk met de guide erbij.

Ik weet niet hoe lang het supported/open source blijft. Wat ik wel weet is dat het bedrijf dat erachter zit (Joyent) het zelf gebruikt voor hun cloud-platform en dat het open-sourcen van Solaris naar Illumos destijds hun dit alles heeft gebracht (de license van de code is op dit moment CDDL).

[unezra]

Anoniem: 524929 schreef op zondag 6 mei 2018 @ 21:02:
[...]
Het is wel veel interessanter dan Proxmox, juist omdat zij gebruik maken van LXC en niet meer van OpenVZ. Daarom gebruik ik Proxmox zelf niet meer.

Proxmox is al heel lang over geschakeld op LXC. :-)
(Ik dacht zelfs 1 of 2 jaar alweer.)

https://pve.proxmox.com/wiki/Linux_Container

Virtuozzo als organisatie is geen kleine jongen en hebben natuurlijk veel meer ervaring met isolatie en ontwikkelingen van Containers. Als je volledig gebruik wilt maken van alle Proxmox updates etc. moet je een abonnement aanschaffen en dat is bij OpenVZ niet het geval.

Is niet waar.
Het énige dat je niet krijgt zonder (betaalde) licentie is toegang tot de zng. stable repository. Dus de updates die je krijgt, zijn niet volledig door Q&A heen. Je krijgt ze wel. Kwestie van de repo aanpassen.

Zie hun wiki:
https://pve.proxmox.com/w...o_subscription_repository

Het enige dat je niet weg krijgt is het nagscreen. (Nja, kan wel, maar dat duurt maar 1 update.)

[Anoniem: 524929]

unezra schreef op maandag 7 mei 2018 @ 06:36:
[...]


Proxmox is al heel lang over geschakeld op LXC. :-)
(Ik dacht zelfs 1 of 2 jaar alweer.)

https://pve.proxmox.com/wiki/Linux_Container

1 of 2 jaar vind ik persoonlijk niet echt lang. Dan alsnog is het erg zonde, maar dat hebben zij wel begrepen van de gebruikers Ze hebben OVZ6 bij Proxmox uitgefaseerd na de OVZ7 release. Aangezien Virtuozzo nu een eigen OS gebruikt i.p.v. een kernel replacement in een linux distributie.

Is niet waar.
Het énige dat je niet krijgt zonder (betaalde) licentie is toegang tot de zng. stable repository. Dus de updates die je krijgt, zijn niet volledig door Q&A heen. Je krijgt ze wel. Kwestie van de repo aanpassen.

Zie hun wiki:
https://pve.proxmox.com/w...o_subscription_repository

Het enige dat je niet weg krijgt is het nagscreen. (Nja, kan wel, maar dat duurt maar 1 update.)

Heb dit ook een tijdje gebruikt, melding is idd makkelijk weg te krijgen. Het ligt eraan hoe stabiel de omgeving moet zijn Heb destijds wel een licentie gekocht, toen was het nog een stuk goedkoper en was het niet echt bug-free. + het feit dat Proxmox een leuk schilletje is, maar (helaas) onderwater gewoon LXC gebruikt.

[ Voor 12% gewijzigd door Anoniem: 524929 op 07-05-2018 06:53 ]

[unezra]

Anoniem: 524929 schreef op maandag 7 mei 2018 @ 06:47:
[...]
1 of 2 jaar vind ik persoonlijk niet echt lang.

Ik heb het even opgezocht:
https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.0

Released 05.10.2015

Dus ruim 2.5 jaar nu, wat ik persoonlijk best een lange tijd vind.

[...]
Heb dit ook een tijdje gebruikt, melding is idd makkelijk weg te krijgen. Het ligt eraan hoe stabiel de omgeving moet zijn Heb destijds wel een licentie gekocht, toen was het nog een stuk goedkoper en was het niet echt bug-free.

Geen enkele software is bug-free. Ook ESXi niet.
Bugs as-such zijn niet echt spannend, zolang je er maar niet al te veel last van hebt.

Ik gebruik PVE nu een jaar of 3, 4 denk ik en eigenlijk akelig tevreden over. Vind het veel flexibeler dan een ESXi en qua features gaat ESX daar alleen overheen als je fors in de buidel tast. (Sommige features heeft het helemaal niet. Logisch, gezien de andere markt maar dat zijn nu net de features die voor kleinere omgevingen nuttig zijn.)

Vind de prijs redelijk mee vallen, al zijn ze idd wat gestegen. Dacht dat het rond de €5,- per CPU per maand lag maar het is nu €6,24 per CPU per maand. (€74,90 per jaar) Kan ook zijn dat ik me daarin vergis.

Da's overigens voor community support en toegang tot de stable/enterprise repo, maar voor zo'n prijs per maand kun je logischerwijs geen volledige support verwachten. (Hoewel bizar genoeg ik bij een totaal ander stuk software wél volledige support kreeg voor een behoorlijk laag bedrag. Mixcraft, aangeschaft voor rond de €120 en dan krijg je veel meer dan alleen community support.)

[Anoniem: 524929]

unezra schreef op maandag 7 mei 2018 @ 07:07:
[...]


Ik heb het even opgezocht:
https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.0

Released 05.10.2015

Dus ruim 2.5 jaar nu, wat ik persoonlijk best een lange tijd vind.


[...]


Geen enkele software is bug-free. Ook ESXi niet.
Bugs as-such zijn niet echt spannend, zolang je er maar niet al te veel last van hebt.

Ik gebruik PVE nu een jaar of 3, 4 denk ik en eigenlijk akelig tevreden over. Vind het veel flexibeler dan een ESXi en qua features gaat ESX daar alleen overheen als je fors in de buidel tast. (Sommige features heeft het helemaal niet. Logisch, gezien de andere markt maar dat zijn nu net de features die voor kleinere omgevingen nuttig zijn.)

Vind de prijs redelijk mee vallen, al zijn ze idd wat gestegen. Dacht dat het rond de €5,- per CPU per maand lag maar het is nu €6,24 per CPU per maand. (€74,90 per jaar) Kan ook zijn dat ik me daarin vergis.

Da's overigens voor community support en toegang tot de stable/enterprise repo, maar voor zo'n prijs per maand kun je logischerwijs geen volledige support verwachten. (Hoewel bizar genoeg ik bij een totaal ander stuk software wél volledige support kreeg voor een behoorlijk laag bedrag. Mixcraft, aangeschaft voor rond de €120 en dan krijg je veel meer dan alleen community support.)

Het werkt zeer goed als managementtool, dat ben ik met je eens. Maar het blijft LXC..... En ik vind LXC helemaal niet productie-ready of krachtig genoeg om bijv. in een enterprise/productie-omgeving te gebruiken. Wel leuk om mee te hobbyen natuurlijk, maar het is zeker geen vervanger voor mijn OVZ installaties Niet efficiënt genoeg en nogal omslachtig om de config in te richten naar wens.

Ik snap in het algemeen ook niet waarom ze 'het wiel opnieuw uitvinden' met LXC, maar goed...

[ Voor 6% gewijzigd door Anoniem: 524929 op 07-05-2018 08:01 ]