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

    Zálohování KVM virtuálů

    16.8.2013 09:40 | Přečteno: 1868× | 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

    Vložit další komentář

    16.8.2013 12:52 Aleš Kapica | skóre: 46 | 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.