On Thu, Jan 8, 2015 at 7:18 AM, Robert Sebastian Gerus ar@bash.org.pl wrote:
Kolejny pomysł sezonu, którego nikt normalny nie powinien używać.
1) Go. Serio. Nie ufam implementacji kompilatora, a mam zaufać hypervisorowi? 2) Używa KVM. Po co mi taki hypervisor, skoro Linux to umie? 3) Virtfs istnieje, też daje filesystem-based provisioning, kolesie się spóźnili tylko o 2 lata. 4) Nowe, nieprzetestowane, nieprodukcyjne, niskiej wydajności.
Pozdrawiam,
Do listy dodam jeszcze: 5) Własne urządzenia wirtualne = pisz nowe drivery wszędzie. Gorsza kupa niż VMWare ESX. 6) Nie umie niczego poza Linuxem. 7) Napisane w zasadzie przez jedną osobę.
Pozdrawiam, R.
2015-01-08 10:57 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
- Własne urządzenia wirtualne = pisz nowe drivery wszędzie. Gorsza
kupa niż VMWare ESX.
Jakie własne? VirtIO
- Nie umie niczego poza Linuxem.
Jak tak patrzę i tak jak autor zauważył, dodanie wsparcia multiboot powinno być trywialne.
2015-01-08 12:06 GMT+01:00 Robert Sebastian Gerus ar@bash.org.pl:
2015-01-08 10:57 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
- Własne urządzenia wirtualne = pisz nowe drivery wszędzie. Gorsza
kupa niż VMWare ESX.
Jakie własne? VirtIO
VirtIO nie ma nadal driverów do sporej gamy urządzeń. (M.in. wirtualizowanego USB, Audio, etc. Gdzie Xen coś ma, a QEMU też ma własne wolne.) Innymi słowy z automatu można uznać, że ten hypervisor nie działa dla szerokiego zakresu zastosowań.
Do tego jest wolne w porównaniu do mechanizmu z Xen PVH czy PVHVM[1]. VirtIO daje context switch między VM w przypadku wywołania "przerwania" tego urządzenia.
[1] http://wiki.xen.org/wiki/Virtualization_Spectrum
Dude, ale to nie jest (teraz) hypervisor do szerokiego zakresu zastosowań, tylko do stawiania lekkich wirtualek pod aplikacje.
On Thu Jan 08 2015 at 11:14:25 AM Radoslaw Szkodzinski < astralstorm@gmail.com> wrote:
2015-01-08 12:06 GMT+01:00 Robert Sebastian Gerus ar@bash.org.pl:
2015-01-08 10:57 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
- Własne urządzenia wirtualne = pisz nowe drivery wszędzie. Gorsza
kupa niż VMWare ESX.
Jakie własne? VirtIO
VirtIO nie ma nadal driverów do sporej gamy urządzeń. (M.in. wirtualizowanego USB, Audio, etc. Gdzie Xen coś ma, a QEMU też ma własne wolne.) Innymi słowy z automatu można uznać, że ten hypervisor nie działa dla szerokiego zakresu zastosowań.
Do tego jest wolne w porównaniu do mechanizmu z Xen PVH czy PVHVM[1]. VirtIO daje context switch między VM w przypadku wywołania "przerwania" tego urządzenia.
[1] http://wiki.xen.org/wiki/Virtualization_Spectrum
-- Radosław Szkodziński
General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
2015-01-08 12:16 GMT+01:00 Tomasz Dubrownik t.dubrownik@gmail.com:
Dude, ale to nie jest (teraz) hypervisor do szerokiego zakresu zastosowań, tylko do stawiania lekkich wirtualek pod aplikacje.
(I ty toppostujesz przeciwko mnie?!)
"Lekkich", ha. VirtIO nie jest lekkie, jest projektowane pod emulację całych urządzeń. To jest po prostu bardzo okrojone QEMU-KVM - w zasadzie Xen stubdom jest dużo, dużo lepszy od proponowanego rozwiązania.
Wydaje mi się, że projekt ma być po prostu "fajny", bo jest w Go.
Jeszcze dodam, że nie wspierają legacy BIOSu i pewnie usług EFI też, zatem system musi mieć specjalnie napisany driver PV. Którego w VirtIO nie ma (bo nie istnieje) - nie ma VirtIO APICu ani kontrolera przerwań.
Dude, to jest *pod aplikacje* - to nie jest maszyna wirtualna, która służy do udawania prawdziwej maszyny, tylko basically jail na poziomie wirtualizacji. Po co aplikacjom BIOS?
On Thu Jan 08 2015 at 11:17:51 AM Radoslaw Szkodzinski < astralstorm@gmail.com> wrote:
Jeszcze dodam, że nie wspierają legacy BIOSu i pewnie usług EFI też, zatem system musi mieć specjalnie napisany driver PV. Którego w VirtIO nie ma (bo nie istnieje) - nie ma VirtIO APICu ani kontrolera przerwań.
-- Radosław Szkodziński
General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
On Thu, Jan 8, 2015 at 12:22 PM, spin@hackerspace.pl wrote:
On 2015-01-08 12:19, Tomasz Dubrownik wrote:
Dude, to jest *pod aplikacje*
Me gusta takie rozwiązania.
Portability is king (vide: kmail1 vs kmail2. U still mad Rysiu?)
Tak, jak przeportujesz aplikację na ten hypervisor, a jednocześnie przeportujesz ten hypervisor tak, aby działał pod innym hypervisorem. Kmail3 anyone?
2015-01-08 12:22 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
On Thu, Jan 8, 2015 at 12:22 PM, spin@hackerspace.pl wrote:
On 2015-01-08 12:19, Tomasz Dubrownik wrote:
Dude, to jest *pod aplikacje*
Me gusta takie rozwiązania.
Portability is king (vide: kmail1 vs kmail2. U still mad Rysiu?)
Tak, jak przeportujesz aplikację na ten hypervisor, a jednocześnie przeportujesz ten hypervisor tak, aby działał pod innym hypervisorem. Kmail3 anyone?
Dude, ale jakie portowanie? Linux na tym działa. Twoje aplikacje działają na linuxie. Where's the problem?
2015-01-08 12:30 GMT+01:00 Robert Sebastian Gerus ar@bash.org.pl:
2015-01-08 12:22 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
On Thu, Jan 8, 2015 at 12:22 PM, spin@hackerspace.pl wrote:
On 2015-01-08 12:19, Tomasz Dubrownik wrote:
Dude, to jest *pod aplikacje*
Me gusta takie rozwiązania.
Portability is king (vide: kmail1 vs kmail2. U still mad Rysiu?)
Tak, jak przeportujesz aplikację na ten hypervisor, a jednocześnie przeportujesz ten hypervisor tak, aby działał pod innym hypervisorem. Kmail3 anyone?
Dude, ale jakie portowanie? Linux na tym działa. Twoje aplikacje działają na linuxie. Where's the problem?
Miało być lekkie. VirtIO i Linux nie spełniają definicji lekkiego. Albo lekkie, albo kurde parawirtualizowany (wolno) Linux.
2015-01-08 12:41 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
Miało być lekkie. VirtIO i Linux nie spełniają definicji lekkiego. Albo lekkie, albo kurde parawirtualizowany (wolno) Linux.
Chcesz powiedzieć, że pełna wirtualizacja, z emulowaniem tony gunwa które nawet w fizycznym sprzęcie jest od 20 lat udawane, jest szybsza? xD
On Thu Jan 08 2015 at 11:42:22 AM Radoslaw Szkodzinski < astralstorm@gmail.com> wrote:
2015-01-08 12:30 GMT+01:00 Robert Sebastian Gerus ar@bash.org.pl:
2015-01-08 12:22 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
On Thu, Jan 8, 2015 at 12:22 PM, spin@hackerspace.pl wrote:
On 2015-01-08 12:19, Tomasz Dubrownik wrote:
Dude, to jest *pod aplikacje*
Me gusta takie rozwiązania.
Portability is king (vide: kmail1 vs kmail2. U still mad Rysiu?)
Tak, jak przeportujesz aplikację na ten hypervisor, a jednocześnie przeportujesz ten hypervisor tak, aby działał pod innym hypervisorem. Kmail3 anyone?
Dude, ale jakie portowanie? Linux na tym działa. Twoje aplikacje działają na linuxie. Where's the problem?
Miało być lekkie. VirtIO i Linux nie spełniają definicji lekkiego. Albo lekkie, albo kurde parawirtualizowany (wolno) Linux.
Nie wiem czy znasz pojęcie kompromisu :>
Chcesz użyć wirtualizacji, żeby mieć maksymalnie bulletproof isolation, w miarę możliwości. Nie chcesz się bawić w udawanie nie wiadomo jakich device'ów.
Masz do wyboru albo przekonać przemysł, żeby pisać na jakiś nowy, lekki OS, albo użyć Linuxa i najmniej bullshitowego transportu do środka tego Linuxa, czyli last I checked chyba jednak virtio.
Dla mnie brzmi reasonable i nie łoiłbym po tym zbyt wiele z punktu widzenia ideologii przed faktycznymi testami. Może faktycznie działa jak gnój, wtedy oh well. A może nie?
2015-01-08 12:46 GMT+01:00 Tomasz Dubrownik t.dubrownik@gmail.com:
On Thu Jan 08 2015 at 11:42:22 AM Radoslaw Szkodzinski astralstorm@gmail.com wrote:
2015-01-08 12:30 GMT+01:00 Robert Sebastian Gerus ar@bash.org.pl:
2015-01-08 12:22 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
On Thu, Jan 8, 2015 at 12:22 PM, spin@hackerspace.pl wrote:
On 2015-01-08 12:19, Tomasz Dubrownik wrote:
Dude, to jest *pod aplikacje*
Me gusta takie rozwiązania.
Portability is king (vide: kmail1 vs kmail2. U still mad Rysiu?)
Tak, jak przeportujesz aplikację na ten hypervisor, a jednocześnie przeportujesz ten hypervisor tak, aby działał pod innym hypervisorem. Kmail3 anyone?
Dude, ale jakie portowanie? Linux na tym działa. Twoje aplikacje działają na linuxie. Where's the problem?
Miało być lekkie. VirtIO i Linux nie spełniają definicji lekkiego. Albo lekkie, albo kurde parawirtualizowany (wolno) Linux.
Nie wiem czy znasz pojęcie kompromisu :>
Ale po co mi zgniły kompromis, skoro jest Xen?
Chcesz użyć wirtualizacji, żeby mieć maksymalnie bulletproof isolation, w miarę możliwości. Nie chcesz się bawić w udawanie nie wiadomo jakich device'ów.
Czyli bierzesz Xen stubdom bez takich urządzeń, tryb paravirt. Ba, nawet możesz dać te VirtIO jeśli bardzo lubisz (choć jest gorsze) - Xen umie.
Pisanie nowego hypervisora po to, aby było bardziej "maintainable"... a do tego napisać go w języku, którego większość programistów nie umie. Genialne.
Masz do wyboru albo przekonać przemysł, żeby pisać na jakiś nowy, lekki OS, albo użyć Linuxa i najmniej bullshitowego transportu do środka tego Linuxa, czyli last I checked chyba jednak virtio.
Bo innego nie ma. (Xen event channel jest tylko dla Xen - choć w teorii inny hypervisor może umieć hypercalle Xen.) Poza tym, po co Linux, skoro to ma być dla aplikacji? Nie lepiej napisać aplikacje wprost pod hypervisor, a'la Xen stubdom lub VMWare ESX, lub podobne?
Nie widzę żadnego powodu, dla którego miałoby to być lepsze od QEMU-KVM, a tym bardziej od Xen.
Dla mnie brzmi reasonable i nie łoiłbym po tym zbyt wiele z punktu widzenia ideologii przed faktycznymi testami. Może faktycznie działa jak gnój, wtedy oh well. A może nie?
Autorzy piszą, że jest powolne. Pewnie jest to prawda. Na pewno nie jest szybsze niż QEMU-KVM z urządzeniami blokowymi VirtIO, gdyż leci po tym samym VirtIO.
Może część od dysku jest nieco szybsza od VirtFS, który leci po protokole 9P przez VirtIO. Może. Choć ostatnio mocno przyspieszyli VirtFS.
Tako rzecze Radoslaw Szkodzinski (2015-01-08, 13:04):
Może faktycznie działa jak gnój, wtedy oh well. A może nie?
Autorzy piszą, że jest powolne. Pewnie jest to prawda. Na pewno nie jest szybsze niż QEMU-KVM z urządzeniami blokowymi VirtIO, gdyż leci po tym samym VirtIO.
Autorzy piszą, że jest „measurable performance hit”, którego jednak możesz nie zauważyć przy przeciętnych workloadach.
2015-01-08 13:10 GMT+01:00 antoszka antoni@hackerspace.pl:
Tako rzecze Radoslaw Szkodzinski (2015-01-08, 13:04):
Może faktycznie działa jak gnój, wtedy oh well. A może nie?
Autorzy piszą, że jest powolne. Pewnie jest to prawda. Na pewno nie jest szybsze niż QEMU-KVM z urządzeniami blokowymi VirtIO, gdyż leci po tym samym VirtIO.
Autorzy piszą, że jest „measurable performance hit”, którego jednak możesz nie zauważyć przy przeciętnych workloadach.
Jeśli nie używasz ostro dysku w aplikacji, pewnie tak. Tylko po co wtedy wirtualny FS, skoro jeden obraz wystarczy? Dla wygody "administratora"?
Ba, do sieci używa to TUN/TAP. Odpala na sztywno dnsmasq. Ma jakąś własną jsonową "bazę" o VM - nie jest stateless.
Nie dotykałbym tej kupy kijem. QEMU-KVM wycofało się z tych rozwiązań trochę czasu temu z dobrego powodu.
R.
2015-01-08 13:04 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
Poza tym, po co Linux, skoro to ma być dla aplikacji? Nie lepiej napisać aplikacje wprost pod hypervisor, a'la Xen stubdom lub VMWare ESX, lub podobne?
Bo łatwiej użyć istniejących aplikacji niż pisać nowe?
2015-01-08 13:13 GMT+01:00 Robert Sebastian Gerus ar@bash.org.pl:
2015-01-08 13:04 GMT+01:00 Radoslaw Szkodzinski astralstorm@gmail.com:
Poza tym, po co Linux, skoro to ma być dla aplikacji? Nie lepiej napisać aplikacje wprost pod hypervisor, a'la Xen stubdom lub VMWare ESX, lub podobne?
Bo łatwiej użyć istniejących aplikacji niż pisać nowe?
Bo łatwiej użyć istniejącego QEMU-KVM niż pisać nowe, biedne odpowiedniki?
A teraz klu problemu tego "hypervisora": https://github.com/google/novm/graphs/contributors
To nie jest aktywnie rozwijane od pół roku, a na 100% nie jest gotowe.
R.
Ja mam propozycję żeby przy takich wątkach gdzie kłócimy się o to która kaczuszka jest prawdziwym gejem bo ma jedną nóżkę bardziejszą, starać się raczej skracać ilość maili produkowanych na liście niż nie skracać.
W sensie, wiecie, 'ustawiam sobie limit 2 wiadomości dziennie, wordlimit 3000 słów'. Akurat po jednym: do gorącej kawy z termosa w zapchanym metrze, i do samkowitego obiadku z sieci restauracyjnej Kopytka-Farfocle i Czerwie.
Lista skorzysta, i kaczuszki też pokorzystają sobie.
Bo teraz tak jak jest to mocno adhd pachnie.
2015-01-08 11:05 GMT+01:00 antoszka antoni@hackerspace.pl:
Tako rzecze Radoslaw Szkodzinski (2015-01-08, 10:52):
- Nowe, nieprzetestowane, nieprodukcyjne, niskiej wydajności.
A skąd wiesz, jakiej jest wydajności?
Sami napisali, że niskiej. :D
-
antoszka -
Radoslaw Szkodzinski -
Robert Sebastian Gerus -
spin＠hackerspace.pl -
Tomasz Dubrownik