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í
×
    dnes 04:33 | IT novinky

    Společnost Teufel nedávno představila svůj první open source Bluetooth reproduktor MYND.

    Ladislav Hagara | Komentářů: 0
    včera 20:00 | Nová verze

    Byla vydána verze 4.2 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.

    Ladislav Hagara | Komentářů: 0
    včera 19:33 | IT novinky

    Anton Carniaux, právní zástupce Microsoft France, pod přísahou: Microsoft nemůže garantovat, že data z EU nepředá do USA bez EU souhlasu, musí dodržovat americké zákony.

    Ladislav Hagara | Komentářů: 4
    včera 15:33 | Nová verze

    Byl vydán Mozilla Firefox 141.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Lokální AI umí uspořádat podobné panely do skupin. Firefox na Linuxu využívá méně paměti. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 141 je již k dispozici také na Flathubu a Snapcraftu.

    Ladislav Hagara | Komentářů: 0
    21.7. 22:44 | Bezpečnostní upozornění

    NÚKIB upozorňuje na kritickou zranitelnost v SharePointu. Jedná se o kritickou zranitelnost typu RCE (remote code execution) – CVE-2025-53770, která umožňuje neautentizovaný vzdálený přístup a spuštění kódu, což může vést k úplnému převzetí kontroly nad serverem. Zranitelné verze jsou pouze on-premise verze a to konkrétně SharePoint Server 2016, 2019 a Subscription Edition. SharePoint Online (Microsoft 365) není touto zranitelností ohrožen.

    Ladislav Hagara | Komentářů: 3
    21.7. 21:00 | IT novinky

    Společnost Valve zpřísnila pravidla pro obsah, který je možné distribuovat ve službě Steam. Současně řadu her ze Steamu odstranila. V zásadách a pravidlech přibylo omezení 15: Obsah, který by mohl porušovat pravidla a normy stanovené zpracovateli plateb a souvisejícími sítěmi platebních karet a bankami nebo poskytovateli připojení k internetu. Sem spadají zejména určité druhy obsahu pouze pro dospělé.

    Ladislav Hagara | Komentářů: 0
    21.7. 13:33 | Komunita

    Dle analytics.usa.gov je za posledních 90 dnů 6,2 % přístupů k webových stránkám a aplikacím federální vlády Spojených států z Linuxu.

    Ladislav Hagara | Komentářů: 0
    20.7. 17:44 | Zajímavý článek

    Jak si zobrazit pomocí Chrome a na Chromiu založených webových prohlížečích stránky s neplatným certifikátem? Stačí napsat thisisunsafe.

    Ladislav Hagara | Komentářů: 3
    20.7. 00:33 | Bezpečnostní upozornění

    V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.

    Ladislav Hagara | Komentářů: 15
    20.7. 00:22 | Komunita

    Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.

    Ladislav Hagara | Komentářů: 1
    Kolik tabů máte standardně otevřeno ve web prohlížeči?
     (27%)
     (25%)
     (4%)
     (6%)
     (5%)
     (2%)
     (4%)
     (27%)
    Celkem 81 hlasů
     Komentářů: 11, poslední včera 20:35
    Rozcestník

    Zálohování KVM virtuálů

    16.8.2013 09:40 | Přečteno: 2316× | Výběrový blog

    Mám už několik produkčních hostů, všichni jsou typu qemu plná virtualizace s HW podporou, s image ve formátu qcow2 a jsou na cLVM svazcích. Hledal jsem, jak je efektivně zálohovat.

    Úvodem bych poznamenal, že zacházení s LVM svazky je trochu míň pohodlné než by bylo zacházení s image ve formě souborů. Jenže když mám image jako soubor, je přístup virtuálního hosta na disk o desítky procent pomalejší než ke stejnému disku přímo od hmotného hostitele. To jsem zjistil už před pár lety na XEN virtuálech a ověřil jsem, že to teď platí i pro KVM virtuály. Asi to bude tím, že když chce host něco udělat s n-tým diskovým blokem, vytvoří system call, ten dostane jádro hostitele a teď musí proběhnout seek v souborových službách hostitele. Oproti tomu LVM jde přímo na bloky.

    Nejasně jsem tušil, že správná záloha image znamená udělat snapshot image a ten nějak zazálohovat a poté smazat tak, aby se image běžícího hosta o ničem nedozvěděl. Moji hosté byli vytvořeni pomocí virt-install, takže k tvorbě a zpracování snapshotů máme na výběr qemu snapshoty třeba podle návodu tady, nebo virtlib snapshoty podle Kashyapa. Zkoušel jsem to oboje a podle určitých drobných rozdílností v chování bych hádal, že virtlib má svoje vlastní metody, jak zacházet se snapshoty, i když v podstatě musí používat stejné KVM konstrukce jako qemu. Pro uživatele je to vždycky takové, že doposud živý image se najednou zmrazí a je z něj snapshot, zatímco další změny páchané živým hostem jdou někam jinam, třeba do nového LVM svazku čerstvě vytvořeného. Není to copy-on-write, jen prosté zapisování do nového místa. Po zpracování snapshotu potřebuju zapsané bloky zkopírovat zpátky do původního image, k tomu slouží
    qemu-img commit <ten nový prostor>
    a následně se ten nový dočasný prostor může zlikvidovat. Jak se analogická operace udělá ve virsh jsem nějak nepochopil (což asi nebude vina virtlibu).

    Když mám vytvořený snapshot, rád bych se podíval, co v něm je. Na to ho musím napřed vyexportovat do jakoby blokového zařízení, a k tomu slouží
    qemu-nbd -c /dev/nbd0 <ten snapshot> .
    Pomocí fdisk se teď můžu podívat na strukturu virtuálního disku, a dopadne to např. takhle:

     # fdisk -u -l /dev/nbd0
    
    Disk /dev/nbd0: 21.5 GB, 21474836480 bytes
    255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x000ec934
    
         Device Boot      Start         End      Blocks   Id  System
    /dev/nbd0p1   *        2048    40136703    20067328   83  Linux
    /dev/nbd0p2        40136704    41940991      902144   82  Linux swap / Solaris
     # 
    
    Dobrá finta u fdisku je volbička -u , údaje o oblastech jsou potom spolehlivě v 512 B sektorech. Jestliže je na oblasti nbd0p1 souborový systém, třeba půjde namontovat read-only:
    mount -r -o offset=$((512*2048)) /dev/nbd0 /mnt
    Volba -r je důležitá, jinak si ve snapshotu něco změníme a jestli je ještě živý, zničíme si tím běžící image.

    Když se nechceme trápit s offsety, je tady podle jednoho návodu taková finta, která se mi líbí nejvíc ze všech vyguglených fint na tohle téma:
    modprobe -r loop && modprobe loop max_part=63
    mount -r /dev/nbd0p1 /mnt
    Česky řečeno, když si odloadujeme defaultně natažený modul pro loop zařízení a zase ho natáhneme s nenulovou hodnotou parametru max_part, tak nám losetup namapuje nejen zadané zařízení jako /dev/loop# , ale také všechny jeho oblasti jako bloková zařízení /dev/loop#p## .

    Až nás hrátky s obsahem snapshotu omrzí, je dobré nezapomenout všechno uklidit. Napřed všechny umount, potom všechny losetup -d a nakonec všechny qemu-nbd -d .

    Spolehlivost snapshoťáckých postupů jsem se snažil testovat tím, že jsem ve zkušebním hostovi pořád dělal manipulace se soubory a při tom jsem vytvářel, prohlížel a zase rušil snapshoty. Dvakrát mi při tom došlo k nevratnému narušení image, kdy mi ten host bez výstrahy spadnul. Mohlo to být chybou manipulace, ale podezření na chybu mechanismu snapshotů stejně mám. Nikomu ho nevnucuju, zkuste si to sami.

    Mount snapshotu zaživa není tak úplně nezbytná věc, ale bez něj je život o něco těžší. Takže se mi zdá důležité, že read-only mount popsaný výše se dost často nedá udělat. Není divu, virtualizační nástroj nic neví o filesystémech hosta a tak jsou file systémy ve snapshotu obecně v nekonzistentním stavu. fsck by to asi srovnal, ale to si na živém snapshotu nemůžeme dovolit. Snapshot můžeme zajisté někam zkopírovat a už v neživém stavu na něj udělat qemu-nbd -c a potom s ním pracovat už read-write. Když ale nepracujeme se soubory ale s LVM svazky, je to trochu nepraktické. A při tom právě při práci s LVM svazky, protože tam máme LVM 2, můžeme v poklidu použít LVM snapshoty. Má to samé výhody a nenapadla mě žádná nevýhoda. Takže to máme
    lvcreate --size 20g --snapshot --name debil.snap /dev/VIRTUALY/debil
    a po odzálohování zase
    lvremove VIRTUALY/debil.snap
    a to je všecko. Při testování jsem nezaregistroval žádný problém. Se živým LVM 2 snapshotem se dá klidně zacházet read-write a nic se tím nezkazí. Můžeme klidně i fsck, když na to máme náladu. Nebo to není potřeba, protože i samotný read-write mount si u některých filesystémů dokáže udělat recovery a to stačí. Tohle chování jsem pozoroval u ext3. Mount -r při intenzívním diskovém provozu na hostu většinou nešel, read-write mount mi šel vždycky. Takže na zálohování budu používat LVM snapshoty a qemu snapshoty tady budou na řešení problémů, kdy si potřebujeme schovat i obsah operační paměti.

           

    Hodnocení: 100 %

            špatnédobré        

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

    Komentáře

    Diskuse byla administrátory uzamčena

    16.8.2013 12:52 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Zálohování KVM virtuálů
    Tyhle hrátky už mám dávno za sebou a věnoval jsem jim docela dost hodně času a úsilí čti. Jak si lze všimnout, k poslední části zatím nic napsáno není, takže jen ve zkratce:

    Poslední řešení je opravdu blbuvzdorné a ustálo bez ztráty kytičky i hodně ošklivé výpadky. Pro diskless řešení je v naší wiki samostateně zpracovaný manuál.
    20.8.2013 08:39 Pev | skóre: 28
    Rozbalit Rozbalit vše Re: Zálohování KVM virtuálů
    Díky za odkazy na zajímavé čtení :-).
    17.8.2013 10:14 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Zálohování KVM virtuálů
    A reminder why you should never mount guest disk images on the host OS - snad není potřeba další komentář...
    Dobrá finta u fdisku je volbička -u , údaje o oblastech jsou potom spolehlivě v 512 B sektorech.
    platí u starších fdisků jako je ten v RHEL6, u novějších (IIRC rok a půl starých a novějších) už -u naopak zapíná kompatibilitu s DOSem.

    Ad pády - nainstalit debug balíčky, zapnout coredumpy, vytáhnout backtrace a do bugzilly s tím!

    Jinak podle libvirtích vývojářů bylo na první implementaci živých snapshotů znát, že byly spíchnuty horkou jehlou pro potřebu oVirta - třeba proto, že neuměly pracovat s trvalými doménami. :) Jinak v nadcházející verzi oVirtu by už živé snapshoty neměly být ochuzeny o RAM - viz.
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.