Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Qemu je softvér na virtualizáciu a emuláciu hardvéru. Upozornenie : Autor neručí za prípadné škody použitím týchto informácii. Užívateľ je si vedomi rizik a bude používať informácie z blogu s dostatočnou opatrnosťou a vždy si preverí postup na cvičnom stroji.
Tento blog popisuje používanie virtualizacie QEMU cez príkazový riadok. Dôvod písania tohto blogu je podelenie sa o informácie získane pri používani QEMU cez CLI.
Na jednú vec musím upozorniť a to je kombinácia fs. Neodporúčam kombináciu LVM thin pool s fs ext4 ak máme LVM s fs ext4 vo VM v spojení s qcow2. Pri inštalácii na tejto platforme trvala inštalácia mnohonásobne dlhšie. Preto odporúčam prvotnú inštaláciu systému do VM vo formate obrazu raw.
Podľa dokumentácie stačí na spustenie QEMU obraz disku a zadanie qemu-system-x86_64 obraz.img
. Príkaz spustí virtualizáciu s základným nastavením.
Počet cpu je možne určiť pomocou parametra -smp
. QEMU podporuje funkciu pridania cpu počas chodu VM. Pred spustením musí byť zadefinovaný počet cpu -smp X,maxcpus=y
, ktoré je možne pridať počas chodu. Premenná X definuje počet aktuálne pripojených cpu a premenná Y maximalný počet cpu.
Ďalši krok je pridanie cpu cez QEMU monitor cez príkaz device_add driver=host-x86_64-cpu,socket-id=1,thread-id=0,core-id=0,id=cpu-1
Veľkosť RAM je definovaný v QEMU voľbou -m
.QEMU podporuje aj pridávanie
V prípade potreby pridávania RAM počas chodu VM môžeme definovať množstvo RAM. V definícii ram -m
môžme pridať definiciu počtu slotov a maximálnu veľkosť RAM, pomocou parametrov slots=
maxmem=
.
-object memory-backend-ram,id=id,size=
object_add memory-backend-ram,id=id,size=
Ako posledné musíme vytvoriť zariadenie RAM pomocou QEMU monitora device_add pc-dimm,id=dimm1,memdev=id
.
Podľa dokumentácie QEMU poskytuje tri spôsobi definovania blokového zariadenia.
Schéma ide má konfiguračné voľby hda až hdd,fda,fdb a cdrom
. V princípe stači definovať cieľový súbor alebo zariadenie.
Definícia drive umožňuje detailnejšie nastavenie typu zariadeni v oblasti rozhrania a typu média. V mojom prípade som použil typ rozhrania virtio. Myslím, že tým odstraním obmedzenia jednotlivých rozhrani a zariadenie bude emulované bez špecifických vlastnosti reálnych hw zariadení.
Definícia -blockdev
je najdetailnejšia konfigurácia blokového zariadnia a vyžaduje aj definovanie zariadenia -device
. V prípade blockdev je nutné definovať zdrojový súbor alebo zariadeni kde budú data uložené, jednoznačný identifikátor a typ blokového zariadenia. Následne je nutné definovať paramter drive
v definícii -device
. Ak použijeme format qcow2, tak je nutné vsunuť medzi blockdev a device, definiciu blockdev pre qcow2. V prípade, že je použita bežna definicia pre obrazy vo formate qcow2 dôjde k ohlaseniu chyby o chýbajúcom disku.
virtio-blk je emulácia blokového zariadenia s najjednoduchším rozhraním vzhľadom na komunikáciu medzi hosťovským blokovým zariadením a VM.
Na pripojenie disk cez blokové zariadenie potrebujeme dve definície -device
a -blockdev
. Pre definíciu device musíme vybrať typ zariadeni virtio-blk a názov backendu ku ktorému bude dané zariadenie priradené pomocou parametra drive=
. U definície blockdev musíme vybrať typ blokového zariadenia. Existujú tri druhy file,raw,qcow2. Pre typ file potrebujeme filename=
,node-name=
.
Ak máme obraz disku vo formate qcow2. Musíme vložiť definiciu blokového zariadenia pre qcow2.
virtio-scsi je emulácia zariadenia zbernice SCSI. Princíp komunikácie je v určitej miere pobodný reálnému SCSI. Z toho vyplýva, že mierný pokles výkonu je spôsobený komunikačným protokolom, ktorý pri virtio-blk je len základná komunikácia čítania a zápisu.
Definicia SCSI zariadenia vyžaduje radič a zariadenie alebo viacej zariadení. -device virtio-scsi,id=id
a -device scsi-hd,drive=,device_id=
.
Definovanie zvukového zariadenia je možne urobiť cez -device
a -audiodev
. -device
definuje typ zvukového hw, ktorý má qemu emulovať. -audiodev
definuje výstup smerom z QEMU do systému.
Definovať zvukovú kartu je možné pomocou -device intel-hda,id=sound
. Zatial mám vyskúšanu zvukovú kartu intel-hda. Ak chceme pripojiť do zvuk do hosťovkého systému musíme pridať -device hda-output,audiodev=snd0
a -audiodev pa,id=snd0
.
Pri spustení qemu bez konfigurácie sieťovej karty je prítomne jedno spojenie s vonkajším svetom.
info network
V tomto prípade potrebujeme na správnu funkcie konfiguračne voľby -device
a -netdev
. -device
definuje typ sieťovej karty a niektoré nastavenia. Ak použijeme viace sieťových kariet je vhodné pre každú kartu definovať hw adresu mac=XX:XX:XX:XX:XX:XX
a identifikátor pomocou ktorého zpárujeme použite spojenie s vonkajšim prostredím.
-netdev
umožňuje definovať typ pripojenia k vonkajšiemu svetu.
user
- režim NAT. Pre každú VM je samostatná sieť s NAT do vonkajšieho sveta
socket
- režim umožňujúci pripojenie dvoch a viacerích VM medzi sebou. Socket poskytuje dva režimi TCP a multicast. V prípade TCP je možne vytvoriť. -netdev socket,id=net,listen=127.0.0.1:10001
a -netdev socket,id=net,connect=127.0.0.1:10001
vde
- pripojenie pomocou vde zariadenia. Na úspešne pripojenie je nutné mať vytvorení vdeswitch.
bridge
- pripoji zariadenie tap k zariadeniu bridge na hosťovskom systéme. Hosťovský systému musí mať vytvorené zariadenie bridge aby mohla byť spustená VM. Ak nepovolíme bridge zariadenie v /etc/qemu-bridge.conf
.
V prípade prepojenia VM je nutné definovať pomocou parametra mac
fyzicku adresu sieťovej karty v definícii -device
.
Umožňuje vytvorenie virtualného switchu pre rozhrania VDE. vde_switch -s /tmp/testnet -d
.
Vytvorí virtuálny router medzi VM a hosťovskou sieťou.slirpvde /tmp/testnet -D
.
Parameter -usb
spustí emuláciu USB vo virtualnom stroji.
V prípade pripojenia emulovného USB kľúča je nutné zadefinovať USB zariadenie a blokové zariadenie cez ktoré bude emulovaný USB kľúč pripojený. Definícia USB zariadenia vo VM je nutné zadefinovať cez -device
. Definicia pre radič usb -device qemu-xhci,id=usb
. Definicia pre USB uložisko -device usb-storage,bus=usb.0,drive=stick
. Definicia samotného obsahu uložiska usb -blockdev file,filename=usbstorage.img,node-name=stick
.
Ak chcem pripojiť obraz vo formate qcow2 musime zadefinovať prepojenie medzi -device
a -blockdev
pomocou -device usb-storage,bus=usb.0,drive=stick1
, -blockdev file,filename=usbstorage.img,node-name=stick
, -blockdev qcow2,node-name=stick1,file=stick
.
Použitie emulovaného seriového portu potrebujeme definiciu -device usb-serial,chardev=serialtest
a -chardev vc,id=serialtest
.
Sériový port je typ rozhrania, ktoré bolo v minulosti používane primárne na komunikáciu s modemom a následne s protistranou. Počas zlepšovania techniky Internetu sa začal seriový port používať na pripojenie do internetu cez analogovú linku. Z tohto vyplýva, že seriové rozhranie PC komunikovalo s modemom a následne modem zakódoval data do signálu vhodného na prenos po analogovej linke. Neskór toto rozhranie začalo používať aj u niektorích zariadeniach na konfiguráciu.Existuje množstvo typov seriových rozhrani. RS-232,RS-442,RS-485.
-serial vc
-serial chardev:id
a -chardev vc,id=id
-serial tcp::10000,server=on,wait=off
Štandardné io
- pripojí IO VM k terminálu kde bola spustená VM
Súbor
- výstup seriového rozhrania je zapisaný do definovaného súboru
Virtuálna konzola
- priame zobraznenie komunikácie seriového rozhrania.
Pty
- na pripojenie k pty môžme použiť minicom -D /dev/pts/X
.
Chardev
- pripojá seriové rozhranie do znakového zariadenia s definovaným id. Následne je možné pomocou chardev preposlať komunikáciu rôznými spôsobmi
TCP
- umožni pripojenie sa k seriovému portu pomocou sieťového pripojenia na sieťovom protokole TCP.
UDP
-
QEMU monitor je nástroj virtualizačného prostredia na konfiguráciu VM a monitorovanie niektorích parametrov. Prednadstavené správanie monitora je v prípade textového režimu beh QEMU monitora v stdio a v prípade GUI v režime virtuálnej konzoly. Podobne ako pri seriovom rozhraní je možné QEMU monitor presmerovať rôznými metódami.
V tomto blogu som opísal niektoré možnosti qemu cez CLI. Vzhladom na množstvo času stráveného spisovaním blogu a testovania, ukončujem tento blog. Možno v buducnosti napíšem ďalšie blogy o QEMU.
Tiskni Sdílej:
určitě to jako zkusim ;D
Ešte som sa neodvážil použiť passthrough.
Hm, tak uvidíme - fakt je, že tenhle kus kódu asi nebude prioritou, protože nasazení v datacentrech přece jenom přináší větší peníze. Nasazení umožňující vidět výstup z hosta na hostiteli u domácích uživatelů naopak žádné peníze nepřináší a ještě bych si tipnul, že bude potřeba kromě Qemu taky podpora v ovladači hostitele.To by se dalo říct i o GVT-g a taky tomu někdo věnoval čas.
A jestli to dobře chápu, tak v Qemu vlastně není potřeba řešit nic, se SR-IOV je to normální passthrough.Tak passthrough je i GVT-g. Taky daný počet jader do VM předáš pomocí VFIO nějak takto:
-device vfio-pci,bus=pcie.0,addr=02.0,sysfsdev=/sys/bus/mdev/devices/bd3652a0-387b-3542-689e-e9b189ec5781,display=on,x-igd-opregion=on,ramfb=on,driver=vfio-pci-nohotplug,xres=1440,yres=900,romfile=./win10-gvt-g/vbios_gvt_uefi.rom
a přidání parametru -display gtk,gl=on,zoom-to-fit=off
způsobí, že se zobrazí okno ve kterém půjde vidět zmiňovaný výstup z VM.
Moc nevěřím tomu, že tak jak je to naprogramované pro GVT-g to bude stačit i pro SR-IOV.
Jako zní to pěkně, ale momentálně bych spíš ocenil, kdyby remote-viewer a další podobné dokázaly odchytávat vstupy z klávesnice i v případě, že VM nemá žádný grafický výstup (protože jede čistě na passthrough grafiku.)Já to řeším pomocí evdev, tzn. pomocí parametrů
-device virtio-keyboard-pci
společně s -object input-linux
. Ze všech způsobů co existují se mi to osvědčilo nejlépe.
Tak passthrough je i GVT-g.Jo, ale tohle bylo potřeba dopsat - SR-IOV na grafice Qemu už umí, protože to pokryje normální VFIO.
a přidání parametru -display gtk,gl=on,zoom-to-fit=off způsobí,...že Qemu spadne na segfault ve chvíli, kdy se ta GVT-g grafika nastartuje.
Já to řeším pomocí evdev, tzn. pomocí parametrů -device virtio-keyboard-pci společně s -object input-linux.Jestli to dobře chápu, takhle si proces Qemu zabere klávesnici a vstupy z ní předává do hosta, dokud běží? To můj use-case neřeší, protože občas chci přepnout monitor do hostitelského systému, přepnout se na jiný X server a pracovat s ním.
...že Qemu spadne na segfault ve chvíli, kdy se ta GVT-g grafika nastartuje.To mně nedělalo.
Jestli to dobře chápu, takhle si proces Qemu zabere klávesnici a vstupy z ní předává do hosta, dokud běží?Ne. Mezi hostem a hostitelem můžeš klávesnici (i myš) přehazovat stiskem L-Ctrl + R-Ctrl.
Ne. Mezi hostem a hostitelem můžeš klávesnici (i myš) přehazovat stiskem L-Ctrl + R-Ctrl.Poznamenal jsem si, dík. Zatím budu doufat, že ten spicec nepřestane fungovat, tohle kdyžtak může být záložní plán v případě, že přestane (hádám, že instalace v téhle konfiguraci nebude úplně triviální, když na klávesnici a myš je potřeba ovladač, ale nainstalovat ho nepůjde, protože nemám ovladač) Ideální stav by byl wishlist bug na ten remote-viewer, ale k tomu se musím nejdřív dostat
hádám, že instalace v téhle konfiguraci nebude úplně triviální, když na klávesnici a myš je potřeba ovladač, ale nainstalovat ho nepůjde, protože nemám ovladačJá myslím, že to je celkem triviální. Jen musíš: - přidat do Qemu parametry
-object input-linux,evdev=/dev/input/by-id/<název klávesnice>,grab_all=on,repeat=on
a -device virtio-keyboard-pci
(Oba parametry i pro myš)
- přidat oprávnění do /etc/udev/rules.d/10-qemu-hw-users.rules
- ve VM Windows nainstalovat ovladač "virtio input" (v Linuxu netřeba instalovat, protože je součástí kernelu)
Na internetu je spousta návodů. Pak je ještě možnost použít Barrier (fork Synergy)
Ideální stav by byl wishlist bug na ten remote-viewer, ale k tomu se musím nejdřív dostatNepřipadá mi jako správné řešení používat remote-viewer (spicec) společně s VGA passthrough. Předpokládám, že spicec ti ukazuje černou obrazovku a používáš ho jen k předání myši a klávesnice. To je spíše hack než správné řešení. Když už by mělo být nějaké jednoduché řešení pro naklikání konfigurace předání myši a klávesnice, tak by to mělo být součástí virt-manageru, nikoliv remote-vieweru.
Nepřipadá mi jako správné řešení používat remote-viewer (spicec) společně s VGA passthrough....i když zase na druhou stranu proč by přes spice protokol nemohly téct jen data z klávesnice a myši. To je taky pravda.
vůbec mi nedává smysl, proč všechny klientské programy pro SPICE protokol (kromě toho spiccec), na základě toho, že ve VM nenajdou grafický výstup, vypnou veškerou svoji zbývající funkcionalitu.Napadá mne ten smysl, že když ve spicec nevidíš grafický výstup a přesto funguje předávání vstupů z klávesnice a myši, tak by to mohlo být docela matoucí, protože bez grafického výstupu to vypadá, že k navázání spojení nedošlo, ale přesto by docházelo k předávání vstupů z klávesnice a ty bys nevěděl a neviděl, že ovládáš vzdálený počítač ke kterému jsi přes SPICE připojený. A jak to teda funguje na spicec při passthrough? Vidíš černou obrazovku nebo místo černé obrazovky je varování, že obraz se sice nepřenáší, ale vstupy z klávesnice ano?
protože bez grafického výstupu to vypadá, že k navázání spojení nedošloNevypadá, když k navázání spojení nedojde, vyhodí to chybovou hlášku a ukončí se to.
A jak to teda funguje na spicec při passthrough?Černé okno, kurzor se v něm přepne na nekliknutelný (nebo jak se to jmenuje, prostě křížek). Klávesová zkratka na přepnutí do fullscreen pořád funguje. A jinak stejně jako u VNC klientů, dokud to okno má focus a kurzor myši je v něm, tak bere všechny klávesové vstupy, které může (ctrl-alt-Fx na přepnutí X konzole třeba sebrat a předat do hosta nedokáže)
Ale připadá mi to už škrabání pravou rukou za levým uchem přidávat další GPU do VM jen kvůli předání vstupů.Přesně tak, proto za nejvíc přímočaré řešení považuju to, co jsem psal - aby SPICE klient ignoroval absenci displaye a vstupy předával i bez něj. Plus ve widlích to ještě AFAIK funguje s více grafikami nějak divně, něco jako že výpočty dělá jen jedna a ostatní slouží jen jako zobrazovače - tj. když se to blbě poskládá, passthrough grafika jede s výkonem té virtuální. Dokonce mám pocit, že jsem to i zkoušel a výsledek byl nic moc.
A jinak stejně jako u VNC klientů, dokud to okno má focus a kurzor myši je v něm, tak bere všechny klávesové vstupyJá jsem ti na to napsal, že aby ti VNC fungovalo, tak potřebuješ mít na vzdálené ploše nainstalovanou GPU (alespoň falešnou - xf86-video-dummy). Takže pokud chceš, aby SPICE fungovalo podobně jako VNC, tak i na vzdálené ploše kam se napojuješ přes SPICE musí být GPU, kterou SPICE vidí (např. qxl).
aby SPICE klient ignoroval absenci displaye a vstupy předával i bez něj.Nevím co myslíš tím displayem. SPICE potřebuje virtuální GPU (qxl) a pak SPICE clienta (remote-viewer, spicec ...), který zobrazuje grafický výstup z qxl. Takže předpokládám, že tím displayem myslíš právě tu virtuální GPU (qxl). To je právě to na co jsem narážel výše. VNC neumí fungovat bez GPU, tak proč to chtít po SPICE?
(alespoň falešnou - xf86-video-dummy)Jen pro upřesnění: xf86-video-dummy byl příklad při napojování do fyzického serveru a netýká se to napojování VNC do Qemu. Ale u Qemu platí určitě to samé tzn. aby ses mohl pomocí VNC klienta napojit do Qemu, tak v Qemu musí být nastavená nějaká virtuální GPU.
Já jsem ti na to napsal, že aby ti VNC fungovalo, tak potřebuješ mít na vzdálené ploše nainstalovanou GPU (alespoň falešnou - xf86-video-dummy).A přesně na to jsem psal to "houbeles" Ale jinak po tom doplnění máte pravdu - mluvím o propojení VNC klienta pro Qemu obecně, tam žádný X server potřeba není.
Ale u Qemu platí určitě to samé tzn. aby ses mohl pomocí VNC klienta napojit do Qemu, tak v Qemu musí být nastavená nějaká virtuální GPU.Nemusí. Nebude to nic ukazovat, ale napojit se jde. (I když co jsem teď otestoval, chová se to stejně jako moderní SPICE klienty, tj. nepředává vstupy.)
Nevím co myslíš tím displayem. SPICE potřebuje virtuální GPU (qxl) a pak SPICE clienta (remote-viewer, spicec ...), který zobrazuje grafický výstup z qxl.Už jsme to řešili vejš. Nepotřebuje. Mám stroj, který nemá virtuální GPU, mám SPICE klienta (spicec), vstupy jsou předávány do Qemu, výstup z Qemu předáván není, protože neexistuje. Ano, ten SPICE klient pak neukazuje žádný obraz, to po něm ovšem v dané konfiguraci nikdo nechce.
Ale u Qemu platí určitě to samé tzn. aby ses mohl pomocí VNC klienta napojit do Qemu, tak v Qemu musí být nastavená nějaká virtuální GPU.Když spustím VM bez virtuální GPU, tak se i s remote-viewerem dokážu napojit, akorát, že místo grafického výstupu vypisuje nápis "Připojeno ke grafickému serveru" a jak správně píšeš nepředává to vstupy. Takže podtrženo sečteno: SPICE klienti, ani VNC klienti nedokáží předávat vstupy z klávesnice a myši do VM když daná VM nemá nastavenu GPU. Jediná výjimka je spicec. Když bych do toho chtěl dál štourat, tak spicec má volby:Nemusí. Nebude to nic ukazovat, ale napojit se jde. (I když co jsem teď otestoval, chová se to stejně jako moderní SPICE klienty, tj. nepředává vstupy.)
--enable-channels <ch0, ch1...> Enable the specified channels. Use “all” for enabling all possible channels. Use the following names for enabling only the selected channels: “display”, “inputs”, “cursor”, “playback” and “record”. By default all channels are enabled. --disable-channels <ch0, ch1...> Disable the specified channels. Use “all” for disabling all possible channels. Use the following names for enabling only the selected channels: “display”, “inputs”, “cursor”, “playback” and “record.” By default all channels are enabled.Remote-viewer má také volbu:
"disable-channels" (string list) The list of session channels to disable. The current SPICE channels are: main, display, inputs, cursor, playback, record, smartcard, usbredir.Ale když si v terminálu zobrazím nápovědu
remote-viewer --help-all
tak to volbu --spice-disable-channels
neukazuje.
Takže jen taková spekulace: Není to třeba tak, že i remote-viewer umí fungovat podobně jako spicec, akorát že remote-viewer není zkompilovaný s patřičnou volbou?
Takže jen taková spekulace: Není to třeba tak, že i remote-viewer umí fungovat podobně jako spicec, akorát že remote-viewer není zkompilovaný s patřičnou volbou?Kdo ví? Zkus parametr
--help-spice
, jak to má spicy. To jsi mimochodem nezkoušel?
remote-viewer --debug ... ... (remote-viewer:6602): virt-viewer-DEBUG: 23:21:34.934: FIXME: disable-channels is not supported atm
-enable-kvm
.
Na jednú vec musím upozorniť a to je kombinácia fs. Neodporúčam kombináciu LVM thin pool s fs ext4 ak máme LVM s fs ext4 vo VM v spojení s qcow2. Pri inštalácii na tejto platforme trvala inštalácia mnohonásobne dlhšie. Preto odporúčam prvotnú inštaláciu systému do VM vo formate obrazu raw.Jasně, protože je to v podstatě COW nad COW. Proto se pro QCOW2 moc nehodí ani BTRFS. Též je potřeba si dát pozor na FS uvnitř toho vmka, mít tam btrfs, vmko qcow2 na btrfs, to by bylo hodně pomalé. Asi nejlepší je mít vmka nad LV v LVM, nebo jako raw soubory na fs starého typu (xfs, ext4). Nebo nad ZFS ZVOL. Atd.
Zrovna to teď řeším. V pc mám NVMe rozdělené na 3 oddíly. EFI, 200 GB pro OS (LUKS, Btrfs) a 800 GB pro /data (LUKS, Btrfs). Adresář s qcow.2 mám na /data. Stačilo by oddíl /data zmenšit a za ním vytvořit nový oddíl pro qcow.2 (LUKS, ext4)?
Používám 2 VM. Mint (ext4), takže ten by pak měl být v pohodě a Windows 10. Ty Windows bych chtěl upgradovat na verzi 11. MS tool mi oznámil, že to nepůjde. Problém je v tom, že ten VM používá BIOS místo UEFI. Půjde to nějak předělat? A taky tam nemám GPU. To taky brání upgradu. Passthrough GPU zatím udělat nemůžu, protože v pc mám zatím jen jednu. To by šlo nějak hacknout? Neřešil jsi to/nevíš?
Ještě koukám, že pro ext4 radíš raw. Takže by asi bylo nejlepší oba ty VM vytvořit znovu, že?
Jak to teď máš?
Jinak, než jsem myslel. Btrfs > qcow2 > Btrfs. Takže VM není nad ext4, ale taky nad Btrfs. Pomalé mi to ale nepřipadá. Zkusil jsem rebootnout VM a reboot plocha > plocha = ~17s. NVMe má r/w 5GBps/4,4GBps. Při kopírování velkého objemu dat ta rychlost sice degraduje, ale na běžný provoz je to celkem rychlé.
Ten pokles rychlosti je jediným problémem? Někde jsem tu s LarryL(em) řešil problém qcow2 a Btrfs, ale nebyl to můj dotaz a těžko bych to teď hledal. Už si právě nepamatuji, o co tam tenkrát šlo. Každopádně když budu spokojený s rychlostí, tak to řešit nemusím?
Zkusil jsem rebootnout VM a reboot plocha > plocha = ~17s.Kolik máš RAM? Na svým pecku mám boot do W10 do 15s. Na virtuálce, pokud je to celé nacachované v ram, je to skoro hned. Ale tohle měření nic neznamená. On tam detekuje HW apod. 17s je naprosto OK.
Ten pokles rychlostiJe to složitější. COW znamená copy on write. To znamená, že každá kopie (každý zápis na stejné místo) se uloží někam jinam (copy on write doslova znamená: přečíst, změnit, uložit jinam).
je jediným problémemOn to není problém per se. COW zdvojnásobuje přepis na daném zařízení. Takže se to rychleji opotřebuje. Pokud ale vmko umístíš na nocow, tak se jednoho přepisu zbavíš.
Každopádně když budu spokojený s rychlostí, tak to řešit nemusím?Ano. A potom to můžeš zoptimalizovat. Co máš za HW. Nevšiml jsem si (moje chyba), že sis to koupil. Zajímá mě to, protože kdy upgrade na poslední zen3. Co máš ty?
Kolik máš RAM?
V pc 32 GB, každému VM jsem přidělil 4 GB.
Seznam hw přikládám.
Koukám, že místy je z toho rozsypaný čaj, ale odkazy by měly fungovat. Případně vždy ten spodní odkaz.
Zkusím to dát ještě sem:
MB
ASRock: B550 Steel Legend
Heureka: ASRock B550 Steel Legend
PSU
Corsair: RMx Series™ RM650x
Heureka: Corsair RMx Series RM650x 650W CP-9020178-EU
CPU
AMD: Ryzen™ 7 5800X Desktop Processors
Heureka: AMD Ryzen 7 5800X 100-100000063WOF
Chladič
Noctua: NH-D15S
Heureka: Noctua NH-D15S
RAM (2 ks)
Kingston: KSM26ED8/16ME
Heureka: Kingston KSM26ED8/16ME
NVMe
GIGABYTE: AORUS Gen4 SSD 1TB
Heureka: GIGABYTE AORUS Gen4 1TB, GP-AG41TB
HDD
Western Digital: WD_BLACK™ Performance Desktop Hard Drive 4TB
Heureka: WD 4TB, SATA3 6Gbps, WD4005FZBX
GPU
AMD (HP neuvádí): AMD Radeon™ Pro W5500 Graphics Card
Heureka: HP Radeon Pro W5500 8GB GDDR6 9GC16AA
Skříň
Fractal Design: Define XL R2
Heureka: Fractal Design Define XL R2 FD-CA-DEF-XL-R2-BL
Trackball
Kensington: Kabelový trackball Kensington Orbit™ s kroužkem Scroll Ring No. K72337EU
Heureka: Kensington K72337EU
Klávesnice
C-Tech: Doména je zaregistrována!
Heureka: C-Tech Scorpia V2 GKB-119
Mechanika
LG: Přehled mechanik, daný model výrobce momentálně na svém webu nemá.
Heureka: Hitachi-LG GP60N
Monitor
Philips: HDR displej 4K s technologií Ambiglow 436M6VBPAB/00
Heureka: Philips 436M6VBPAB
Nemáš zač.
Ještě jsem se díval, bavíme se o Zen3, že oba R9 mají oproti R7 2x větší L3 cache. A i 5950X má oproti 5900X větší L1 a L2 cache. V čem se to v reálu projevuje? Možná bych se řídil i tím. Ne jen počtem jader a frekvencemi.
Díky za vysvětlení
Projevuje se to u výpočtů, kde procesor čeká na paměť.
A jak poznám, že CPU čeká na paměť?
…, tak jsem potupně nastavil swap.Swap rozhodně není přežitek, pokud alespoň někdy pracuješ s velkými souboru, nebo když virtualizuješ stroje, co vyžadují hodně paměti.
O virtualizaci na swapu se ani bavit nebudu. Jasně, jako těžká nouzovka, pokud potřebuješ něco rozjet, tak OK, ale pro provoz ne.Tady nejde o to, že bys se ten swap reálně používal. Vtip je v tom, že ti dovolí ošálit virtualizovaný systém. Díky tomu umím spustit virtualizované MS Windows s 1TB virtuálním diskem a 50GB RAM na stroji co má reálně 8G RAM a 120GB SSD a dá se na nich vzdáleně pracovat přes virtualizovanou plochu připojenou před Spice.
Proč jsi tam dal jen 32GB RAM? Cena nebo aktuálně víc nepotřebuješ?
Nepotřebuji. I tak už to mám docela naddimenzované.
Jen pro zajímavost:
Kolik máš RAM? Na svým pecku mám boot do W10 do 15s. Na virtuálce, pokud je to celé nacachované v ram, je to skoro hned. Ale tohle měření nic neznamená. On tam detekuje HW apod. 17s je naprosto OK.
Tak jsem dal na ten bindnutý adresář qemu_kvm chattr +C
a reboot plocha > plocha trvá stále ~17 s.
Stačilo by oddíl /data zmenšit a za ním vytvořit nový oddíl pro qcow.2 (LUKS, ext4)?Mělo by stačit nastavit příznak nocow příkazem:
chattr +C
na daný (v tuto chvíli prázdný) adresář. To vypne COW v BTRFS pro daný adresář a soubory v něm. Je to rychlejší, ale na XFS to nemá. (Ale před případnou změnou FS doporučuji otestovat, na NVMe to bude rychlé a vůbec nebude potřeba měnit FS.)
Ty Windows bych chtěl upgradovat na verzi 11. MS tool mi oznámil, že to nepůjde. Problém je v tom, že ten VM používá BIOS místo UEFI.Ano, Win11 potřebují UEFI. Převáděl jsem takto W10 (na fyzickém stroji). Ještě jsem to neupgradoval na W11 (jde to, ale snad zítra / víkend).
A taky tam nemám GPU. To taky brání upgradu. Passthrough GPU zatím udělat nemůžu, protože v pc mám zatím jen jednu. To by šlo nějak hacknout? Neřešil jsi to/nevíš?To nevím. Na virtuálce jsem zatím na W11 neupgradoval. Kolega je má na pecku a tam to šlo hodně rychle W10-W11 asi během 40minut. Krom vzhledu žádná zásadní změna, vše mu fungovalo (dokonce si nechal otevřených asi 40 programů , vše prošlo).
Díky za odkaz.
S tím převodem jsem se špatně vyjádřil. Já měl na mysli, jestli to půjde nějak přepnout v QEMU/Virt manageru? Používám i440FX BIOS.
Mělo by stačit nastavit příznak nocow příkazem: chattr +C na daný (v tuto chvíli prázdný) adresář. To vypne COW v BTRFS pro daný adresář a soubory v něm.QEMU/KVM si defaultně ukládá obrazy do /var. Já je ale mám v /data a ve fstab mám:
/data/data_giga/qemu_kvm /var/lib/libvirt/images none bind,x-gvfs-hide 0 0
Na který adresář(e) mám prosím tě chattr +C
aplikovat?
Já bych řekl, že jenom na ten qemu_kvm
Díky za zápis.