Příspěvky

451

Windows a jiné systémy / Re:Nelze se připojit na SAMBA disk

« kdy: 30. 01. 2020, 17:10:39 »

Ahoj díky za tip mapování \\name\slozka a \\IPadresa\slozka jsem zkousel na Win10 proste nejede.
Asi přejdu na Wedos disk ...

Wedos disk v žádném případě. Za ty prachy seženeš i dvojnásobnou kapacitu.

452

/dev/null / Re:Hackathon na dálniční známky.

« kdy: 27. 01. 2020, 14:22:02 »

Trochu jsem to včera sledoval https://www.facebook.com/znamkamarada/videos/518326918792325/ a zajímalo mě jaké technologie použili.
Prezentace je sice trochu zmatená, ale vzhledem ke shonu v jakém to vznikalo se to dá pochopit. Jestli jsem to správně pochytil, tak použili:

Eshop udělali 2x ( https://ferznamka.cz/ a https://fairznamka.cz/ ):
1) v ReactJS
2) v Kentico - https://www.kentico.com/
Včera jely oba, dnes se přesměrovává jen na fairznamka.cz

Udělali appky na Android a iOS.

Core system udělali v .Net.

Rozpoznání SPZ: ALPR Cameras + statická kamera od firmy CAMEA.

Integrace na účetní systém Abra.

Hostováno je na MS Azure Cloud.

Reporting: Power BI - https://powerbi.microsoft.com/cs-cz/report-server/

Jestli je tady někdo kdo se toho účastnil nebo zná bližší informace o technických detailech tak by bylo skvělé kdyby se podělil. Mě zarazil ten .NET. Více bych hádal Javu, myslím, že se jim přihlásilo více vývojářů v Javě než v .NETu.

453

Vývoj / Re:Využití a aplikace Machine learningu

« kdy: 22. 01. 2020, 12:36:36 »

V jedné firmě používali ML na odhad kdy bude zákazník objednávat další zboží. ML se učil chování zákazníků při opakovaných objednávkách a pak jim dokázal s předstihem dané zboží nabídnout. Nemusí se jednat jen o chování konkrétního zákazníka, že každé 2 měsíce objednává brusné kotouče, ale o chování nějaké skupiny zákazníků, např. když si někdo koupí základovku se 4 sloty RAM a zakoupí si jen 2 moduly RAM, tam mu ML za 5 let nabídne speciální nabídku dalších 2 modulů (pro upgrade PC).

454

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 10. 01. 2020, 11:44:52 »

no s verzi qemu si me zaskocil :-D

Xubuntu 18.04.3
qemu 2.11+dfsg-1ubuntu7.21
libspice-server1 0.14.0-1ubuntu2.4
libvirt0 4.0.0-1ubuntu8.14
virt-manager z gitu...

Teď jsi zaskočil zase ty mě. Qemu 2.11 je na můj vkus už hodně historická verze. Když jsem si před pár lety nastavoval virtuálky, tak jsem pro ně potřeboval nové funkce co byly v Qemu. Teď už nejnovější funkce nepotřebuji, takže pomrkávám po distru, které by bylo více stabilní a méně aktuální, ale s 2.11 bych kvůli vga-pass měl asi problém.

Spice (server) 0.14.0 jsem v kešce měl, ale právě kvůli Qemu jsem ho nemohl downgradovat. libvirtd (libvirt) mám 5.10.0.

455

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 10. 01. 2020, 11:33:32 »

No on můj dotaz nebyl na ovladače, ale na guest tools(guest-agent) https://wiki.libvirt.org/page/Qemu_guest_agent cituji z popisu

executing functions which need assistance of the guest OS. For example, freezing and thawing filesystems, entering suspend

Guest agenta nemám. Co vím, tak guest agent by byl potřebný pokud bych se snažil uspat nebo hibernovat OS uvnitř VM. Ten bug na který jsem narazil se ale týká pauznutí celé VM bez ohledu na OS.

PS: co mám své virtuály Windowsu v čistém Qemu (bez libvirtu), tak jsem pro guest agenta nikdy nenašel využití. Když potřebuji Windows uvnitř VM hibernovat nebo spustit nějaký Win program/script a potřebuji to udělat z vnějšku (z hostitele), tak vše dělám přes Qemu monitor - https://en.wikibooks.org/wiki/QEMU/Monitor

456

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 09. 01. 2020, 13:54:35 »

Zkusil jsem spustit virt-managera s parametrem --debug, ale našel jsem jen varování:

Kód: [Vybrat]

(virt-manager:31125): GSpice-WARNING **: 12:01:58.850: Warning no automount-inhibiting implementation available

Zkusil jsem v nastavení VM nastavit Obrazovku "VNC server" místo výchozího "Spice server" a kupodivu to pomohlo - s VNC to nevytuhává. Zkusil jsem downgradovat Spice, ale Qemu vyžaduje min. verzi 0.14.2 (moje současná) a starší Qemu v kešce nemám. Downgrade spice-gtk, spice-protokolu, virt-managera nepomohl. Takže nevím který balíček za ten bug může.

Mám:
virt-manager 2.2.1
spice 0.14.2
qemu 4.2.0

Mám pech. Jen jsem chtěl vyzkoušet uspávání ve virt-manageru a zrovna narazím na bug. Asi mně osud naznačuje, že mám přejít na stabilnější distro

457

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 09. 01. 2020, 00:53:04 »

Tak nakonec jsem zjistil, že vůbec nezáleží na délce běhu VM. Jde pouze o to jestli je po pauznutí VM zavřeno okno dané VM.

Reprodukce problému:
1) Spustit virt-manager
2) Otevřít VM (stačí dvakrát na ni kliknout)
3) Spustit VM
4) Pauznout VM
5) Zavřít okno
6) Otevřít VM (stačí dvakrát na ni kliknout)
7) Obnovit VM (zrušit pauzu)
a VM je zatuhnuta

Pokud bod 5+6 vynechám nebo zavřu okno pouze když VM běží (není pauznutá), tak vše funguje dobře. Testováno na VM Win7, Debian9, Openelec, Alpine Linux. Všude se to chová stejně. Zvláštní. Že by nějaký bug v GUI virt-managera?

458

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 08. 01. 2020, 23:27:50 »

... to zrychlení času má na svědomí zřejmě nastavení:
<timer name="rtc" tickpolicy="catchup"/>
což je v libvirtu výchozí nastavení pro Win guesty.

459

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 08. 01. 2020, 23:03:49 »

Mně to nedalo a taky jsem ještě něco zkusil:

1) Ve virt-manageru jsem spustil VM Windows7
2) Ukončil jsem virt-managera i libvirtd
3) Napojil jsem se na VM napřímo:

Kód: [Vybrat]

sudo nc -U /var/lib/libvirt/qemu/domain-2-windows7/monitor.sock

4) Pauznul jsem VM pomocí QMP:

Kód: [Vybrat]

{ "execute": "qmp_capabilities" }
{ "execute": "stop" }

5) nechal jsem cca hodinu odležet
6) Probudil jsem VM:

Kód: [Vybrat]

{ "execute": "cont" }

Takto jsem to udělal 2x a VM nevytuhla ani jednou, přitom když jsem pauzoval ve virt-manageru na desítky minut, tak VM s Win7 vytuhla vždy. Takže si myslím, že to vytuhnutí při pauznutí a obnovení ve virt-manageru je zřejmě bug libvirtu (nějaký problém se zámky stavů).

Ale to není všechno. Po probuzení té VM jsem si všiml, že čas není opožděn, ale naopak je na hodinách víc než ve skutečnosti. Po bližším pohledu jsem si všiml, že jedna minuta trvá jen cca 6 sekund. Když jsem si hodiny rozklikl, abych viděl ty windowsovské ručičkové hodiny, tak jsem se začal smát - vteřinová ručička uháněla jako při cestování časem . Až po několika minutách se to vrátilo do normální rychlosti. Kdybych hledal řešení s problémy s časem, tak bych asi zkusil odstranit "no-hpet" nebo přidat "-cpu hv_time ..." (což u svých VM v Qemu scriptu takto mám).

Každopádně mě Libvirt a Virt-manager zase zklamal. Zase jsem se utvrdil v tom, že někdy věci usnadňuje, ale někdy je to zase zbytečná vrstva nad Qemu, která je zdrojem bugů (snad libvirtu nekřivdím, protože to může být i bug přímo v qemu).

PS: ani já jsem přes google nenašel jasnou odpověď na "monitor=remoteDispatchDomainResume"

460

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 08. 01. 2020, 18:08:06 »

takže mám podezření, že se OS nevyrovná s rozdílným časem po probuzení. Nevím, je to jen odhad, protože nevím jak to debbugnou.

co na guesta nainstalovat ntp daemona

To na Debianu9 nastavené je. Když pozastavím VM Debianu na pár minut, tak po probuzení VM se po 1-2 minutách čas synchronizuje.

případně pod Windows zatrhnout tahání času z Internetu

To je také ve Win nastavené, ale jde o to, že když VM hned po probuzení vytuhne, tak se nic nezesynchronizuje.

Na netu jsem našel pár bugů, které se týkaly obnovení VM, např. https://bugzilla.redhat.com/show_bug.cgi?id=1635581 , ale žádné řešení. Jelikož to nepoužívám, tak se mi tomu nechce věnovat čas - jen jsem to zkusil. Jen mě zajímá jestli to na jiných distribucích funguje spolehlivě nebo jestli s takovým probouzením virtuálky bývají problémy.

461

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 08. 01. 2020, 16:48:26 »

Máte v tom Windows stroji naistalované guest tools? https://www.linux-kvm.org/page/WindowsGuestDrivers

Mám tam nainstalované Virtio ovladače (virtio-scsi, virtio-ethernet, virtio-serial, virtio-balloon) no a ten qxl. Jelikož se mi to stalo i u VM s Debianem, tak virtio ovladače s tím podle mě nesouvisí.
Zkusím to dnes ještě párkrát, uvidíme jestli to byl včera jen náhodný problém libvirtu.

Tak jsem to dnes ještě zkusil - pauznul jsem VM Win7 i VM Debian9 na cca 50 minut a ani jedna z nich se neprobrala. V hlavním okně virt-managera jsou obě VM uvedeny jako "spuštěné", ale když nahoře v menu kliknu na "Otevřít", tak se cca 10 sekund nic neděje a poté se místo GUI daného OS objeví hláška:

Chyba při připojování ke grafické konzoli:
Při operaci překročen časový limit: nedaří se získat zámek změny stavu (drženo monitor=remoteDispatchDomainResume)

Zkoušel jsem se připojit přes Remote-viewer a taky se nepřipojí, jen nápis "Connecting ...". Zkrátka to vypadá, že OS po probuzení totálně vytuhne. Díval jsem se jestli v těch VM nejsou nastaveny nějaké exotické zařízení, ale zdá se, že ne. Pokud pauznu VM na pár sekund nebo minut, tak to naopak funguje jak má, takže mám podezření, že se OS nevyrovná s rozdílným časem po probuzení. Nevím, je to jen odhad, protože nevím jak to debbugnou. Testoval jsem na hostiteli Manjaro.

462

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 08. 01. 2020, 12:51:21 »

Máte v tom Windows stroji naistalované guest tools? https://www.linux-kvm.org/page/WindowsGuestDrivers

Mám tam nainstalované Virtio ovladače (virtio-scsi, virtio-ethernet, virtio-serial, virtio-balloon) no a ten qxl. Jelikož se mi to stalo i u VM s Debianem, tak virtio ovladače s tím podle mě nesouvisí.

Zkusím to dnes ještě párkrát, uvidíme jestli to byl včera jen náhodný problém libvirtu.

463

Windows a jiné systémy / Re:Uspání virtuálního PC

« kdy: 07. 01. 2020, 21:17:27 »

- hibernace - v menu VirualniStroj dam "Vypnout/Ulozit", pro probuzeni Obnovit

Běžně to takto přes virt-manager nepoužívám, tak jsem to zkusil na VM s Win 7. Po obnovení je na hodinách ve VM čas z doby "Uložení" a ani po několika minutách se nesrovnal. Také se mi ve VM začaly objevovat grafické artefakty (používám QXL což je výchozí ovladač ve virt-manageru).

- suspend - v menu VirtualniStroj dam "uspat" (~pausa), pro probuzeni Pokracovat

Toto mně fungovalo jen když jsem VM s Win 7 pozastavil na jednotky minut. Pokud jsem VM pozastavil na cca 15 min, tak po obnovení VM sice fungovala myš, ale Windows nijak nereagoval. Po chvilce vyskočila hláška:
"libvirt.libvirtError: Při operaci překročen časový limit: nedaří se získat zámek změny stavu (drženo monitor=remoteDispatchDomainResume)". Takto se mi to u Win 7 stalo několikrát.
Zkusil jsem to i na VM s Debianem a výsledek stejný - po obnovení VM po 15 minutách Debian nereagoval a pak stejná chybová hláška. Napodruhé VM s Debianem fungovala i po 15 minutách a čas se během 1-2 minut srovnal.

Obě VM jsou už pár let staré, takže možná si dnes virt-manager vytváří VM s jinou konfigurací kde tento problém není. Tys takový problém nezaznamenal?

464

O serveru Root.cz / Přestaly fungovat statistiky Nových uživatelů

« kdy: 02. 01. 2020, 20:11:19 »

Né, že bych byl šťoura, ale od září 2019 vám přestaly fungovat statistiky Nových uživatelů - https://forum.root.cz/index.php?action=stats
Tabulka úplně dole, sloupec "Nových uživatelů".

PS: Posílal jsem v listopadu SZ (panu Krčmářovi), ale možná se někde zatoulala.

465

Windows a jiné systémy / Re:Linux a v něm běžící virtuál s Windows

« kdy: 02. 01. 2020, 19:58:06 »

to automaticke pusteni pri bootu se da zaskrtnout ve virt-manageru v detailech konkretniho virtualu, sekce "Predvolby zavadeni"

Jo je to tam, bohužel automatické uspávání (uložení stavu) VM při shutdownu hostitele tam není.

@mhi: Před tím jsem psal o uspávání pomocí příkazu "system_powerdown", který se pošle do VM (já to tak mám kvůli vga-passthrough), ale bez vga-pass by mělo jít VM pauznout a uložit obsah RAM a CPU na disk. Tady je nějaká nápověda https://unix.stackexchange.com/questions/361010/pause-qemu-kvm-vm-save-ram-and-cpu-state-to-disk-like-vmware-player

Co se týká problému se systémovým časem po probuzení VM, tak to jsem opravdu kdysi řešil a jak jsem mrkl do svých poznámek, tak jsem to vyřešil přidáním hv_time za Qemu parametr "-cpu". Takže tam má něco jako:

Kód: [Vybrat]

-cpu host,hv_time,...

Možná že se hv_time přidává automaticky při vytváření VM ve virt-manageru. Další způsob synchronizace času by měl být za pomocí QMP pomocí guest-agenta příkazem "{"execute":"guest-set-time"}"