Byla vydána verze 0.2.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Společnost Cloudflare jej letos v únoru uvolnila pod licencí Apache 2.0.
Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
/sys/class/net/ethX/device budou soubory sriov_. Pokud tam jsou a pokud do nich půjde zapisovat (na serverech, co používáme, se to musí extra povolit v biosu), karta SR-IOV podporuje. Pak můžete místo virtio síťovky do toho virtuálního serveru přímo dát ten "fyzický" hardware. (Klíčová slova pro hledání jsou vfio passthrough)
Výhoda - ty Windows budou na stejné fyzické síti bez další práce. Nevýhody - ten virtuální server bude muset zamknout (memlock) svoji paměť do fyzické, tj. nemůžete použít KSM (deduplikace paměti) a taky budete muset sehnat ovladač té fyzické karty do Windows - a to ne přímo té karty, ale její virtuální funkce.
22.9.2020 11:11
Max | skóre: 72
| blog: Max_Devaine
22.9.2020 11:22
Max | skóre: 72
| blog: Max_Devaine
# vytvoříme si virtuální disk : qemu-img create -f qcow2 ./MyServer.qcow2 20G # vytvoříme si VM : virt-install --name MyServer --ram 16384 \ --os-type=linux \ --os-variant=ol5.11 \ --disk path=/vm/MyServer_01.qcow2,format=qcow2,bus=virtio,size=60 \ -c /mnt/iso/Oracle/OEL/OEL-5U11-V47133-01.iso \ --network bridge=br0-lan,model=virtio,mac=RANDOM \ --graphics vnc,password=heslo,listen=0.0.0.0,port=5900 --noautoconsole \ -v --vcpus=12 \ --boot cdrom,hdA pak jednoduchý mgmt:
# seznam VM : virsh list --all # start/stop : virsh shutdown guest1 --mode acpi virsh start virsh shutdown virsh suspend virsh reset virsh reboot virsh console # zobrazit nastavení : virsh dumpxml MyServer # zmazat vm : virsh undefine MyServer # připojit cd : virsh attach-disk MyServer /mnt/iso/Oracle/OEL/OEL-5U11-V47133-01.iso hdc --type cdrom --mode readonly # zobrazit info o img : qemu-img info MyServer_01.qcow # zobrazit seznam podporovaných os variant: virt-install --os-variant listZdar Max
qemu-system-x86_64 -device ? | grep qemu64 tak mi to ukazuje:
name "qemu64-v1-x86_64-cpu" name "qemu64-x86_64-cpu"V nějaké verzi Qemu zřejmě vznikla druhá verze virtuálního procesoru qemu64. Nebo v sekci Storage používají
-drive if=virtio,...ale dnes by se mělo používat:
-drive if=none,... -device virtio-blk-pci,...nebo ještě modernější:
-drive if=none,... -device virtio-scsi-pci,...No vlastně místo
-drive by se nově mělo používat -blockdev
Podobně je to u Network:
-netdev ... -device virtio-net-pci ...Zajímalo by mne jestli je ještě pořád aktuální věta o BTRFS:
Don't use the linux filesystem btrfs on the host for the image files. It will result in low IO performance. The kvm guest may even freeze when high IO traffic is done on the guest.Pokud bys chtěl optimalizovat ještě víc, tak někdo používá "cpu pinning", ale to na serveru asi nevyužiješ, ale je vhodné použít HyperV parametry (HyperV požívat nemusíš) pro CPU nějak takto:
-cpu host,kvm=off,hv_synic,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,...ale taky už možná nejsou úplně aktuální - zkus pogooglit. Těmi příznaky "řekneš" virtuálce Windowsu, že běží ve virtuálce a Win by tak měl fungovat trochu optimálněji. Pro vytunění RAMky někdo používá huge pages, ale považuji to za zbytečné, přesněji řečeno jsem nikdy nenarazil na nějaký test, který by prokazoval zásadní benefit. Jinak co se týká výkonu souborů *.qcow2 vs *.raw, tak ano uvádí se, že raw je rychlejší, ale abys to poznal tak bys musel ve VM provozovat DB, nebo nějaké diskově náročné operace. Každopádně pohrát si u
-drive s parametrem cache=... smysl dává. Z vlastní zkušenosti vím, že se u některého nastavení prodloužil boot Windowsu ve VM na dvojnásobek. U cache=writeback se mi zase začal sekat kurzor myši na hostiteli (Linuxu) když jsem ve VM prováděl kopírování velkého souboru. Pokud se VM přiděluje celý svazek nebo partition (což zřejmě plánuješ ty), tak se většinou používá cache=none. U kombinace ZFS a NVMe někdo zkoušel "vhost_scsi", takže kdyby to byla zrovna tvoje HW kombinace na serveru, tak můžeš zkusit.
Někdo volí raději -machine typu q35 namísto zastaralého, ale stále výchozího i440fx. Taky to může mít vliv na výkon.
Možností pro optimalizace je dost, takže jde o to jak moc jsou dané optimalizace nutné pro danou aplikaci, kterou chceš ve VM Windows provozovat. Pokud ta aplikace nebude zásadně vytěžovat server, tak přehnané optimalizace nedávají smysl.
zere min pametiDá se to vyjádřit nějak číselně? Když přiřadím VM 8GB RAM, tak kolik GB/MB paměti ušetřím když zapnu hugepages?
nemas zdaleka tak casto TLB missTak asi nějaký vliv to má, ale jde o to jestli se tím získá navíc výkon, který je vůbec měřitelný.
PTE jsou 4B pro kazdou 4kB stranku. Nasobit a delit umis, ne?Jestli to u 8GB znamená pár získaných pár MB, tak to je celkem zanedbatelné ušetření RAM. Nějak do detailu hugepages neznám, ale asi větší benefit je, že se menší velikost snáze vejde do cache CPU a tím se sníží latence a věřím, že u DB to význam může mít.
Ja si virtualizuju herni VMTaktéž, a když jsem měřil výkon v 3DMarku s/bez hugepages tak jsem žádný rozdíl neviděl a jelikož bych musel hugepages alokovat při startu VM a uvolnit při vypnutí VM (aby mi hugepages zbytečně nezabíraly RAM), tak jsem se na to vykašlal. Ve tvém prvním odkazu se moc nevyznám. Vidím, že je z roku 2010 a uvádí se tam jednotky nanosekund. Hádám, že u hraní hry by ta latence mohla být max 0.5ms (ale spíše výrazně méně) a jelikož doma nemáme žádného profihráče, tak to neřeším.
bez HP uz jenom ziras, kam se podela veskera pamet.U spotřebované paměti RAM přece musí platit přímá úměra. Tzn. když přidělím VM 8GB RAM, tak bez HP si PTE navíc vezme (dejme tomu) 16MB RAM. Se zapnutými HP by si PTE vzaly z RAM jen 32kB. A když VM přidělím 10x více RAM (80GB) (např. pro Oracle DB), tak by si 10x více paměti měly vzít i PTE. Takže nějak nechápu kam by se měla záhadně spotřebovávat veškerá paměť, tak jak popisuješ.
"jenom na mapovani"Konkrétní čísla co jsem uvedl jsem vzal z linux-kvm.org (6. stránka Cache effect). Při 16GB z RAM se "na mapování" používá 32MB (bez HP) nebo 64KB (s HP). Takže pokud by Oracle měl "jenom na mapování" bez HP použít 100GB, tak by musel Oracle používat 50TB RAM. Pokud Oracle tolik TB RAM nepoužívá, tak si do těch 100GB musí ukládat ještě nějakou vlastní Oracle režii, tzn. že HP nepouužívá jen na mapování virtuální paměti do fyzické paměti, ale funguje to jako nějaká např. DB cache.
Při 16GB z RAM se "na mapování" používá 32MB (bez HP) nebo 64KB (s HP).
a pustime databazovou instanci s tisicem procesu, kde si kazdy proces musi namapovat tech 16GB, protoze je sdili, najednou nebudes potrebovat jenomna mapovani 32MB resp. 64KB, ale celkem 32GB resp. 64MB.
. Myslel jsem, že je jen jedna překladová tabulka pro celý OS.
Zajímalo by mne jestli je ještě pořád aktuální věta o BTRFSJenom tipuju, takže bez záruky, ale obával bych se, že je to dáno architekturou - BTRFS je Copy-On-Write filesystém a image ve formátu qcow je podle jména totéž. Takže když se do toho souboru něco napíše, tak se tam taky musí zapsat metadata (blok je teď umístěn někde), což jsou dva zápisy, načež Btrfs musí udělat totéž jak pro data, tak pro metadata, což už jsou čtyři zápisy. Což by ovšem znamenalo, že když máte SSD, tak si toho varování nejspíš nemusíte moc všímat.
U cache=writeback se mi zase začal sekat kurzor myši na hostiteliNa hraní je to dobré, jinak si ale IIRC koledujete o ztrátu dat. Zatímco host si myslí, že data jsou již uložena na disku, Qemu v tomhle režimu považuje zápis za dokončený, už když se dostane do té cache (tj. k zápisu na disk nikdy nemusí dojít, když např. vypadne proud.)
BTRFS je Copy-On-Write filesystém a image ve formátu qcowNa redditu píší, že to souvisí s COW na BTRFS a při každé změně image VM dochází k velké fragmentaci na disku. Jestli je image VM v qcow2 nebo v raw asi už nezáleží. Vypnutí COW pro adresář ve kterém jsou image VM se zdá jako rozumné řešení.
Na hraní je to dobré, jinak si ale IIRC koledujete o ztrátu dat.Ano, máš pravdu. Je to na zvážení podle důležitosti dat se kterými se pracuje ve VM. Pokud třeba edituješ fotky ve VM a neuložíš si rozdělanou práci a spadne VM nebo hostitel, tak o tu rozdělanou práci (data) stejně přijdeš nehledě na nastavení
cache. Je i nastavení cache=unsafe u kterého jsem pozoroval největší rychlost při bootování VM. Pro desktop je hodnota writeback nebo unsafe v pohodě a u serveru se zase předpokládá záložní zdroj, takže tam je to riziko taky malé.
26.9.2020 15:08
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
I já jsem se chvíli radoval při výpadku sítě, že mám vše jištěné záložním zdrojem, než jsem zjistil, že baterky byly KO a hlásili mi to do emailu ráno před výpadkem.
Tak to je moc.
Tiskni
Sdílej:
