Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: Ħαℓ₸℮ℵ ␏⫢ ⦚ » 07. 01. 2020, 11:33:38
-
Jak proběhne uspání virtuálního PC (je to trochu ze široka, Windows 7,8, LInux, virtuální OS X) v různých virtualizačních nástrojích?
Resp. půjde to vůbec (zda guest os nabídne vůbec možnost přechod do režimu spánku S3 či hibernace S4) dle toho, zda provádí nějakou detekci ACPI podporovaných režimu ? Tím - tedy - nebízí virtualizační nástroj tuto možnost?
Otázka míří na spíš na S3(RAM), neboť pro S4 není potřeba z hlediska PC nic navíc, vše ohledně rozmrznutí si obstarává OS.
-
Funguje to běžně, běžně uspávám laptop se zapnutým VirtualBoxem, po otevření víka vše funguje v pohodě.
Nevidím důvod proč by to nemělo fungovat, procesor se normálně zastaví, do RAM jde dále šťáva, ... U hibernace podobně s tím, že RAM se uloží na disk.
-
Ale dotaz byl na uspání virtuálního stroje, ne hostitelského serveru.
Zběžným nakouknutím jsem zjistil, že Hyper-V BIOS toto nejspíš nepodporuje, takže virtualizované Windows 10 možnost uspání ani nenabízejí.
-
jde o to proc to chces, zda vyzadujes aby virtualizovanej os prosel vlastnim procesem suspendu nebo hibernace, nebo ti jde o to aby virtual byl "nejak" uspanej(=nezral cpu,io,lan) a nejak hibernovanej(=+uvolnil ram)... v druhem pripade, z praxe:
hostitel Xubuntu 18.04 64bit, virtualizace kvm/qemu/virt-manager, virtual W10 64bit:
- suspend - v menu VirtualniStroj dam "uspat" (~pausa), pro probuzeni Pokracovat
- hibernace - v menu VirualniStroj dam "Vypnout/Ulozit", pro probuzeni Obnovit
-
- 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?
-
Máte v tom Windows stroji naistalované guest tools? https://www.linux-kvm.org/page/WindowsGuestDrivers
-
zda vyzadujes aby virtualizovanej os prosel vlastnim procesem suspendu nebo hibernace, nebo ti jde o to aby virtual byl "nejak" uspanej(=nezral cpu,io,lan)
Ano, první možnost, že sám guest OS provede rituál S3. Naproti tomu "uspání" tlačítkem pause z rozhraní virtualizačního nástroje je zásah z vnějšího světa, který vůbec nezávisí na tom jaký OS běží uvnitř či zda to platforma virtualizačního nástroje umí.
-
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.
-
zda vyzadujes aby virtualizovanej os prosel vlastnim procesem suspendu nebo hibernace, nebo ti jde o to aby virtual byl "nejak" uspanej(=nezral cpu,io,lan)
Ano, první možnost, že sám guest OS provede rituál S3. Naproti tomu "uspání" tlačítkem pause z rozhraní virtualizačního nástroje je zásah z vnějšího světa, který vůbec nezávisí na tom jaký OS běží uvnitř či zda to platforma virtualizačního nástroje umí.
Muzu se zeptat na co to potrebujes? Popravde mi to neni moc jasne....pokud virtual nic nedela, zere uplne minimum systemovych prostredku, host stejne musi bezet kvuli zbylym virtualkam, a pokud tim chces setrit treba pamet, tak mas spis spatne nadimenzovane prostredi. Cim ho chces navic z toho suspendu probouzet?
-
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.
-
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, případně pod Windows zatrhnout tahání času z Internetu, aby si synchronizoval ten čas? třeba pak přestane zlobit, pokud by to bylo tímhle.
-
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.
-
@LarryLin pauzu sem pouzival casto pravazne s W7 a castecne s W10 na >=hodinu, neozivenej cas sem neresil, nicemu to nevadilo...
ulozeni sem pouzil jen obcas, vcera zkusil W10Pro64bit ulozit na hodinu, probuzeni bez problemu, ulozil znovu a chtel probudit ted po ~24h a problem:
Chyba pri obnovovani domeny:
operation failed: domain is not running"
Nedari se navazat v chodu domeny. Prejete si odebrat zachyceny stav a provest normalni spusteni?
Traceback (most recent call last):
File "/usr/local/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/local/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
callback(*args, **kwargs)
File "/usr/local/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn
ret = fn(self, *args, **kwargs)
File "/usr/local/share/virt-manager/virtManager/object/domain.py", line 1355, in startup
self._backend.create()
File "/usr/lib/python3/dist-packages/libvirt.py", line 1062, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: operation failed: domain is not running
problem s casem asi neni, nastavil sem cas jako ${cas_ulozeni}+5m a stejna hlaska (qcow2 image i domain.save soubory maji cas zmeny ze vcera = po zmene casu 5m pred)
-
btw: v en_US: Error restoring domain: operation failed: domain is not running
EDIT: a celkem me zarazi ze google na to najde jen 1 vysledek a to jeste irelevantni
-
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: sudo nc -U /var/lib/libvirt/qemu/domain-2-windows7/monitor.sock4) Pauznul jsem VM pomocí QMP:
{ "execute": "qmp_capabilities" }
{ "execute": "stop" }5) nechal jsem cca hodinu odležet
6) Probudil jsem VM:
{ "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"
-
... 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.
-
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)
8) 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?
-
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.
[...]
zkusil sem pauzu, zavrit okno, pokracovat a ok, i kdyz virt-manager komplet ukoncim pri pauznute virtualce a pak pustim, otevru, pokracuju tak take ok... virt-manager mam 2.2.1+git
-
Zkusil jsem spustit virt-managera s parametrem --debug, ale našel jsem jen varování:
(virt-manager:31125): GSpice-WARNING **: 12:01:58.850: Warning no automount-inhibiting implementation availableZkusil 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 :)
-
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...
-
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
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.
-
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
-
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.