Community-list October 2017

community-list@lists.vpsfree.cz

15 participants
9 discussions

GPU Mining z vody :)
by Pavel Snajdr 07 May '18

07 May '18

Zdarec vsichni, posledni dobou si hraju s miningem altcoinu a docela se dari, tak zase pro jednou, kdyz resim neco pro sebe, proc to nezresit skupinoveji :) Naskytla se moznost umistit az 10kW HW do prostor u vodni elektrarny, takze energie s prehledem rovnou pod 2 Kc; premyslim o modelu, ze bychom poresili mining rigy ve vetsim a vy byste pak meli moznost poslat nam jenom svoje karty. Ty by pak byly pres klasicky chain vpsAdmin-OpenVZ zpristupnene do QEMU pod vasi rezii, takze na tech kartach muzete pocitat, co chcete. S konektivitou bude asi kapku problem, takze pocitam s tvrdym QoS/shapovanim, dostatecnym pro mining a SSH, ale zatim nevim o moznosti sehnat tam lepsi linku na cokoliv narocnejsiho. Kdo byste mel zajem a jak velky? :) /snajpa (Pavel Snajdr) (Predseda vpsFree.cz) (+420 720 107 791)

32 50

Budoucnost OpenVZ
by Pavel Bařina 03 Jan '18

03 Jan '18

Ahoj, s kolegou řešíme jakou cestou virtualizace se ve firmě vydat. Jelikož jsou zde odborníci na OpenVZ rád bych se poradil. Já mám zkušenosti s KVM z jiné firmy a kolega zatím zkoušel OpenVZ na CentOS release 6.7. Vyšlo nové OpenVZ a jak jsem zahlídl i zde s pár poznámek budoucnost OpenVZ může být nejistá. Jakou cestou kontejneru byste se vydali vy? Nové OpenVZ, LXC nebo docker? Zároveň bychom chtěli na stejném stroji provozovat i KVM (pro chod Windows). Momentálně máme na stroji obojí. OpenVZ i KVM. Nicméně je problém se spouštěním virtuálního stroje v KVM, po druhém pokusu o spuštění virtuálního stroje již naběhne. Chyba při startu domény: Nelze vytvořit cgroup pro Debian-wheeze: Adresář nebo soubor neexistuje Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1355, in startup self._backend.create() File "/usr/lib/python2.7/dist-packages/libvirt.py", line 999, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: Nelze vytvořit cgroup pro Debian-wheeze: Adresář nebo soubor neexistuje KVM není spuštěno v kontejnerech jako u VPS ale samostatně vedle OpenVZ Děkuji moc za postřehy a nakopnutí správným směrem Pavel

19 30

Arch Linux a problem s glibc >=2.26
by Jakub Skokan 02 Dec '17

02 Dec '17

Ahojte, dejte si pozor na aktualizaci Arch Linuxu, s glibc >= 2.26 vam VPS nenajede. Vypada to, ze glibc od 2.26 podporuje jen kernel 3.2+ [1], takze to u nas uz nemusi fungovat spravne. Zatim jsme narazili jen na problem se systemd, ktery je teda celkem zasadni, protoze nestartujou zadne sluzby, napr.: systemd-journald.service: Main process exited, code=exited, status=205/LIMITS Jedina cesta zda se bude zustat u glibc 2.25. Sablonu archu jsem upravil, nicmene existujici VPS si musite pohlidat sami -- pridat glibc do IgnorePkg v /etc/pacman.conf. Casem to zrejme bude problem i v jinych distribucich, kdyz tam ta glibc 2.26 probubla, ale to uz snad stihnem prejit na novejsi kernel + LXC. [1] https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html Jakub

2 2

MariaDB nefunguje se systemd 233 v kontejneru
by Jiří Eischmann ml. 11 Nov '17

11 Nov '17

Ahoj, při upgradu na Fedoru 26 jsem nebyl schopný nastartovat MariaDB s chybovými hláškami: mariadb.service: Failed at step KEYRING spawning /usr/libexec/mysql- check-socket: Permission denied Failed at step KEYRING spawning /usr/libexec/mysql-wait-stop: Permission denied Dočetl jsem se, že MariaDB má problémy se systemd 233 v kontejneru. Očividně to není problém jenom Fedory, protože v Ubuntu řeší něco podobného: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1691096 Ve Fedoře jsem to nahlásil: https://bugzilla.redhat.com/show_bug.cgi?id=1471306 a rollbackem se vrátil zpátky na F25. Tak si dejte na upgrade na systemd 233 pozor, používáte-li MariaDB. Jirka

6 8

Klonování virtuálu opravuje aplikace?
by Stanislav Vasko 18 Oct '17

18 Oct '17

Zdravím, mám velice zajímavou zkušenost. Moje Django aplikace začala padat jakmile odešlu email. Nejspíše nějaký problém mezi Python-Django-WSGI, možná je v tom namočený i Apache. Nicméně, abych zjistil co se děje, virtuál a jsem oklonoval, zapl debug mód a …. žádná chyba. Email odešel, aplikace poděkovala a svět se točil dál… WTF? Vrátím do DEBUG=False, opět pohoda. No totok… Než si tu ukroutím hlavu a utestuju virtuál, může někdo chytřejší poradit zda je mezi VPS a VPS na playgroundu, které bylo klonováno, nějaký rozdíl co by mohl hrát roli pro výše zmíněné technologie a posílání emailu? Nebo Playground rovnou zdrojáky opravuje :)? Mám na virtuálu, tedy i na klonu, nějakou homo-domo konfiguraci posílání emailu aby to vůbec chodilo, ale to se zklonovalo i s chybami co jsem na tom spáchal a tak to asi nemůže mít vliv. Možná, pokud Django fungovalo, to asi stejně nehraje roli, protože posílám přes nastavení SMTP a smtp.seznam.cz. Co jsem tak pohledal, na Ubuntu 14 je údajně stará verze WSGI, nicméně před pár dny ještě vše jelo a opět: klonoval jsem, takže mám shodné nastavení, aplikaci i verze aplikací, tudíž neměl by být vliv, chyby by měly být shodné. Měly by… :) Díky za nápady, mezitím zkusím opravit tu verzi WSGI přes PIP a našroubováním do Apache, když už Ubuntu se nenamáhá po létech aktualizovat. Ale přesto budu rád za jakékoliv tipy, hlavně pro budoucnost, takto nikdy nevím zda na produkci poběží co mi běží doma i přes shodné verze knihoven. Hezký den, Standa Ing. Stanislav Vasko | výkonnostní marketing, webdesign a analytika tel: +420 602 282 686 <tel:%2B420%20602%20282%20686> email: vasko(a)vaskonsulting.cz <mailto:vasko@vaskonsulting.cz> web: www.vaskonsulting.cz <http://www.vaskonsulting.cz/>

9 10

Re: [vpsFree.cz: community-list] Prosba - nefunkncni virt-manager
by René Langer 06 Oct '17

06 Oct '17

Ahoj, není to problém virt-manageru, ale hlavně libvirt. Nespustí se hypervisor libvirt qemu:///system, jak je v logách níže a virt-manager se nemá k čemu připojit. Libvirt chodí jen na OpenVZ šablonách distribuce Alpine Linux, Debian 8 a CentOS 7.1, viz. KB https://kb.vpsfree.cz/navody/vps/kvm. Jinak Qemu/KVM chodí například na Debian 9 či Ubuntu 16.04, jen se musí ovládat pomocí init skriptů, místo libvirt (virt-manageru). Renda _____________________________________________________________ > Od: Tomas Meszaros <meszaros(a)advice.sk> > Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> > Datum: 06.10.2017 20:10 > Předmět: Re: [vpsFree.cz: community-list] Prosba - nefunkncni virt-manager > mne sa to podarilo rozchodit na debian 8 jedine arty Dňa 6. 10. 2017 o 17:07, Richard Korinek <richard.korinek(a)gmail.com <richard.korinek(a)gmail.com>> napísal: Zdravím, snažím se rozchodit KVM a chtěl bych použít virt-manager. Zkoušel jsem ArchLinux 3.6 i Centos 7.3 ale zatím bez úspěchu. Naistaluju qemu, dokonce i spustím image pomocí konfiguračního souboru. Když ale zkouším virt-amanger (po nainstalování všech dependencies, pro Centos viz KB KVM / Centos), tak virt-manager padá s nic neříkající chybou. Kompletní debug:[root@majestatix log]# virt-manager --debug[Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (cli:261) Launched with command line: /usr/share/virt-manager/virt-manager --debug[Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (virt-manager:183) virt-manager version: 1.4.1[Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (virt-manager:184) virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'>[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (virt-manager:214) PyGObject version: 3.22.0[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (virt-m anager:218) GTK version: 3.22.10Gtk-Message: Failed to load module "canberra-gtk-module"[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:496) libguestfs inspection support: False[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (systray:156) Showing systray: False[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:1037) processing cli command uri= show_window= domain=[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:1039) No cli action requested, launching default window[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (manager:203) Showing manager[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:401) window counter incremented to 1[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:161) Loading stored URIs:qemu:///system[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:140) Initial gtkapplication activated[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:571) conn=qemu:///system changed to s tate=Con necting[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:989) Scheduling background open thread for qemu:///system[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1039) libvirt version=3002000[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1041) daemon version=3002000[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1042) conn version=1005003[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1044) qemu:///system capabilities:<capabilities> <host> <uuid>4e56d8c3-7406-4b81-9a01-39d12aae0b60</uuid> <cpu> <arch>x86_64</arch> <pages unit="KiB" size="4"/> </cpu> <power_management/> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> <uri_transport>rdma</uri_transport> </uri_transports> </migration_features> <secmodel> <model>none</model> <doi>0</doi> </secmodel> <secmodel> <model>dac</model> <doi>0</doi> <baselabel type="kvm">+107:+107</baselabel> <baselabel type="qemu">+107:+107</baselabel> </secmodel> </host> <guest> <os_type>hvm</os_type> <arch name="i686"> <wordsize>32</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> <machine maxCpus="240">pc-i440fx-rhel7.0.0</machine> <machine canonical="pc-i440fx-rhel7.0.0" maxCpus="240">pc</machine> <machine maxCpus="240">rhel6.0.0</machine> <machine maxCpus="240">rhel6.1.0</machine> <machine maxCpus="240">rhel6.2.0</machine> <machine maxCpus="240">rhel6.3.0</machine> <machine maxCpus="240">rhel6.4.0</machine> <machine maxCpus="240">rhel6.5.0</machine> <machine maxCpus="240">rhel6.6.0</machine> <domain type="qemu"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> <domain type="kvm"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default="off" toggle="no"/> <acpi default="o n" toggl e="yes"/> <apic default="on" toggle="no"/> <pae/> <nonpae/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name="x86_64"> <wordsize>64</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> <machine maxCpus="240">pc-i440fx-rhel7.0.0</machine> <machine canonical="pc-i440fx-rhel7.0.0" maxCpus="240">pc</machine> <machine maxCpus="240">rhel6.0.0</machine> <machine maxCpus="240">rhel6.1.0</machine> <machine maxCpus="240">rhel6.2.0</machine> <machine maxCpus="240">rhel6.3.0</machine> <machine maxCpus="240">rhel6.4.0</machine> <machine maxCpus="240">rhel6.5.0</machine> <machine maxCpus="240">rhel6.6.0</machine> <domain type="qemu"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> <domain type="kvm"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default="off" toggle="no"/> <acpi default= "on" tog gle="yes"/> <apic default="on" toggle="no"/> </features> </guest> </capabilities> [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:845) Using domain events[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:882) Using network events[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:902) Using storage pool events[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:921) Using node device events[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1426) Error polling connection qemu:///systemTraceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 1404, in tick_from_engine self._tick(*args, **kwargs) File "/usr/share/virt-manager/virtManager/connection.py", line 1294, in _tick self._hostinfo = self._backend.getInfo() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3739, in getInfo if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self)libvirtError: An error occurred, but the cause is unknown[Pá, 06 říj 2017 16 :47:39 virt-manager 943] DEBUG (connection:1436) An error occurred, but the cause is unknown[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:937) conn.close() uri=qemu:///system[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:571) conn=qemu:///system changed to state=Disconnected[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (error:99) error dialog message:summary=Error polling connection 'qemu:///system': An error occurred, but the cause is unknowndetails=Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 385, in _handle_tick_queue conn.tick_from_engine(**kwargs) File "/usr/share/virt-manager/virtManager/connection.py", line 1437, in tick_from_engine raise e # pylint: disable=raising-bad-typelibvirtError: An error occurred, but the cause is unknown [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (manager:214) Closing manager[Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:405) window counter decremented to 0[Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:467) No windows found, requesting app exit[Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:491) Exiting app normally.Vypadá to, že na něco nedostane odpověď "ret is None" .... ale netuším na co. Jak v ArchLinuxu tak i v Centosu jsem našel tythle hlášky:Oct 6 17:04:35 majestatix libvirtd: 2017-10-06 15:04:35.371+0000: 1420: warning : virNumaGetNodeCPUs:276 : NUMA topology for cell 0 is not available, ignoringOct 6 17:04:35 majestatix libvirtd: 2017-10-06 15:04:35.372+0000: 1420: warning : virQEMUCapsInit:1138 : Failed to get host CPUNa Centosu si potom ještě stěžuje KSMTUNEDOct 6 16:57:56 majestatix ksmtuned: /usr/sbin/ksmtuned: line 61: /sys/kernel/mm/ksm/run: No such file or directoryOct 6 16:58:06 maje statix / usr/sbin/irqbalance: WARNING, didn't collect load info for all cpus, balancing is brokenAle netuším, jestli to s tím souvisí. Nemáte někdo nějakou radu co dál prosím? Vzhledem k tomu, že jsem ke stejnému výsledku dospěl jak na Centos tak i na Arch LInux, tak myslím že problém bude někde v nastavení VPSky? Nebo se pletu? Díky za tipy jak dál.R.-- Richard Kořínek ^^^^^^^^^^^^^^ email: richard.korinek(a)gmail.com <richard.korinek(a)gmail.com>phone: +420 604 777 044 _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz <Community-list(a)lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list ---------- _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>

1 0

Prosba - nefunkncni virt-manager
by Richard Korinek 06 Oct '17

06 Oct '17

Zdravím, snažím se rozchodit KVM a chtěl bych použít virt-manager. Zkoušel jsem ArchLinux 3.6 i Centos 7.3 ale zatím bez úspěchu. Naistaluju qemu, dokonce i spustím image pomocí konfiguračního souboru. Když ale zkouším virt-amanger (po nainstalování všech dependencies, pro Centos viz KB KVM / Centos), tak virt-manager padá s nic neříkající chybou. Kompletní debug: [root@majestatix log]# virt-manager --debug [Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (cli:261) Launched with command line: /usr/share/virt-manager/virt-manager --debug [Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (virt-manager:183) virt-manager version: 1.4.1 [Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (virt-manager:184) virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'> [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (virt-manager:214) PyGObject version: 3.22.0 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (virt-manager:218) GTK version: 3.22.10 Gtk-Message: Failed to load module "canberra-gtk-module" [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:496) libguestfs inspection support: False [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (systray:156) Showing systray: False [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:1037) processing cli command uri= show_window= domain= [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:1039) No cli action requested, launching default window [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (manager:203) Showing manager [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:401) window counter incremented to 1 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:161) Loading stored URIs: qemu:///system [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:140) Initial gtkapplication activated [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:571) conn=qemu:///system changed to state=Connecting [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:989) Scheduling background open thread for qemu:///system [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1039) libvirt version=3002000 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1041) daemon version=3002000 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1042) conn version=1005003 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1044) qemu:///system capabilities: <capabilities> <host> <uuid>4e56d8c3-7406-4b81-9a01-39d12aae0b60</uuid> <cpu> <arch>x86_64</arch> <pages unit="KiB" size="4"/> </cpu> <power_management/> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> <uri_transport>rdma</uri_transport> </uri_transports> </migration_features> <secmodel> <model>none</model> <doi>0</doi> </secmodel> <secmodel> <model>dac</model> <doi>0</doi> <baselabel type="kvm">+107:+107</baselabel> <baselabel type="qemu">+107:+107</baselabel> </secmodel> </host> <guest> <os_type>hvm</os_type> <arch name="i686"> <wordsize>32</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> <machine maxCpus="240">pc-i440fx-rhel7.0.0</machine> <machine canonical="pc-i440fx-rhel7.0.0" maxCpus="240">pc</machine> <machine maxCpus="240">rhel6.0.0</machine> <machine maxCpus="240">rhel6.1.0</machine> <machine maxCpus="240">rhel6.2.0</machine> <machine maxCpus="240">rhel6.3.0</machine> <machine maxCpus="240">rhel6.4.0</machine> <machine maxCpus="240">rhel6.5.0</machine> <machine maxCpus="240">rhel6.6.0</machine> <domain type="qemu"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> <domain type="kvm"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default="off" toggle="no"/> <acpi default="on" toggle="yes"/> <apic default="on" toggle="no"/> <pae/> <nonpae/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name="x86_64"> <wordsize>64</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> <machine maxCpus="240">pc-i440fx-rhel7.0.0</machine> <machine canonical="pc-i440fx-rhel7.0.0" maxCpus="240">pc</machine> <machine maxCpus="240">rhel6.0.0</machine> <machine maxCpus="240">rhel6.1.0</machine> <machine maxCpus="240">rhel6.2.0</machine> <machine maxCpus="240">rhel6.3.0</machine> <machine maxCpus="240">rhel6.4.0</machine> <machine maxCpus="240">rhel6.5.0</machine> <machine maxCpus="240">rhel6.6.0</machine> <domain type="qemu"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> <domain type="kvm"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default="off" toggle="no"/> <acpi default="on" toggle="yes"/> <apic default="on" toggle="no"/> </features> </guest> </capabilities> [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:845) Using domain events [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:882) Using network events [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:902) Using storage pool events [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:921) Using node device events [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1426) Error polling connection qemu:///system Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 1404, in tick_from_engine self._tick(*args, **kwargs) File "/usr/share/virt-manager/virtManager/connection.py", line 1294, in _tick self._hostinfo = self._backend.getInfo() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3739, in getInfo if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self) libvirtError: An error occurred, but the cause is unknown [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1436) An error occurred, but the cause is unknown [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:937) conn.close() uri=qemu:///system [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:571) conn=qemu:///system changed to state=Disconnected [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (error:99) error dialog message: summary=Error polling connection 'qemu:///system': An error occurred, but the cause is unknown details=Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 385, in _handle_tick_queue conn.tick_from_engine(**kwargs) File "/usr/share/virt-manager/virtManager/connection.py", line 1437, in tick_from_engine raise e # pylint: disable=raising-bad-type libvirtError: An error occurred, but the cause is unknown [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (manager:214) Closing manager [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:405) window counter decremented to 0 [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:467) No windows found, requesting app exit [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:491) Exiting app normally. Vypadá to, že na něco nedostane odpověď "ret is None" .... ale netuším na co. Jak v ArchLinuxu tak i v Centosu jsem našel tythle hlášky: Oct 6 17:04:35 majestatix libvirtd: 2017-10-06 15:04:35.371+0000: 1420: warning : virNumaGetNodeCPUs:276 : NUMA topology for cell 0 is not available, ignoring Oct 6 17:04:35 majestatix libvirtd: 2017-10-06 15:04:35.372+0000: 1420: warning : virQEMUCapsInit:1138 : Failed to get host CPU Na Centosu si potom ještě stěžuje KSMTUNED Oct 6 16:57:56 majestatix ksmtuned: /usr/sbin/ksmtuned: line 61: /sys/kernel/mm/ksm/run: No such file or directory Oct 6 16:58:06 majestatix /usr/sbin/irqbalance: WARNING, didn't collect load info for all cpus, balancing is broken Ale netuším, jestli to s tím souvisí. Nemáte někdo nějakou radu co dál prosím? Vzhledem k tomu, že jsem ke stejnému výsledku dospěl jak na Centos tak i na Arch LInux, tak myslím že problém bude někde v nastavení VPSky? Nebo se pletu? Díky za tipy jak dál. R. -- Richard Kořínek ^^^^^^^^^^^^^^ email: richard.korinek(a)gmail.com phone: +420 604 777 044

2 1

Pomoc se stánkem Alpine Linuxu na LinuxDays
by Jakub Jirutka 05 Oct '17

05 Oct '17

Ahoj, Hody mě ukecal, abych na LinuxDays udělal stánek pro Alpine Linux. Problém je, že nikomu z komunity se do Prahy nějak moc nechce, takže jsem na to sám. Chtěl bych se tedy zeptat, zda by mi s tím někdo nechtěl pomoci. Hlavně s fyzickým bytím na stánku, abych taky mohl na nějaké přednášky. :) Jakub J.

3 2

Přivez staré knížky na LinuxDays
by Petr Krcmar 03 Oct '17

03 Oct '17

Ahoj všem, vymyslel jsem si takovou věc: mám tu hromadu různých knížek o Linuxu, vývoji, sítích a podobně a chci se jich zbavit. Odvezu je proto na LinuxDays na stánek vpsFree a nechám je tam rozebrat. Máte taky takové? Vezměte je taky, udělají radost někomu dalšímu! Říjen, měsíc linuxové knihy zdarma. -- Petr Krčmář vpsFree.cz

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Community-list October 2017