<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Kvm on Morfitronik</title>
    <link>https://morfikov.github.io/tags/kvm/</link>
    <description>Recent content in Kvm on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Fri, 27 Aug 2021 22:26:00 +0200</lastBuildDate><atom:link href="https://morfikov.github.io/tags/kvm/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak odblokować bootloader w Xiaomi Redmi 9 (galahad/lancelot)</title>
      <link>https://morfikov.github.io/post/jak-odblokowac-bootloader-w-xiaomi-redmi-9-galahad-lancelot/</link>
      <pubDate>Fri, 27 Aug 2021 22:26:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-odblokowac-bootloader-w-xiaomi-redmi-9-galahad-lancelot/</guid>
      <description>&lt;p&gt;Jakiś czas temu wpadł w moje łapki smartfon Xiaomi Redmi 9 (galahad albo lancelot, bo w różnych
częściach systemu jest to inaczej określone), który miał preinstalowanego Androida 10 oraz MIUI 11.
Przez parę miesięcy używania telefonu, dostał on dwa albo trzy większe update całego ROM&#39;u,
wliczając w to aktualizację MIUI do 12.0.1 ze stanem zabezpieczeń na dzień 2021-01-05. Zatem
ostatnia aktualizacja zabezpieczeń tego telefonu miała miejsce zaraz na początku Stycznia. Od tego
czasu cisza. Niby w przypadku tego modelu telefonu aktualizacje miały być wydawane &lt;a href=&#34;https://www.mi.com/global/service/support/security-update-1.html&#34;&gt;co trzy
miesiące do roku 2023&lt;/a&gt; ale najwyraźniej coś jest nie tak i urządzenie od ponad pół roku nie
dostało żadnych aktualizacji. Niby pod tym linkiem można wyczytać informację, że planowana jest
aktualizacja do Androida 11 ale prawdę mówiąc jestem nieco zawiedziony opieszałością Xiaomi. Tak
się złożyło, że przez przypadek trafiłem w &lt;a href=&#34;https://forum.xda-developers.com/f/redmi-9-poco-m2-roms-kernels-recoveries-dev.11175/&#34;&gt;to miejsce na forum XDA&lt;/a&gt;, gdzie z kolei znalazłem
m.in. &lt;a href=&#34;https://forum.xda-developers.com/t/rom-unofficial-11-0-pixel-plus-ui-for-redmi-9-lancelot-galahad.4243813/&#34;&gt;ten wątek&lt;/a&gt;. Zatem alternatywne ROM&#39;y na mój smartfon istnieją i tego faktu nie byłem
świadomy, bo w zeszłym roku jeszcze nic nie szło znaleźć. Postanowiłem zatem odblokować bootloader
w swoim Xiaomi Redmi 9 i spróbować wgrać na niego TWRP i jeden (a może nawet kilka) przykładowy ROM
na bazie AOSP/LineageOS. Proces odblokowania bootloader&#39;a w urządzeniach Xiaomi nie wymaga zbytnio
wysiłku i da się go przeprowadzić w całości pod linux korzystając czy to z XiaoMiTool, czy też przy
pomocy &lt;a href=&#34;https://morfikov.github.io/post/wirtualizacja-qemu-kvm-libvirt-na-debian-linux/&#34;&gt;maszyn wirtualnych na bazie QEMU/KVM&lt;/a&gt;. Ten proces nie do końca jest dla każdego taki
oczywisty, dlatego postanowiłem go dokładnie opisać.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Aktualizacja firmware drukarki HP LaserJet P2055dn pod linux</title>
      <link>https://morfikov.github.io/post/aktualizacja-firmware-drukarki-hp-laserjet-p2055dn-pod-linux/</link>
      <pubDate>Wed, 27 Jan 2021 19:10:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/aktualizacja-firmware-drukarki-hp-laserjet-p2055dn-pod-linux/</guid>
      <description>&lt;p&gt;Bawiąc się ostatnio drukarką laserową Hewlett Packard (HP) LaserJet P2055dn, zauważyłem, że ma ona
wgrany dość stary firmware. Naturalnie sama drukarka do najmłodszych nie należy, bo została
wyprodukowana w 2011 roku ale skoro na stronie producenta jest dostępna nowsza wersja
oprogramowania dla tego urządzenia, to przydałoby się je do tej drukarki wgrać. Problem jednak
pojawia się w przypadku takich osób jak ja, tj. tych, które korzystają w swoim środowisku pracy z
maszyn mających na pokładzie system operacyjny z rodziny jakieś dystrybucji linux&#39;a, np. Debian czy
Ubuntu. Producent drukarki udostępnia stosowne narzędzia do aktualizacji firmware ale tylko i
wyłącznie dla OS z gatunku Windows. Co mają zrobić osoby, które z Windows&#39;a nie korzystają, a
chciałyby przy tym mieć aktualny firmware w drukarkach HP? Możemy spróbować postawić maszynę
wirtualną na bazie QEMU/KVM, tam zainstalować Windows&#39;a i udostępnić w obrębie tej maszyny
wirtualnej drukarkę, której firmware mamy zamiar aktualizować.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Zastosowanie KSM w maszynach wirtualnych QEMU/KVM</title>
      <link>https://morfikov.github.io/post/zastosowanie-ksm-w-maszynach-wirtualnych-qemu-kvm/</link>
      <pubDate>Sun, 18 Oct 2020 10:45:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/zastosowanie-ksm-w-maszynach-wirtualnych-qemu-kvm/</guid>
      <description>&lt;p&gt;Użytkownicy linux&#39;a, którzy korzystają z &lt;a href=&#34;https://morfikov.github.io/post/wirtualizacja-qemu-kvm-libvirt-na-debian-linux/&#34;&gt;mechanizmu wirtualizacji QEMU/KVM&lt;/a&gt;, wiedzą, że takie
maszyny wirtualne potrafią zjadać dość sporo pamięci operacyjnej. Im więcej takich maszyn zostanie
uruchomionych w obrębie danego hosta, tym większe ryzyko, że nam tego RAM&#39;u zwyczajnie zabraknie.
Można oczywiście ratować się dokupieniem dodatkowych modułów pamięci ale też nie zawsze taki zabieg
będzie możliwy, zwłaszcza w przypadku domowych stacji roboczych pokroju desktop/laptop. Szukając
rozwiązania tego problemu natrafiłem na coś, co nazywa się Kernel Samepage Merging. W skrócie, KSM
to mechanizm, który ma na celu współdzielenie takich samych stron pamięci operacyjnej przez kilka
procesów. W ten sposób można (przynajmniej teoretycznie) dość znacznie obniżyć zużycie RAM,
zwłaszcza w przypadku korzystania na maszynach wirtualnych z tych samych systemów operacyjnych.
Przydałoby się zatem ocenić jak bardzo KSM wpłynie na wykorzystanie pamięci i czy będzie z niego
jakiś większy użytek zarówno przy korzystaniu z maszyn wirtualnych, czy też w codziennym użytkowaniu
komputera.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak zmienić rozmiar obrazu maszyny wirtualnej QEMU/KVM</title>
      <link>https://morfikov.github.io/post/jak-zmienic-rozmiar-obrazu-maszyny-wirtualnej-qemu-kvm/</link>
      <pubDate>Sun, 09 Aug 2020 13:45:00 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-zmienic-rozmiar-obrazu-maszyny-wirtualnej-qemu-kvm/</guid>
      <description>&lt;p&gt;Bawiąc się ostatnio &lt;a href=&#34;https://morfikov.github.io/post/wirtualizacja-qemu-kvm-libvirt-na-debian-linux/&#34;&gt;maszynami wirtualnymi na bazie QEMU/KVM&lt;/a&gt;, zauważyłem, że sugerowany rozmiar
pliku &lt;code&gt;.qcow2&lt;/code&gt; waha się w okolicach 25 GiB. Nie jest to może jakoś specjalnie dużo ale mało to też
nie jest, zwłaszcza jeśli tworzymy maszyny wirtualne na dysku swojego laptopa. Co jeśli
przeholowaliśmy z szacunkami co do rozmiaru takiego obrazu i po zainstalowaniu systemu operacyjnego
gościa okazało się, że w sumie to ten obraz można by zmniejszyć o połowę? Albo też i w drugą stronę,
tj. co w przypadku, gdy stworzony obraz maszyny wirtualnej okazał się zbyt mały i teraz zachodzi
potrzeba jego powiększenia? Czy w takiej sytuacji musimy na nowo tworzyć maszynę wirtualną
odpowiednio zwiększając lub zmniejszając jej przestrzeń na pliki? A może istnieje jakiś sposób na
zmianę rozmiaru tych istniejących już obrazów maszyn wirtualnych? Postaramy się ten fakt
zweryfikować, a cały proces zostanie opisany przy wykorzystaniu systemu Debian Linux.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Konfiguracja HugePages pod maszyny wirtualne QEMU/KVM</title>
      <link>https://morfikov.github.io/post/konfiguracja-hugepages-pod-maszyny-wirtualne-qemu-kvm/</link>
      <pubDate>Sun, 09 Aug 2020 11:11:00 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/konfiguracja-hugepages-pod-maszyny-wirtualne-qemu-kvm/</guid>
      <description>&lt;p&gt;W linux rozmiar stron pamięci operacyjnej RAM ma domyślnie 4096 bajtów (4 KiB). Maszyny wirtualne
QEMU/KVM mają to do siebie, że wykorzystują dość spore zasoby pamięci (wile GiB), przez co mały
rozmiar strony może niekorzystnie wpływać na wydajność systemów gościa. Chodzi generalnie o to, że
rozrostowi ulega tablica stron, której przeszukiwanie jest czasochłonną operacją. By temu zaradzić,
wymyślono TLB (&lt;a href=&#34;https://en.wikipedia.org/wiki/Translation_lookaside_buffer&#34;&gt;Translation Lookaside Buffer&lt;/a&gt;), który ulokowany jest albo w CPU albo gdzieś
pomiędzy CPU i główną pamięcią operacyjną. TLB to mały ale za to bardzo szybki cache. W przypadku
systemów z duża ilością pamięci RAM, niewielki rozmiar TLB sprawia, że odpowiedzi na zapytania nie
są brane z cache, tylko system wraca do przeszukiwania normalnej tablicy stron zlokalizowanej w
pamięci RAM (TLB miss). Taka sytuacja jest bardzo kosztowna, spowalnia cały system i dlatego trzeba
jej unikać. Na szczęście jest &lt;a href=&#34;https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt&#34;&gt;mechanizm HugePages&lt;/a&gt;, który pozwala na zwiększenie rozmiaru
strony pamięci z domyślnych 4 KiB do 2 MiB lub nawet do 1 GiB w zależności od właściwości głównego
procesora. W tym artykule postaramy się skonfigurować HugePages na potrzeby maszyn wirtualnych dla
systemu Debian Linux.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Wirtualizacja QEMU/KVM (libvirt) na Debian Linux</title>
      <link>https://morfikov.github.io/post/wirtualizacja-qemu-kvm-libvirt-na-debian-linux/</link>
      <pubDate>Sat, 08 Aug 2020 14:55:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/wirtualizacja-qemu-kvm-libvirt-na-debian-linux/</guid>
      <description>&lt;p&gt;Prawdopodobnie dla większości użytkowników linux&#39;a, wirtualizacja kojarzy się w zasadzie z jednym
oprogramowaniem, tj. VirtualBox. &lt;a href=&#34;https://www.virtualbox.org/&#34;&gt;Niby strona VBox&#39;a podaje, że jest on na licencji GPL-2&lt;/a&gt; ale
w Debianie nie ma go w głównym repozytorium (jest on obecny w sekcji &lt;code&gt;contrib&lt;/code&gt; ). Problem z
VirtualBox&#39;em jest taki, że &lt;a href=&#34;https://salsa.debian.org/pkg-virtualbox-team/virtualbox/-/blob/master/debian/copyright&#34;&gt;wymaga on kompilatora Open Watcom&lt;/a&gt;, który już wolnym
oprogramowaniem nie jest. VBox też nie jest jedynym oprogramowaniem, które na linux można
wykorzystać w roli hiperwizora do obsługi maszyn wirtualnych. Jest o wiele lepsze rozwiązanie,
mianowicie QEMU, które jest w stanie zrobić użytek z maszyny wirtualnej kernela (Kernel Virtual
Machine, KVM) i realizować dokładnie to samo zadanie, które zwykł ogarniać VirtualBox.
Wirtualizacja na bazie QEMU/KVM jest w pełni OpenSource, co ucieszy pewnie fanów wolnego i
otwartego oprogramowania, choć zarządzanie maszynami wirtualnymi odbywa się za sprawą konsoli.
Oczywiście, osoby które korzystają z VirtualBox&#39;a zdają sobie sprawę, że to narzędzie oferuje
graficzny menadżer maszyn wirtualnych (Virtual Machine Manager, VMM), który usprawnia i znacznie
ułatwia zarządzanie wirtualnymi maszynami. Jeśli GUI jest dla nas ważnym elementem środowiska pracy
i nie uśmiecha nam się konfigurować maszyn wirtualnych przy pomocy terminala, to jest i dobra
wiadomość dla takich osób, bo istnieje &lt;code&gt;virt-manager&lt;/code&gt; , który jest dość rozbudowanym menadżerem
maszyn wirtualnych pozwalającym na ich tworzenie, konfigurowanie i zarządzanie nimi przy
wykorzystaniu graficznego interfejsu użytkownika. W tym artykule postaramy się skonfigurować
naszego Debiana w taki sposób, by przygotować go do pracy z maszynami wirtualnymi posługując się
&lt;code&gt;qemu&lt;/code&gt;/&lt;code&gt;libvirt&lt;/code&gt;/&lt;code&gt;virt-manager&lt;/code&gt; .&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
