abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 16:11 | Komunita

Byly zveřejněny videozáznamy přednášek a workshopů z letošní konference OpenAlt konané 4. a 5. listopadu v Brně. K videozáznamům lze přistupovat ze stránky na SuperLectures nebo přes program konference, detaily o vybrané přednášce nebo workshopu a dále kliknutím na ikonku filmového pásu.

Ladislav Hagara | Komentářů: 0
včera 14:11 | Komunita

Některým uživatelům Firefoxu se tento týden do Firefoxu nainstalovalo neznámé rozšíření Looking Glass 1.0.3 (png). Ve fórů Mozilly se řešilo, zda se nejedná o malware. Mozilla později informovala, že se jednalo o reklamu na seriál Mr. Robot. Řadě uživatelů Firefoxu se jednání Mozilly vůbec nelíbilo. Mozilla proto automatickou instalaci doplňku ukončila [Hacker News, reddit].

Ladislav Hagara | Komentářů: 15
16.12. 12:00 | Nová verze

Po cca 3 týdnech od vydání Linux Mintu 18.3 s kódovým jménem Sylvia a prostředími MATE a Cinnamon byla oznámena také vydání s prostředími KDE a Xfce. Podrobnosti v poznámkách k vydání (KDE, Xfce) a v přehledech novinek s náhledy (KDE, Xfce). Linux Mint 18.3 je podporován do roku 2021.

Ladislav Hagara | Komentářů: 6
15.12. 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 54
15.12. 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
15.12. 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 10
15.12. 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
14.12. 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 10
14.12. 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
14.12. 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (0%)
 (1%)
 (1%)
 (76%)
 (14%)
Celkem 1012 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3

    3.1.2015 14:30 | Přečteno: 1565× | Linux | Výběrový blog | poslední úprava: 1.1.2015 14:34

    Po po předvčerejším a včerejším díle následuje zakončení: Systemd a řízení zdrojů – KVM hosté a systemd-user – Squid proxy pro Pacmana – Transmission.

    Maboroshi v3

    Když nejde mít reálně grafiku v systému virtualizovaném, tak nezbývá než ji mít v systému virtualizujícím. Server od desktopu tak sice nebude tak čistě oddělen, ale co už…

    KDE, systemd, cgroups a řízení zdrojů

    No, a když už se dává desktop na takové nadupané železo, tak tam dáme v rámci sjednocení domácího prostředí rovnou KDEčka. Aby ale desktop příliš neomezoval virtualizovaný server, chtělo by to ho nějak omezit, ale jak? Máme přece ten systemd… Jeden jim všem vládne… pomocí cgroups.

    O tom, jak to udělat, se rozepisuje sám ten, jehož jméno se nevyslovuje. Všechny procesy jednoho uživatele jsou zařazovány do jedné skupiny, z hlediska systemd jsou pak reprezentovány jako user-UID.slice. Tomu pak lze přiřadit limit využití paměti, nebo něčeho jiného:

    # z ruky
    systemctl set-property user-1000.slice MemoryLimit=2G
    
    # nebo konfigurákem
    #/etc/systemd/system/user-1000.slice.d/50-MemoryLimit.conf
    [Slice]
    MemoryLimit=2147483648
    				

    Za předpokladu, že na systému nebude naráz pracovat více uživatelů, což nebude, by to mělo rozumně fungovat. Jak to zrovna se zdroji vypadá, ukáže nástroj systemd-cgtop.

    KVM hosté a systemd-user

    Aby bylo funkci tohoto zápisku coby externí paměti učiněno zadost přidávám ještě službu, která spustí server Makoto:

    #/home/qemu-makoto/.config/systemd/user/qemu-makoto.service 
    [Unit]
    Description=QEMU virtual makoto
    
    [Service]
    ExecStart=/usr/bin/env qemu-system-x86_64 -name makoto \
            -enable-kvm -m 4096 -cpu host -smp 2 -nographic \
            -device virtio-net-pci,netdev=net2,mac=52:54:00:12:34:01 \
            -netdev type=tap,id=net2,ifname=tap0,script=no,downscript=no \
            -drive file=/dev/maboroshi_ssd_lvm/makoto,index=0,media=disk,if=virtio \
            -drive file=/dev/sda,index=1,media=disk,if=virtio \
            -virtfs local,id=p9fs1,path=%h/boot,security_model=mapped,mount_tag=makoto_9p_boot \
            -monitor unix:%h/kvm-makoto.sock,server,nowait \
            -kernel "%h/boot/vmlinuz-linux" -initrd "%h/boot/initramfs-linux.img" \
            -append "root=/dev/disk/by-label/makoto_ssd_btrfs rootflags=subvol=makoto_root rw quiet systemd.unit=multi-user.target" 
    ExecStop=/usr/bin/bash -c "/usr/bin/echo 'system_powerdown' | /usr/bin/nc -U %h/kvm-makoto.sock"
    TimeoutStopSec=30
    KillMode=none
    
    [Install]
    WantedBy=default.target
            #-drive media=cdrom,file=%h/archlinux-2014.09.03-dual.iso,readonly,index=1 \
    				

    A dodávám hlasitou mentální poznámku: Pozor na zakomentované řádky končící zpětným lomítkem! Mrcha se nepochopitelně interpretovala a v pozici před ExecStop způsobila, že se toto „záhadně“ nevykonávalo.

    Makoto

    Současná podoba Makoto je pouze holý systém a zmigrované dosud používané služby. Oproti původnímu záměru jsem CUPS hodil na Maboroshi, protože závislosti na X11. Na zatím nedůležitá data jsem zneužil kupodivu stále fungující SATA disk z prvního stolního počítače z roku 2004.

    Squid proxy pro Pacmana

    Toto jsem objevil, když jsem řešil zdlouhavou aktualizaci několika stejných Arších strojů na pomalé ADSL, pak jsem to nasadil i doma, i když tam je ADSL rychlejší. Popis na Arch Wiki, zde jen stručně:

    pacman -S squid
    
    # /etc/fstab
    LABEL=makoto_hdd_btrfs  /mnt/proxy    btrfs     rw,noatime,space_cache,subvol=makoto_proxy      0 0
    
    # /etc/systemd/system/squid.service.d/customization.conf 
    [Unit]
    RequiresMountsFor=/mnt/proxy
    
    # /etc/squid/squid.conf
    maximum_object_size 512 MB
    cache_dir aufs /mnt/proxy 4096 16 256
    shutdown_lifetime 1 seconds 
    
    refresh_pattern \.pkg\.tar\.   0       20%     4320      reload-into-ims
    refresh_pattern .              0       0%      0
    					

    Na straně klientů jsem pak nastavil aliasy:

    # ~/.bashrc
    alias yaourt="http_proxy='http://makoto:3128' yaourt"
    alias pacman="http_proxy='http://makoto:3128' pacman"
    					

    A pro funkčnost pro uživatele využívajícího sudo:

    # /etc/sudoers
    Defaults env_keep += "http_proxy"
    					
    Transmission

    I toto je rozumně popsané na Arch Wiki. Oproti ad-hoc slepenci na Kanashimi jsem zvolil provoz pod uživatelem transmissionkonfigurace je pak ve /var/lib/transmission/, opět jen stručně:

    # .config/transmission-daemon/settings.json
        "download-dir": "/mnt/torrent", 
        "incomplete-dir": "/mnt/torrent/incomplete", 
        "rpc-whitelist": "127.0.0.1,192.168.1.*",
        "umask": 23, #osmičková umask, obzvláště výživné
    
    # /etc/fstab
    LABEL=makoto_hdd_btrfs  /mnt/torrent  btrfs     rw,noatime,space_cache,subvol=makoto_torrent    0 0
    
    # /etc/systemd/system/transmission.service.d/customization.conf 
    [Unit]
    Requires=network.target
    RequiresMountsFor=/mnt/torrent
    
    # aby se uživatel dostal ke staženým Linuxovým distribucím:
    usermod -aG transmission nik
    					

    Šikovné je pak ovládání z řádky:

    transmission-remote makoto -a "oblíbená-distribuce.torrent"
    

    Závěr

    Že bude fáze 1 nasazení domácího servříku trvat hrubého času 3 měsíce, jsem tedy nečekal. Čistá bilance by vypadala lépe, neb jsem se tomu krom Vánoc věnoval většinou jen jedno odpoledne týdně. Zas jsem si vyzkoušel pár zajímavých věcí, a ač to teda nedopadlo přesně podle mých představ, tak lze fázi 1 označit za úspěšně dokončenou.

    Shrnuto: systemd potěšil (systemd-user, aktivace služeb na vyžádání, úprava existujících unit a řízení zdrojů), KVM s grafikou spíše zklamalo (zajímalo by mě, zda je to jen danou HW+SW konfigurací, nebo zda je to s grafikou v KVM hostech, vždy takto tragické), btrfs fajn, ale pro KVM vadí, že pododdíly nejsou bloková zařízení. Asi by se tomu dalo vyhnout, kdyby KVM hosti měli vlastní souborový systém, tam pak nevadilo přidat právo přes skupinu.

    Asi budu pokračovat fází 1.5, kde ještě doladím využití btrfs – nějaké ty pravidelné snapshoty a snapshoty při aktualizaci systému.

    PS Přístě si dělám zápisky průběžně.

           

    Hodnocení: 67 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    3.1.2015 15:11 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3

    děláš to vše zbytečně složitě ....

    USE="-gnome -kde";turris
    Nicky726 avatar 3.1.2015 15:35 Nicky726 | skóre: 56 | blog: Nicky726
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    V čem konkrétně?
    Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
    3.1.2015 16:07 qqq
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Hlavně přestaň tapetovat. Seš horší než Jílek.
    pavlix avatar 3.1.2015 20:20 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Nebylo by lepší vyndat hlavu z řiti a jít se věnovat Jílkovi než obtěžovat u technicky zaměřených blogů?
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    3.1.2015 22:45 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3

    existence libvirt. Spoustu veci by ti ulehcila, dale bych zvazil pouziti dockeru ci systemd-nspawn

    USE="-gnome -kde";turris
    Nicky726 avatar 3.1.2015 23:23 Nicky726 | skóre: 56 | blog: Nicky726
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    O libvirt vím, ale nechtěl jsem. Ten nspawn vypadá pro situaci, do které jsem se dopracoval, zajímavě.
    Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
    4.1.2015 00:37 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Klid. Nenech se tím rozhodit. Moje řešení rovněž nepoužívá libvirt.

    Je ovšem pravda, že děláš hodně věcí složitě, ale to se dá pochopit, pokud se s tím teprve seznamuješ. Osobně mi přijde zajímavé, že se to pokoušíš řešit přes systemd. Na druhou stranu, řešit síťování přes bridge, když je k dispozici openvswitch, mi přijde poněkud humpolácké a nepružné.
    pavlix avatar 4.1.2015 09:39 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    řešit síťování přes bridge, když je k dispozici openvswitch, mi přijde poněkud humpolácké a nepružné.

    Jakou výhodu tedy poskytne openvswitch? Klasický bridge je v linuxu nativní nástroj, který se dá skládat s ledasčím.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    4.1.2015 13:58 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Jen tak letmo:

    - Dynamické vytváření portů pro virtuální stroje

    - Operativní práci s konfigurací vlan, aniž by si tím odstřelil hlavní konektivitu

    - Vytváření interních sítí, tunelovaných na jiné virtuální switche, aj.

    Jednou nastavený openvswitch znamená - alespoň pro mne - vyřešené problémy s konektivitou. Kupř. při blbnutí s testovacím sedmi nodovým clusterem, jsem měl nastavenou mimo hlavní síťovou konfiguraci paralelní servisní interní síť, takže když náhodou někde něco při konfiguraci neklaplo, stroj nezůstal nedostupný a mohl jsem to ihned opravit. A to vše na jednom fyzickém interface z každého stroje.
    pavlix avatar 4.1.2015 14:50 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Dynamické vytváření portů pro virtuální stroje
    Operativní práci s konfigurací vlan, aniž by si tím odstřelil hlavní konektivitu
    Vytváření interních sítí
    tunelovaných na jiné virtuální switche
    Máme tu čtyři různé body. Ani u jednoho nevím, proč by to nešlo se stávající kernelovou infrastrukturou.
    Jednou nastavený openvswitch znamená - alespoň pro mne - vyřešené problémy s konektivitou.
    To chápu. Stejně jako jakýkoli jiný vyhovující nástroj nebo sada nástrojů, která jde nakonfigurovat a dále používat.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    4.1.2015 19:28 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Máme tu čtyři různé body. Ani u jednoho nevím, proč by to nešlo se stávající kernelovou infrastrukturou.
    Však já nikde nepsal, že to nejde řešit i jinak. Dotaz byl: "Jakou výhodu tedy poskytne openvswitch?"
    pavlix avatar 4.1.2015 20:57 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Dotaz byl: "Jakou výhodu tedy poskytne openvswitch?"
    Obávám se, že to jsem se zatím nedozvěděl. Ale je klidně možné, že mi odpověď může nabídnout jenom člověk zkušený v řešení s openvswitch i bez něj a takoví se asi těžko hledají.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    5.1.2015 00:28 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Obávám se, že se svým přístupem se uspokojivé odpovědi nedočkáš. O tom co je výhoda, má totiž každý svou vlastní představu. Já volím technologie pokud možno tak, aby jejich použití bylo výhodné pro dané použití. Tzn. že co může být výhodné pro mne, nemusí být výhodné pro někoho jiného. Na druhou stranu nasazení openvswitche usnadňuje především změny do budoucna. Klasické řešení, s využitím vlan a bridgů, takovou pružnost nenabízí.
    pavlix avatar 5.1.2015 10:53 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Obávám se, že se svým přístupem se uspokojivé odpovědi nedočkáš.
    S možností, že se odpovědi nedočkám, celkem počítám, ale nevím, co jsem ti udělal tak zlého, že máš potřebu to svádět na můj přístup.
    Na druhou stranu nasazení openvswitche usnadňuje především změny do budoucna. Klasické řešení, s využitím vlan a bridgů, takovou pružnost nenabízí.
    Jenže to jsou stále jenom prázdné kecy jak z marketingového oddělení. Pokud se nedozvím alespoň jednu konkrétní věc a u ní konkrétní výhody, diskuze brzy ztratí smysl.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    5.1.2015 12:34 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Tvůj přístup je především vadný v tom, že nejsi schopen akceptovat, že jiní uživatelé mají jiné potřeby než ty. Pokud by tě zajímalo řešení nějaké konkrétní věci, tak bys především musel nejprve nastínit jak ji máš řešenou ty - tak jako to učinil autor tohoto blogpostu.
    pavlix avatar 5.1.2015 14:36 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    nejsi schopen akceptovat, že jiní uživatelé mají jiné potřeby než ty.
    Obávám se, že jsi si zde jen nastavil zrcadlo. Pokud vím, tak jsi to byl ty, kdo shazoval jedno ze dvou možných řešení, takže asi nedává smysl abys z výše uvedeného obviňoval kohokoli jiného než sebe.
    Pokud by tě zajímalo řešení nějaké konkrétní věci, tak bys především musel nejprve nastínit jak ji máš řešenou ty
    Nesmysl. Ty jsi prezentoval jedno řešení jako špatné a druhé jako dobré. Je tedy na tobě, abys to buď obhájil nebo nechal neobhájené. Jestli ti můžu poradit, tak je mnohem čistší přiznat, že ve skutečnosti nevíš, říct, že to asi neumíš vysvětlit, nebo se jednoduše vymluvit, že na to teď nemáš čas. Ale klidně si můžeš vycucat z prstu nějaký výrok shazující tazatele, pokud ti to dělá dobře.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    5.1.2015 17:40 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Obávám se, že problém je spíš v tom, že se pavlix ptal na výhody openvswitch oproti infrastruktuře v jádře, a jako odpověď dostal seznam věcí, které ta jaderná infrastruktra nabízí (tudíž ty věci nelze považovat za výhody.) Tím neříkám, že openvswitch je špatný, ale z popisů, které jsem viděl (většinou ve vašem blogu) mi spíš než co jiného přijde jako nástroj usnadňující nastavení a správu ostatních jaderných komponent.
    Quando omni flunkus moritati
    pavlix avatar 5.1.2015 18:00 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    +1

    Samozřejmě z pohledu uživatele lze za validní výhody označit i ty, které se jádra netýkají, ale je potřeba to rozlišit a je potřeba ty výhody nějak jasně definovat, pokud to nemá být jenom chvalozpěv.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    5.1.2015 21:05 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Openvswitch je v jádře, tudíž nejde o nástroj ke konfiguraci jiných komponent, nýbrž o komponentu, která je nahrazuje.
    6.1.2015 00:33 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    No v tom odkazu níž píšou něco o tom, že se snažili použít co nejvíc existující infrastruktury, takže bych hádal, že s tím nahrazením to nebude tak žhavé. Ostatně když koukám na obrázky na jejich webu, tak je to tam samé VM - tap0 - br0, tedy přesně ten bridge, který jste nahoře zkritizoval jako humpolácké řešení.

    Zkusil jsem projít jejich web, článek na LWN, ale nenašel jsem nic, o čem bych si řekl "jo, to by se hodilo". To, co obsahuje sekce "features", je v podstatě výčet věcí, které v jádře byly už před open vSwitch. Uznávám, jako konfigurační nástroj to vypadá pěkně, na první pohled o něco jednoduššeji než manipulace s jednotlivými komponentami přímo. Ale jiný přínos tam moc vidět není.
    Quando omni flunkus moritati
    6.1.2015 08:06 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Nejsem vývojářem Openvswitche, pouze uživatel a zaobíral jsem se jím jen do té míry abych mohl zdokumentovat svoje řešení. Takže k tomu mohu jen říct že názvy použité v dokumentaci jsou volené tak aby co nejvíc usnadnily pochopení jak to funguje a co nahrazuje. Tap zařízení se používá naprosto běžně i u jiných řešení - např. u vde2 switche který ovšem jinak běží v userspace. Já jsem jím nahradil zmíněný vde2 switch, a jaderné moduly pro vytvoření bridge a separaci vlan. Mimochodem, podobné řešení na bázi Openvswitche, jak jsem s překvapením zjistil, používá pro síťování i Citrix Xen server.
    6.1.2015 13:32 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Takže k tomu mohu jen říct že názvy použité v dokumentaci jsou volené tak aby co nejvíc usnadnily pochopení jak to funguje a co nahrazuje.

    Takže chcete říct, že když na hostiteli, kde se tohle používá, pustíte brctl show, tak to nic neukáže?
    Já jsem jím nahradil ... jaderné moduly pro vytvoření bridge a separaci vlan.
    To je právě to, o čem dost pochybuju. Připouštím, že před vámi openvswitch může zkoušet leccos schovat, ale opravdu se mi nezdá, že by vývojářům při začlenění do jádra prošla duplikace kódu jak pro ten bridge, tak pro vlany.
    Mimochodem, podobné řešení na bázi Openvswitche, jak jsem s překvapením zjistil, používá pro síťování i Citrix Xen server.

    No nevím jak Citrix Xen server, ale normální server s Xenem se taky bude tvářit, že síť je hogofogo cosi, načež se ukáže, že síťovka peth0 je přejmenované eth0 a eth0 je bridge, který se nejmenuje br0.
    Quando omni flunkus moritati
    pavlix avatar 6.1.2015 13:39 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Nešlapej mu po jeho modlách, vždyť vidíš, jak je z toho nešťastný.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    6.1.2015 14:11 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    No já bych se rád dobral toho, jak ten openvswitch funguje, co přesně dělá a jestli má cenu, abych tomu věnoval pozornost (tj. jestli mi použití něco přinese.) Jestli vás to nezajímá, tak si klidně rýpejte, ale mě do toho netahejte.
    Quando omni flunkus moritati
    pavlix avatar 6.1.2015 15:41 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    To chápu, ale já vím jenom málo a z Aleše těžko dostaneš nějaké technické detaily. Co vím, tak do jisté míry využívá stávající moduly, slyšel jsem hlavně o bondingu, nevím, jak moc se to týká vlan a bridge, nicméně se to neprojevuje navenek. Ten návrh je takový víc monolitický, že openvswitch je vlastně kernel i userspace, ne jako jednotlivé moduly v kernelu, poskládané pomocí userspace nástroje. Zatím pro mě nebyl dost zajímavý, abych ho zkoumal blíže. Uvažoval jsem o tom jenom kdyby se mi chtělo hledat výnosnější zaměstnání, protože buzzword, ale to byly skutečně jen úvahy.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    6.1.2015 15:51 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3

    Stroj snoopy je jeden z nejstarších strojů mého clusteru, které ještě mají původní síťovou konfiguraci bez openvswitche. Což je bohužel jediná příčina, proč tyto stroje nemohou současně fungovat i jako virtualizační. Původně se na nich pro tento účel využívaly vde2 switche - viz KVM (networking) v naší wiki

    snoopy (DATASERVER) :~# lsmod | grep -E '(bridge|8021q)'
    8021q                  23895  0 
    garp                   13148  1 8021q
    mrp                    13325  1 8021q
    bridge                 81844  0 
    stp                    12437  2 garp,bridge
    llc                    12783  3 stp,garp,bridge
    snoopy (DATASERVER) :~# brctl show
    bridge name     bridge id               STP enabled     interfaces
    br0             8000.4061868d10df       no              eth0
    br17            8000.4061868d10de       no              vlan17
    br202           8000.4061868d10de       no              vlan202
    br223           8000.4061868d10de       no              vlan223
    br226           8000.4061868d10de       no              vlan226
    br5             8000.4061868d10de       no              vlan5
    

    Infrastruktura strojů lucy a patty již využívá openvswitch. Každý z nich může fungovat jak datový stroj, tak virtualizační, proto pro rálnou představu v následujícím výpisu uvádím výpis konfigurace openvswitche pro oba stroje

    patty (DATASERVER) :~# lsmod | grep -E '(bridge|8021q)'
    patty (DATASERVER) :~# brctl show
    bridge name     bridge id               STP enabled     interfaces
    patty (DATASERVER) :~# ovs-vsctl show
    458eb0ea-1825-40de-8e3b-028ea61c0faf
        Bridge main
            Port "main5"
                tag: 5
                Interface "main5"
                    type: internal
            Port "nfs-k328"
                tag: 54
                Interface "nfs-k328"
                    type: internal
            Port main
                Interface main
                    type: internal
            Port "main-aa4cc-5"
                tag: 5
                Interface "main-aa4cc-5"
            Port "nfs-k23"
                tag: 223
                Interface "nfs-k23"
                    type: internal
            Port "nfs-k2"
                tag: 202
                Interface "nfs-k2"
                    type: internal
            Port "nfs-k26"
                tag: 226
                Interface "nfs-k26"
                    type: internal
            Port "eth2"
                trunks: [1, 4, 5, 17, 54, 202, 223, 226]
                Interface "eth2"
            Port "nfs-k9"
                tag: 17
                Interface "nfs-k9"
                    type: internal
        Bridge interni
            Port interni
                Interface interni
                    type: internal
            Port "eth3"
                Interface "eth3"
            Port "interni-aa4cc"
                Interface "interni-aa4cc"
        ovs_version: "2.1.0"
    patty (DATASERVER) :~# ip tuntap
    patty (DATASERVER) :~# 
    

    Jak je z výpisu zřejmé, bridge se nemusí nutně jmenovat br.. a jak je zřejmé z předchozího výpisu, port nemusí být nutně připojen na tap zařízení.

    lucy (DATASERVER) :~# ovs-vsctl show
    c66d1285-ef67-4c03-9bca-57e387bb0ff1
        Bridge main
            Port "nfs-k328"
                tag: 54
                Interface "nfs-k328"
                    type: internal
            Port "main-samba-4"
                tag: 4
                Interface "main-samba-4"
            Port "nfs-k2"
                tag: 202
                Interface "nfs-k2"
                    type: internal
            Port "main-poste-17"
                tag: 17
                Interface "main-poste-17"
            Port "main-media-1"
                tag: 1
                Interface "main-media-1"
            Port "main-k2-223"
                tag: 223
                Interface "main-k2-223"
            Port "main-redmi-5"
                tag: 5
                Interface "main-redmi-5"
            Port main
                Interface main
                    type: internal
            Port "main-k2-226"
                tag: 226
                Interface "main-k2-226"
            Port "nfs-k23"
                tag: 223
                Interface "nfs-k23"
                    type: internal
            Port "main-k2-54"
                tag: 54
                Interface "main-k2-54"
            Port "nfs-k26"
                tag: 226
                Interface "nfs-k26"
                    type: internal
            Port "main-suppo-1"
                tag: 1
                Interface "main-suppo-1"
            Port "nfs-k9"
                tag: 17
                Interface "nfs-k9"
                    type: internal
            Port "main-k2-1"
                tag: 1
                Interface "main-k2-1"
            Port "main-boura-54"
                tag: 54
                Interface "main-boura-54"
            Port "main5"
                tag: 5
                Interface "main5"
                    type: internal
            Port "main-x32bi-4"
                tag: 4
                Interface "main-x32bi-4"
            Port "main-moodl-1"
                tag: 1
                Interface "main-moodl-1"
            Port "main-git-1"
                tag: 1
                Interface "main-git-1"
            Port "main-k2-202"
                tag: 202
                Interface "main-k2-202"
            Port "main-mapse-5"
                tag: 5
                Interface "main-mapse-5"
            Port "main-felk--5"
                tag: 5
                Interface "main-felk--5"
            Port "main-drupa-1"
                tag: 1
                Interface "main-drupa-1"
            Port "main-poste-5"
                tag: 5
                Interface "main-poste-5"
            Port "eth2"
                trunks: [1, 4, 5, 17, 54, 202, 223, 226]
                Interface "eth2"
            Port "main-k2-17"
                tag: 17
                Interface "main-k2-17"
            Port "main-build-5"
                tag: 5
                Interface "main-build-5"
            Port "main-aa4cc-5"
                tag: 5
                Interface "main-aa4cc-5"
            Port "main-k2-5"
                tag: 5
                Interface "main-k2-5"
        Bridge interni
            Port "interni-x32bi"
                Interface "interni-x32bi"
            Port interni-drupa
                Interface interni-drupa
            Port interni-moodl
                Interface interni-moodl
            Port interni
                Interface interni
                    type: internal
            Port interni-build
                Interface interni-build
            Port interni-git
                Interface interni-git
            Port interni-suppo
                Interface interni-suppo
            Port interni-redmi
                Interface interni-redmi
            Port interni-felk-
                Interface interni-felk-
            Port "eth3"
                Interface "eth3"
            Port interni-mapse
                Interface interni-mapse
            Port interni-samba
                Interface interni-samba
            Port "interni-aa4cc"
                Interface "interni-aa4cc"
            Port "interni-k2"
                Interface "interni-k2"
        ovs_version: "2.1.0"
    lucy (DATASERVER) :~# ip tuntap
    main-poste-5: tap vnet_hdr
    main-build-5: tap vnet_hdr
    main-k2-17: tap vnet_hdr
    main-k2-54: tap vnet_hdr
    main-git-1: tap vnet_hdr
    interni-git: tap vnet_hdr
    interni-k2: tap vnet_hdr
    main-moodl-1: tap vnet_hdr
    main-aa4cc-5: tap vnet_hdr
    main-suppo-1: tap vnet_hdr
    main-k2-1: tap vnet_hdr
    main-k2-5: tap vnet_hdr
    main-poste-17: tap vnet_hdr
    main-felk--5: tap vnet_hdr
    main-mapse-5: tap vnet_hdr
    main-x32bi-4: tap vnet_hdr
    main-drupa-1: tap vnet_hdr
    main-k2-226: tap vnet_hdr
    main-k2-223: tap vnet_hdr
    main-k2-202: tap vnet_hdr
    main-samba-4: tap vnet_hdr
    interni-suppo: tap vnet_hdr
    interni-aa4cc: tap vnet_hdr
    interni-build: tap vnet_hdr
    interni-drupa: tap vnet_hdr
    interni-felk-: tap vnet_hdr
    interni-mapse: tap vnet_hdr
    interni-moodl: tap vnet_hdr
    interni-redmi: tap vnet_hdr
    interni-samba: tap vnet_hdr
    interni-x32bi: tap vnet_hdr
    main-redmi-5: tap vnet_hdr
    

    Jak snad jistě i pavlix uzná, spravovat něco podobného klasicky přes /etc/network/interfaces by bylo poněkud vražedné.

    7.1.2015 01:49 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Infrastruktura strojů lucy a patty již využívá openvswitch. Každý z nich může fungovat jak datový stroj, tak virtualizační, proto pro rálnou představu v následujícím výpisu uvádím výpis konfigurace openvswitche pro oba stroje
    Ok, žádné kernelové bridge, které by se tak hlásily.

    Už jsem to psal, fakt se mi nezdá, že by vývojářům openvswitch prošla tak velká duplikace kódu, jakou by bezesporu byla reimplementace bridge. Bezesporu píšu, protože linuxový bridge se v rámci jednoho hostitele chová jako switch - spravuje si porty, ať už fyzické či virtuální síťovky, drží se seznam MAC adres na jednotlivých portech apod. Furt mám zato, že využívají stejný kód.
    Jak snad jistě i pavlix uzná, spravovat něco podobného klasicky přes /etc/network/interfaces by bylo poněkud vražedné.
    Tak to uzná asi každý, kdo používá zdravý rozum. Pokud člověk potřebuje víc než "síťovce xyz nastav adresu a.b.c.d/e a k tomu bránu a.s.d.f", je práce s tímhle souborem - zejména strojové zpracování - totální katastrofa. Už jsem se několikrát podivoval, že se v Debianu nikdo neobtěžoval tenhle otřes předělat. Rejp, asi neměli čas, protože se věnovali mnohem důležitějšímu a potřebnějšímu systemd.

    Na druhou stranu když odhlédnu od jednodušší konfigurace, tak mi pořád uniká, v čem má openvswitch výhodu nad použitím bridge. U našich virtualizačních strojů je síť řešená tak, že co virtuál, to tap síťovka, všechny jsou spojené do bridge společně s fyzickým ethernet rozhraním, které je připojené do internetu. VLANy se tam nepoužívají, ale kdyby to bylo potřeba, tak na hostiteli stačí pro každou VLAN vytvořit samostatný bridge, do toho nacpat tap rozhraní jenom těch virtuálů, které do ní mají být zapojené, a do fyzické sítě to zapojit přes fyzické něco jako eth0.10 (ip link add link eth0 name eth0.10 type vlan id 10). Live migrace mezi hostiteli není problém - co jsem si všiml, tak se qemu postará o aktualizaci ARP tabulek bez nějakého dalšího snažení a pak už mě nenapadá nic, co by se ještě mohlo hodit.

    Zajímavější by to bylo, kdybych chtěl vytvořit něco jako distribuovaný switch, do kterého by byly zapojené virtuály přes několik hostitelů, ale jejich provoz by nebyl vidět na fyzické síti. Nicméně i to by asi nějak šlo buď přes separátní vlan, nebo nějakým (gre?) tunelem, tj. furt nic, co by bez openvswitch nešlo.

    ---

    Jen tak mimochodem, nakoukl jsem na tu wiki stránku networking a trochu mě zaujalo/zmátlo opakované povídání o té KVM vlan. Pak jsem to dohledal v dokumentaci a pokud to dobře chápu, tak když místo net-net použijete netdev-device, nemusíte žádné vlan=x řešit.
    Quando omni flunkus moritati
    7.1.2015 08:34 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Už jsem to tady několikrát zmiňoval - to jsou ty z Pavlixova pohledu nic neříkající kecy - že moje pro moje virtuály se zakládají a ruší porty na virtuálním Openvswitchi podle potřeby. Proto mi vyhovuje, že konfigurace v /etc/network/interfaces řeší pouze základní nastavení fyzických rozhraní. O všechno ostatní se mi stará Pacemaker a fakt to poslední co potřebuji je nějaký network manažer, který mi v tom svou autodetekcí bude dělat bordel. Ta základní síťová konfigurace slouží pouze k tomu, aby se byl schopen stroj domluvit s ostatními nody v clusteru. Asi by to bylo zřejmé kdybych sem nakopíroval i jejich obsah, ale nemusí zase naše interní ip viset všude.

    Co se týče toho, jak to je uvnitř Openvswitche tak soudím, že bezpochyby využívá kódu zmíněných modulů, ale k tomu je přeci nepotřebuje mít samostaně zavedené. Je to zcela identická situace jako u Btrfs, které také používá kusy kódu z md raidu, ale funguje trochu jinak.
    pavlix avatar 7.1.2015 12:01 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    fakt to poslední co potřebuji je nějaký network manažer,
    A proto máš openvswitch :).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.1.2015 13:42 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Překvapuje mne, že zrovna ty nechápeš rozdíl mezi switchem a konfigurátorem síťových zařízení.
    pavlix avatar 7.1.2015 13:48 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Pobavilo.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.1.2015 13:16 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Už jsem to tady několikrát zmiňoval - to jsou ty z Pavlixova pohledu nic neříkající kecy - že moje pro moje virtuály se zakládají a ruší porty na virtuálním Openvswitchi podle potřeby.
    Teď si nejsem jistý, jestli je to odpověď na tu výhodu oproti bridge. Ale jestli jo, tak to přece bridge umí taky:
    tunctl -t tapx
    ip link set tapx up
    brctl addif brx tapx
    
    brctl delif brx tapx
    ip link set tapx down
    tunctl -d tapx
    Co se týče toho, jak to je uvnitř Openvswitche tak soudím, že bezpochyby využívá kódu zmíněných modulů, ale k tomu je přeci nepotřebuje mít samostaně zavedené.
    Tak jasně že ne, ale pak je otázka, jak moc přesné je tvrzení "nepoužívám linuxový bridge", když tu použitou funkcionalitu v openvswitch interně zajišťuje stejný kód.
    Quando omni flunkus moritati
    7.1.2015 14:04 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Tak jasně že ne, ale pak je otázka, jak moc přesné je tvrzení "nepoužívám linuxový bridge", když tu použitou funkcionalitu v openvswitch interně zajišťuje stejný kód.
    Tak tady už se dostáváme k onomu klasickému "já o voze, on o koze". Pokud napíšu, že nepoužívám bridge, tak tím mám na mysli, že nemám zavedený jaderný modul bridge a nevyskytuje se mi ani v konfiguraci /etc/network/interfaces. Zda-li s ním má Openvswitch něco společného z hlediska kódu je pro mne naprosto nezajímavá informace. Nevylučuji tím, že pro někoho jiného může "použití" znamenat i využití určité části kódu.
    ..to přece bridge umí taky
    Jenže tohle vytvoření tap zařízení a jeho zapojení do bridge je pouze jedna, relativně marginální část o kterou se Openvswitch vůbec nestará. Tohle mi řeší skript který si při spouštění volá qemu. Openvswitch je virtuální switch se vším všudy, který umožňuje stejné opičky jako fyzické zařízení. Z jedné strany, přes fyzický interface mi do něj leze trunk a VLAN se nastavují až při zavedení portu, předtím, než se na něj připojí tap interface virtuálního stroje.

    Můžu tak bez problému v rámci clusteru přesunout virtuály na libovolný stroj, na kterém musí běžet pouze openvswitch. V podstatě by to může být i bezdiskový stroj s výkoným CPU a dostatkem RAM a , bez ohledu na to co dalšího je na něm z hlediska sítě nakonfigurované. Můžu dělat i zcela izolované vnitřní sítě. Škrtit porty dle libosti, aj.
    pavlix avatar 7.1.2015 14:10 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Popravdě řečeno jsem před časem testoval přesuny s klasickým linuxovým bridgem. Proto jsem se taky v diskuzi ptal na konkrétní výhody, ale už jsem celkem smířený s tím, že se o tom budu muset pobavit s někým jiným. A koncem měsíce budu mít i příležitost ;).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.1.2015 15:20 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Hodně štěstí! Pro Maxe bylo rychlejší zabrousit na Karlovo náměstí.
    pavlix avatar 7.1.2015 15:55 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Tak já zabrousím do Bruselu, no :).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.1.2015 16:11 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Pohádka na cestu. ;-)
    7.1.2015 17:02 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Nevylučuji tím, že pro někoho jiného může "použití" znamenat i využití určité části kódu.
    Tady je tenhle pohled důležitý proto, že tam, kde se používá stejný kód, je stejná i poskytovaná funkcionalita.
    Openvswitch je virtuální switch se vším všudy, který umožňuje stejné opičky jako fyzické zařízení.
    Jenže to infrastruktra v kernelu (myslím bez openvswitch) taky. Jaderný bridge zastává stejnou funkctionalitu jako switch. Sasmozřejmě různá fyzická zařízení mají různé schopnosti, ale...
    Z jedné strany, přes fyzický interface mi do něj leze trunk a VLAN se nastavují až při zavedení portu, předtím, než se na něj připojí tap interface virtuálního stroje.
    ...tohle umí jaderná infrastruktura taky. Fyzická síťovka se rozdělí na virtuální podle VLAN ID (ip link add výše), ty virtuální se pak vloží jako port do bridge (jeden bridge pro každou VLAN). Když se pak vytvoří tap zařízení, přidá se do bridge podle toho, ve které VLAN ten virtuál má být.
    Můžu tak bez problému v rámci clusteru přesunout virtuály na libovolný stroj
    To také jde bez openvswitch. Před spuštěním virtuálu se vytvoří tap zařízení, osadí se do bridge, pak se ten virtuál (qemu proces) spustí a začne se na něj migrovat. Výpadek konektivity toho virtuálu po dokončení migrace je minimální (v podstatě čím větší provoz, tím menší.)
    Můžu dělat i zcela izolované vnitřní sítě.
    Taktéž jde bez openvswitch - bridge v rámci jednoho hostitele, tap zařízení jako porty pro jednotlivé virtuály, propojení mezi hostiteli třeba pomocí tunelu (tuším GRE), přičemž gre rozhraní také zapojím do toho bridge. Na ostatních hostitelích, jejichž virtuály mají být do té izolované sítě také zapojeny, udělám to samé a o předávání rámců mezi hostiteli - když je to potřeba - se už postarají kernely obou hostitelských strojů
    Škrtit porty dle libosti
    Taky - stačí pro daný port nastavit traffic shaper v jádře. Tohle všechno jde samozřejmě nastavit za běhu, aniž bych to musel mít v interfaces.

    Jinak nevykládejte si to tak, že bych vás chtěl přesvědčovat, že openvswitch nemáte používat. Spíš by ale bylo dobré mít na paměti, že - podle toho, co jste zatím popsal - vám jako jedinou přidanou hodnotu poskytuje zjednodušení konfigurace (jeden příkaz místo hodně příkazů.) A že to tedy není žádné zázračné řešení, které vám poskytuje něco navíc, co by kernel jinak neměl. A v neposlední řadě že není dobré označovat použití bridge jako "humpolácké řešení", když vlastně používáte totéž (stejný kód), akorát nakonfigurované jiným způsobem.
    Quando omni flunkus moritati
    7.1.2015 18:34 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Však já nikde neříkám, že to nejde. Pro mne je podstatné, že jsem to potřeboval udělat tak, abych mohl veškerou správu infrastruktury přenechat na Pacemakeru. A pro tento účel se ukázalo nejvýhodnější použít openvswitch. Pro cokoliv jiného bych musel psát nějaké vlastní obslužné skripty a na tohle fakt nemám čas. Pokud něco označím za "humpolácké" řešení, tak tím rozhodně nemám na mysli, že by to nebylo funkční. Ostatně, více viz
    6.1.2015 16:02 MarSarK | skóre: 23 | blog: marsark_linux | Praha
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    A nebo třeba takto, je li libo LACP bonding. Kernelu není potřeba nic, z bridge, vlan, bond atd. Chová se to vlastně jako fyzické switch.
    ares3 ~ # ovs-vsctl show
    4de59ac4-58da-4f23-92d8-b7cf17c8eacb
        Bridge "ovsbr0"
            Port "ovsbr0"
                tag: 1
                Interface "ovsbr0"
                    type: internal
            Port "vnet0"
                tag: 4
                Interface "vnet0"
            Port "bond0"
                Interface "eno1"
                Interface "eno2"
    
    Even a small adventure could be a beginning of a great journey.
    7.1.2015 02:08 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Kernelu není potřeba nic, z bridge, vlan, bond atd.

    Jak jsem psal o něco výš, nevěřím tomu - to by znamenalo veškerou funkcionalitu, která v jádře byla, znovu napsat. A taky by to znamenalo nějak přesvědčit vývojáře mainline, aby si při začleňování nevšimli toho, že openvswitch duplikuje funkcionalitu. Což si všimli - pokud dobře překládám, při zaslání k začlenění to duplikovalo mechanismus pro klasifikaci a řízení paketů - reimplementace bridge, vlan, bond atd. by asi pozornosti neunikla.
    Quando omni flunkus moritati
    pavlix avatar 7.1.2015 12:05 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Osobně jsem si vždycky myslel, že openvswitch prošel jen díky velkému tlaku z komerční sféry. Co jsem se bavil s kerneláři co do něj fušují, tak mimo záznam neměli problém říct, že je to z pohledu vývoje linuxu hrozná sračka. Pohled uživatele je samozřejmě od takových technických detailů značně odstíněný.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.1.2015 20:26 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Co jsem se bavil s kerneláři co do něj fušují, tak mimo záznam neměli problém říct, že je to z pohledu vývoje linuxu hrozná sračka.
    To je možné. Já si to rovněž o některých věcech myslím a přesto je používám, protože jiná, lépe udělaná alternativa k dispozici není. Ale není reálné si všechno napsat sám. Krom toho, tohle je open source, takže ještě vcelku dobrý. Třeba se někdo najde, kdo to v budoucnu udělá lépe. Jenže když vidím čuňačiny, za které něž se některé firmy nestydí inkasovat nehorázné peníze, tak to bych teprv blil.
    pavlix avatar 7.1.2015 21:33 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Však jsem ti ani v nejmenším nevyčítal, že openvswitch používáš. Kdo jsem já, abych rozhodoval o tom, co mají profesionální admini používat. Sám jsem byl vždycky spíš experimentátor a posledních několik let se snažím adminování omezit jen na svoji vlastní nekritickou infrastrukturu.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    8.1.2015 09:37 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Vžyť nic neříkám. Jinak i když jsem to nijak explicitně nezmínil, tak není problém se k nám zastavit a případně si pohovořit o tom, jak některé veci řešíme. Konec konců jsme veřejná instituce. Mou hlavní parketou jsou stroje virtualizované v prostředí Pacemakeru. Síť a infrastrukturu kolem ní řeší můj kolega od vedlejšího stolu MarSarK.
    pavlix avatar 8.1.2015 10:10 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Ale jo, někdy určitě pohovoříme, to není úplně špatný nápad už jen proto, že se v diskuzích vídáme víc než dost, takže spojit si diskuzi s reálným ksichtem nemusí být úplně od věci. Konkrétně k openvswitch mě ale v první zajímá spíše takový méně uživatelský a více vývojářský pohled. Když už jsme u toho, nechystáš se na nějaký ze srazů?
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    8.1.2015 11:19 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    No na jednom nedávném srazu jsem se zastavil, ale účast nebyla nejhojnější, takže jsem překočoval do Šumavské kde jsem se měl sejít ještě s jedním kámošem. Obecně však srazy v restauračních zařízeních moc nemiluju. Sice se na nich lidé názorově sbližují, ale z praktického hlediska je to o ničem.

    Dokud jsem byl ještě hlavně v OV (do r. 2008) tak jsme se občas sešli. I když oficiálně ty akce organizoval kolega Stopka - tehdy to byl ještě takový mladý tukan ;-). Pak mu ale stouplo do hlavy, že začal dělat v korporačce a hodil na to bobek. Nicméně tvrdé jádro tvořené mými kolegy a kamarády se pak ještě občas sešlo v Narcisu. Teď během pobytu v OV jen tak tak stíháme obrazit dědečky a babičky, a jsem rád, když mi vyjde čas alespoň na to, abych se viděl s kámošem co mě na úřadě nahradil.

    Mnohem lepší jsou akce typu LinuxAlt, Installfest nebo Linux Days, jenže ani na tohle moc času nezbývá.
    pavlix avatar 8.1.2015 11:26 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Tak si zkus naplánovat návštěvu InstallFestu, akorát budu potřebovat, abys mě tam odchytil a řekl mi, kdo jsi, protože toho asi jinak budu mít trochu moc.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 8.1.2015 11:29 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Teď mě napadá, je stále otevřený CFP a to včetně tracku o sítích, takže jestli ty nebo nějaký kolega něco máte, tak tím líp.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    6.1.2015 16:26 VSi | skóre: 28
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Umožňuje OVS realizovat víceúrovňový bonding? Kernelový bonding to totiž neumí, nebo aspoň mě to nefunguje. Mám 2 LACP trunky do 2 switchů, a nad nimi bych chtěl udělat active-failover bond. Alternativa je v druhé úrovni udělat bridge, ale linuxový umí jen obyčejné STP, kde jsou konvergenční časy dost nepříjemné. Jde to realizovat na OVS? A umí OVS RSTP/MSTP?

    Nemá někdo zkušenost s používání OVS a DRBD zároveň? Od doby co je v XenServeru výchozí OVS, tak ho musím vypínat, protože jinak v kombinaci s DRBD dochází k zátuhům kernelu... http://openvswitch.org/pipermail/dev/2013-March/026334.html
    6.1.2015 16:38 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Tak pokud jde o DRBD, tak to se vždy snažím připojit zcela nezávisle na zbylé síťové infrastruktuře. I když na testovacím clusteru ho mám i nad openvswitchem. Ale pravda také je, že používám aktuální verze jak openvswitche (2.1), tak drbd (8.4).
    4.1.2015 23:34 citanus | skóre: 10 | Cork (Ireland)
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Nicky726 avatar 5.1.2015 08:26 Nicky726 | skóre: 56 | blog: Nicky726
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Díky, povědomí o openvswitch by se mohlo hodit pro nějaká větší nasazení.
    Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
    Max avatar 3.1.2015 22:35 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Zajímavé, možná mně něco podobného bude čekat, ale v širším měřítku.
    Zdar Max
    Měl jsem sen ... :(
    Migilenik avatar 5.1.2015 16:02 Migilenik | skóre: 58 | blog: Mig_Alley
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Pěkné, ale přijde mi to moc práce za málo muziky. Přijde mi to jako takové dítko vztahu Docker s OpenVZ.
    GIMP 2.8 Cage Transformation - what is it good for? http://www.youtube.com/watch?v=S4whULCb8t0
    6.1.2015 19:19 otmar
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Dobře, že ses tu objevil. Napiš a hoď sem prosím tě nějaký pořádný blogpost, nebo tu bude jenom dalších deset dílů těch ptákovin !
    6.1.2015 19:44 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Si zablokuj autora, pokud tě jeho blogy nebaví. A úplně nejlépe uděláš, když sám přispěješ vlastním hodnotným blogem místo blbých keců v diskuzi.
    6.1.2015 20:17 gunar
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    A ty by si nenapsal něco novýho ?
    6.1.2015 21:02 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3
    Dělá se na tom.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.