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 22:11 | Bezpečnostní upozornění

Intel potvrdil (INTEL-SA-00161) další bezpečnostní problém ve svých procesorech. Problém byl pojmenován L1 Terminal Fault aneb L1TF. Popis problému přímo od Intelu na YouTube. Jedná se o CVE-2018-3615 (SGX), CVE-2018-3620 (OS/SMM) a CVE-2018-3646 (VMM). Další informace na stránce Foreshadow nebo přímo v dnešním commitu do Linuxu.

Ladislav Hagara | Komentářů: 0
dnes 12:33 | IT novinky

Po více než 4 letech bylo vydáno RFC 8446 popisující verzi 1.3 protokolu TLS (Transport Layer Security). Popis novinek i historie TLS například v příspěvku na blogu Cloudflare.

Ladislav Hagara | Komentářů: 0
dnes 11:11 | Zajímavý software

V roce 1998 uvedla společnost Tiger Electronics na trh elektronickou hračku, malého chlupatého tvora s velkýma ušima, Furby. Furby patřil k nejžádanějším hračkám. Během tří let se jich prodalo více než 40 milionů. Furby již tenkrát reagoval na světlo, zvuk, polohu, doteky a přítomnost dalších Furby. Sám mluvil a pohyboval se. Firmware uvnitř simuloval postupný vývoj a učení. Zdrojový kód tohoto firmwaru byl zveřejněn na Internet Archive [Hacker News].

Ladislav Hagara | Komentářů: 12
dnes 02:00 | Nová verze

Australská společnost Blackmagic Design oznámila vydání verze 15 svého proprietárního softwaru pro editování videa a korekci barev DaVinci Resolve běžícího také na Linuxu. Představení nových vlastností na YouTube. Základní verze DaVinci Resolve je k dispozici zdarma. Plnou verzi DaVinci Resolve Studio lze koupit za 299 dolarů. Před rokem to bylo 995 dolarů.

Ladislav Hagara | Komentářů: 0
včera 21:00 | Zajímavý projekt

Cílem projektu DXVK bylo vytvořit vrstvu kompatibility mezi Direct3D 11 a Vulkanem a začlenění této vrstvy do Wine. Direct3D 10 nad Vulkanem bylo možné řešit mezikrokem pomocí vrstvy DXUP překládající Direct3D 10 na Direct3D 11. Vývojáři DXVK se rozhodli přímo podporovat Direct3D 10. Podpora byla začleněna do hlavní větve na GitHubu.

Ladislav Hagara | Komentářů: 4
včera 16:00 | Nová verze

Vyšla verze 3.10 přehrávače Audacious. Přináší oprav chyb a drobná vylepšení seznamů skladeb, vyhledávání či ikonek. Zároveň pokračují práce na novém uživatelském rozhraní využívajícím Qt namísto GTK+ – nejsou však hotovy, proto je vydání 3.10 pojmenováno „Not Quite There Yet“; až bude proces u konce, vyjde Audacious 4.

Fluttershy, yay! | Komentářů: 12
včera 02:00 | Nová verze

Linus Torvalds vydal Linux 4.18. Více o vývojovém cyklu v Jaderných novinách: začleňovací okno [1] a [2], statistiky. Finální přehled změn je k mání na webu Linux Kernel Newbies.

Fluttershy, yay! | Komentářů: 5
včera 01:00 | Pozvánky

Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze. Prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.

xkucf03 | Komentářů: 0
11.8. 22:22 | Komunita

Vývojáři svobodného softwaru pro 3D grafiku Blender představili Blender Benchmark. Uživatelé Blenderu si pomocí něj mohou otestovat své počítače a výsledky volitelně odeslat vývojářům. Z odeslaných výsledků lze například zjistit, na kterých operačních systémech byl benchmark spuštěn. Aktuálně vede Linux s cca 83 % (2032 z 2448). Získaná data budou anonymizovaná a uvolněna jako otevřená data. Představení Blender Benchmarku také na YouTube.

Ladislav Hagara | Komentářů: 5
11.8. 03:00 | Komunita

Některým uživatelům Dropboxu na Linuxu se začalo objevovat upozornění, že v listopadu přestanou být jejich soubory synchronizovány. Vývojáři Dropboxu to v oficiálním fóru potvrdili. Po 7. listopadu budou synchronizovány pouze soubory uloženy na souborovém systému ext4 [reddit].

Ladislav Hagara | Komentářů: 56
Používáte zařízení („chromebook“, „chromebox“ či tablet) s ChromeOS?
 (7%)
 (3%)
 (12%)
 (78%)
Celkem 167 hlasů
 Komentářů: 9, poslední dnes 21:03
    Rozcestník

    AToL: LibVirt API

    27.6.2012 09:45 | Přečteno: 3278× | Linux

    Autor: Daniel Vrátil
    Nasledovný príspevok je študentskou prácou, ktorá vznikla v rámci predmetu Advanced Topics of Linux Administration. Predmet je vypisovaný na Fakulte informatiky MU v spolupráci so spoločnosťou Red Hat Czech. Vyučovacím jazykom je angličtina a preto je v nej aj nasledovný príspevok, študent nemá právo výberu iného jazyka. Komentáre k obsahu príspevku sú vítané v ľubovoľnom zrozumiteľnom jazyku.

    This article aims to provide introduction to programmatic use of Libvirt through it's C API.

    Libvirt is a toolkit that allows programmers to control virtual machines running under different hypervisors through common API. At this moment Libvirt supports QEMU, Xen, LXC, OpenVZ, UML, VMWare and Microsoft Hyper-V.

    The design is that application connects through libvirt to a libvirtd deamon (local or remote), which controls it's local (from daemon's point of view) virtual machines through libvirt. Libvirt itself consists of the user-side API and backends, which essentially translate the libvirt API calls into hypervisor-specific commands.

    A lot has been written about libvirt(d) and how to install, configure it and how to use it's management tools, but less about how programmers can utilize it. Simple management tasks can be done through console applications like virsh (which supports both interactive and non-interactive mode). But sometimes programmer or administrator might want to watch a libvirtd server and be notified about events. This cannot be achieved through the console application and one must resort to use of Libvirt API.

    When it comes to programming, hands-on approach is always better then cheap talks. I will demonstrate use of Libvirt's API on an application I have written for this article. Libvirt officially offers native C API and Python bindings, but 3rd party bindings for Ruby, PHP, Perl, Java, C# and OCaml are available too. I have decided to use the native C API and write a KDE Plasma Applet and DataEngine in C++/Qt to demonstrate use of Libvirt in event-driven environment.

    I will not go into much detail of the Plasma-related code, there are numerous articles about it, including this serial (in Czech) here on ABCLinuxu. The Plasma applet is written completely in QML and is there only to visualize data, the libvirt interaaction is implemented in a DataEgine.

    The DataEngine is completely written in C++. It is a sort of a backend where each virtual machine is provided as a Source. Visualizers (like the applet) can connect to one or more sources and poll them for changes or let themselves be notified about changes. Each Source is essentially a hash map property => value. Every Source can also have so called services which visualizers can invoke to let the DataEngine perform an action or change a property of a Source.

    Libvirt offers two ways how to be notified about changes. Either by polling or by event notifications. I have decided to use event notifications, because polling causes unnecessary load on server and network. Libvirt comes with it's own implementation of an event loop, so that it can easily be used in applications without any other event-based framework (Qt, Glib, ...). The elementary use is same as with any other event-based application:

    int main(int argc, char **argv)
    {
      /* initialize libvirt */
      virInitialize(); 
    
      /* connect to server */
      virConnectPtr conn = virConnectOpen(....);
    
      /* initialize event loop */
      virEventRegisterDefaultImpl();
    
      /* connect callbacks to events */
      ....
    
      /* process events in a loop */
      quit = false;
      while (!quit) {
        virEventRunDefaultImpl();
      }
    
      /* disconnect callbacks */
      ....
    
      /* disconnect from server */
      virConnectClose(conn);
    
      return 0;
    }
    

    Problem arises if you try to use Libvirt's events implementation together with an another event-based framework. For this situation Libvirt offers virEventRegisterImpl() to which user can pass callbacks for registering, modifying and removing handlers and timeouts. User then have to implement handling of the handlers and timeouts in the other event loop. In Qt, it would be possible to reimplement QAbstractEventDispatcher to do this. Unfortunately DataEngines are just a plugins run by Plasma desktop and we can't change the event dispatcher on runtime. An alternative approach if you want to save some work, is to use the original virEventRegisterDefaultImpl() in separate thread.

    (libvirteventloop.cpp)
    void LibvirtEventLoop::run()
    {
        /* Initialize libvirt event loop */
        virEventRegisterDefaultImpl();
    
        /* Setup separate connection */
        virConnectPtr connection = virConnectOpen("qemu:///system");
    
        /* Make sure the connection stays alive in case there were no events for some time */
        if (virConnectSetKeepAlive(connection, 5, 3) < 0) {
            virConnectClose(connection);
            return;
        }
    
        /* Connect event handlers here */
        .....
    
        m_stopMutex.lock();
        while (!m_stop) {
            m_stopMutex.unlock();
    
    
            /* Die another day */
            if (virConnectIsAlive(connection) != 1)
                break;
    
            /* Process all queued libvirt events */
            if (virEventRunDefaultImpl() < 0) {
                m_stop = true;
            }
    
            m_stopMutex.lock();
        }
        m_stopMutex.unlock();
    
        /* Disconnect event handlers here */
        ....
    
        /* Disconnect from server */
        virConnectClose(connection);
    }
    

    The thread has it's own connection to server and will notify the main thread (which has it's own connection too) through standard Qt's slot/signal mechanism. The main thread then forces respective Source to update and notifies visualizers (see LibvirtEngine::eventLoopEvent()).

    To connect to event handlers, there are virConnectDomainEventRegister() and virConnectDomainEventRegisterAny() functions. The first one notifies only about changes in domain (Libvirt term for a virtual machine) lifecycle. The latter allows users to specify which type of events they want to listen to and to specify domain for which they want to receive events (otherwise events for all domains are delivered).

    Now when we are notified about events, we need to actually get a list of the domains that are available. The DataEngine has hardcoded connection to qemu:///system, which is a connection to global session of local libvirtd. The protocol specifies hypervisor type. To obtain list of all available domains, one must query active (running) and inactive domains separately. It's also worth noting, that domains in Libvirt can be uniquely identified by their name (though that can change during runtime) and UUID (persistent). Only running domains have ID. virDomainGetID() for inactive domain returns -1. The ID is incremental, but it reset to zero after every libvirtd restart.

    (LibvirtEngine::init())
        /* Get number of active and inactive domains */
        int numActiveDomains = virConnectNumOfDomains(m_connection);
        int numInactiveDomains = virConnectNumOfDefinedDomains(m_connection);
    
        char **inactiveDomains = (char **) malloc(sizeof(char *) * numInactiveDomains);
        int *activeDomains = (int *) malloc(sizeof(int) * numActiveDomains);
    
        /* Get IDs of active domains and names of inactive domains */
        numActiveDomains = virConnectListDomains(m_connection, activeDomains, numActiveDomains);
        numInactiveDomains = virConnectListDefinedDomains(m_connection, inactiveDomains, numInactiveDomains);
    
        for (int i = 0 ; i < numActiveDomains ; i++) {
            /* Lookup the actual domain object by it's ID */
            virDomainPtr domain = virDomainLookupByID(m_connection, activeDomains[i]);
            /* Create a new Plasma DataContainer for each domain */
            addSource(new LibvirtSource(domain, m_connection, this));
        }
    
        for (int i = 0 ; i < numInactiveDomains ; i++) {
            /* Lookup the actual domain by it's name */
            virDomainPtr domain = virDomainLookupByName(m_connection, inactiveDomains[i]);
            addSource(new LibvirtSource(domain, m_connection, this));
            free(inactiveDomains[i]);
        }
    

    The code above creates a new DataContainer (Source) for every domain. The sources are then exposed to visualizers via addSource().

    The next task is to populate the sources with data from domains. We do it in LibvirtSource::dataUpdateRequested() slot, which is called whenever anyone wants the Source to update. Elementary domain information are simple to retrieve, there are dedicated functions for it, like virDomainGetName(), virDomainGetID() or virDomainGetState(). For example memory configuration (soft and hard limit for VM memory allocation) can be obtained only from the XML description. Libvirt stores configuration of every domain in a XML file which can be retrieved via virDomainGetXMLDesc(). To obtain a user's text description of a domain, there is virDomainGetMetaData() function, but it throws a runtime warning when the domain does not have any description (quite common case), therefor it's better to manually look into the XML for <description> tag and silently continue when it's not there. The XML format is documented on Libvirt homepage.

    It should be possible to query the domain for memory usage (e.g. amount of used memory within the VM), but it requires some cgroups settings which didn't work for me, so the DataEngine does not report it. It is possible to get information about CPU usage though - virDomainGetInfo() returns number of virtual CPUs allocated to the domain and total CPU time used by all vCPUs (see LibvirtSource::updateCPUUsage()).

    As mentioned in the beginning of the article, every DataEngine Source can also have a Service. Our DataEngine have a few simple services for changing state of a domain and it's memory size and CPU count.

    To change a domain state, there is a specific method for every state to be invoked:

    To change number of virtual CPUs, virDomainSetVcpusFlags() is used. The flags specify whether the change should affect only current session (if the domain is active at the moment) or whether it should be persistently written to domain configuration. When VIR_DOMAIN_VCPU_MAXIMUM flag is provided, the hard limit is modified. virDomainSetMemoryFlags() works analogically for domain memory allocation and the hard limit is set through virDomainSetMaxMemory().

    It is of course possible to alter any other preferences. Some can be changed through dedicated API calls (for example storage pool has quite an extensive API), some only by altering domain's XML description. To update domain's XML, virDomainDefineXML() can be used. If the XML is missing UUID or has UUID of non-existent domain a new domain will be created. Finally, domains can be removed by virDomainUndefine().

    The Libvirt API is much more extensive, for full description see the official API reference and the Application Development Guide. If you were interested in a more detailed use of the Libvirt API, check Virt-Manager, which is written in Python and utilizes almost everything Libvirt can offer.

    To see all the code above in context and in action, you can build the example application. Tarball with sources is available here, git repository can be cloned from git://anongit.kde.org/scratch/dvratil/plasma-virt-monitor.

           

    Hodnocení: 80 %

            špatnédobré        

    Obrázky

    AToL: LibVirt API, obrázek 1 AToL: LibVirt API, obrázek 2 AToL: LibVirt API, obrázek 3

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

    Komentáře

    Vložit další komentář

    28.6.2012 14:48 David Rehza
    Rozbalit Rozbalit vše Re: AToL: LibVirt API
    Tento článek se neslučuje s kvalitou.
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.