Изпечатай

[mimosh]

Здравейте,
имам следният проблем с virt-manager:
Ползвам виртуална машина с уиндоус 8.1 на нея и както си работя забива за няколко секунди, след което virt-manager се изключва. Когато го включа отново, виртуалната машина си работи. Ако по време на забиването съм цъкал с мишката то тези действия са се изпълнявали и аз не съм ги виждал, т.е. виртуалната машина явно продължава да си работи, просто нямам достъп до нея.

Та въпроса ми е от къде да започна за да установя какъв е проблема.

Ползвам Кубунту 18.04, Virtual Machine Manager 1.5.1

Точно след такова забиване дадох идход от dmesg и ето това е:

[ 3694.298488] audit: type=1400 audit(1557465649.141:30): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-cfe144d7-caf7-4043-bba8-aabf909848ec" pid=4276 comm="apparmor_parser"
[ 3694.451008] audit: type=1400 audit(1557465649.297:31): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-cfe144d7-caf7-4043-bba8-aabf909848ec" pid=4279 comm="apparmor_parser"
[ 3694.591849] audit: type=1400 audit(1557465649.437:32): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-cfe144d7-caf7-4043-bba8-aabf909848ec" pid=4282 comm="apparmor_parser"
[ 3694.731235] audit: type=1400 audit(1557465649.577:33): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="libvirt-cfe144d7-caf7-4043-bba8-aabf909848ec" pid=4285 comm="apparmor_parser"
[ 3694.782860] virbr1: port 2(vnet0) entered blocking state
[ 3694.782864] virbr1: port 2(vnet0) entered disabled state
[ 3694.783155] device vnet0 entered promiscuous mode
[ 3694.785539] virbr1: port 2(vnet0) entered blocking state
[ 3694.785545] virbr1: port 2(vnet0) entered listening state
[ 3694.979212] audit: type=1400 audit(1557465649.825:34): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-cfe144d7-caf7-4043-bba8-aabf909848ec" pid=4311 comm="apparmor_parser"
[ 3695.244782] L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details.
[ 3696.790745] virbr1: port 2(vnet0) entered learning state
[ 3698.806745] virbr1: port 2(vnet0) entered forwarding state
[ 3698.806747] virbr1: topology change detected, propagating
[ 5016.226550] perf: interrupt took too long (2511 > 2500), lowering kernel.perf_event_max_sample_rate to 79500
[ 5762.432066] perf: interrupt took too long (3160 > 3138), lowering kernel.perf_event_max_sample_rate to 63250
[ 8079.675820] perf: interrupt took too long (3966 > 3950), lowering kernel.perf_event_max_sample_rate to 50250
[ 8098.802366] audit: type=1400 audit(1557470053.628:35): apparmor="DENIED" operation="capable" profile="/usr/sbin/libvirtd" pid=5059 comm="libvirt_parthel" capability=17  capname="sys_rawio"

обаче това на мен нищо не ми говори.

Някакви насоки?

[spec1a]

   Според мен или виртуалната машина е много натоварена,или
на моменти вътре бозата забива.
   Пробвай следното: конфигурирай на уиндоус -а някакво
отдалечено управление (vnc или remote desktop (за последното може
да използваш Линукс клиенти от типа на remmina и rdesktop)).
   При проблем пробвай да влезеш в уиндоус -а,ако не става,значи е
забил,и трябва да спреш виртуалната машина.

[makeme]

Може да погледнеш, и ако използваш NAT да преминеш към Bridge. NAT-a e бъгав принципно.

[mimosh]

Може да погледнеш, и ако използваш NAT да преминеш към Bridge. NAT-a e бъгав принципно.

Ползвам Route to wlp3s0

ПС: Тази виртуална машина съм я ползвал и с Кубунту 16.04, там нямаше такъв проблем.

Инсталацита на 18.04 беше чиста и конфигурацията на виртуалната машина е създадена наново, тъй като имаше някъкъв проблем при ъпгрейда беше забранено връзка с virt-manager-a.

Проблема не е много чест, обаче е дразнещ. Понякога се случва няколко пъти докато работиш да се появи, понякога с дни не се появява.

[makeme]

Проблемът ти е доста странен и предполагам е бъг при някаква ситуация.

Ако ползваш директно виртуалката, можеш да пробваш използването и през remote desktop, както @spec1a предложи. Това за да провериш дали не е някакъв бъг в KDE-то.

Може да провериш дали няма някакво разминаване в конфигурациите (новата и старата). Ако пазиш стария XML, ги сравни и виж разликите.

Отделно виж наистина и ресурсите. Дали просто не си натоварваш виртуалната или физическата машина и да краши.

ПП: На мен все ми се струва, че е нещо от мрежата. Принципно при десктоп дистрибуциите network menager-ите постоянно нещо се бъркат в работата на ръчните конфигурации и са възможни именно такива неща.

[jet]

Пробвай и да спреш apparmor, може бозата да иска да пипа някъде...