Traag opstarten virt-manager

[smeerbartje]

De situatie: Ubuntu 14.nieuwste op een 64 bit machine. Ik heb KVM geinstalleerd via "apt-get install qemu-kvm libvirt-bin". Alles prima tot dusver. Aangezien de server headless is wil ik via X-forwarding het zaakje bedienen. Dus vanaf m'n iMac benader ik de server met: "ssh -X [serverip]".

Daarna start ik virt-manager op en moet ik belachelijk lang wachten totdat het zaakje is opgestart. Zie hieronder de stdout logging. Ik weet nu niet meer waar ik het moet zoeken. Eerst zie ik dat hij twee minuten ofzo wacht tussen "keyring:30" en "engine:411".

Daarna duurt het lang tijdens het "About to connect to uris ['qemu:///system']". Het lijkt erop dat virt-manager probeert te connecten naar de verkeerde locatie en uiteindelijk de goede wel te pakken heeft. Maar hoe debug ik dit?

Overigens, ALS het eenmaal is opgestart, dan werkt alles erg snel. Het gaat volgens mij dus mis tijdens het connecten naar de host.
.

code:

$ virt-manager --debug
2015-09-19 14:39:57,405 (cli:71): virt-manager startup
2015-09-19 14:39:57,406 (virt-manager:314): Launched as: /usr/share/virt-manager/virt-manager.py --debug
2015-09-19 14:39:57,406 (virt-manager:315): GTK version: (2, 24, 23)
2015-09-19 14:39:57,406 (virt-manager:316): virt-manager version: 0.9.5
2015-09-19 14:39:57,407 (virt-manager:317): virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'>
2015-09-19 14:39:57,475 (cli:118): virtinst version: 0.600.4
2015-09-19 14:39:57,476 (cli:119): virtinst import: <module 'virtinst' from '/usr/lib/python2.7/dist-packages/virtinst/__init__.pyc'>
2015-09-19 14:39:57,495 (keyring:30): gnomekeyring bindings not installed, no keyring support
2015-09-19 14:42:04,811 (engine:411): No inspection thread because libguestfs is too old, not available, or libvirt is not thread safe.
2015-09-19 14:42:04,817 (systray:138): Showing systray: True
2015-09-19 14:44:12,116 (engine:202): About to connect to uris ['qemu:///system']
2015-09-19 14:46:19,368 (manager:172): Showing manager
2015-09-19 14:46:19,399 (engine:327): window counter incremented to 1
2015-09-19 14:46:19,400 (manager:172): Showing manager
2015-09-19 14:46:19,402 (connection:963): Scheduling background open thread for qemu:///system
2015-09-19 14:46:19,403 (connection:1019): Background 'open connection' thread is running
2015-09-19 14:46:19,427 (connection:1070): Background open thread complete, scheduling notify
2015-09-19 14:46:19,495 (connection:1075): Notifying open result
2015-09-19 14:46:19,509 (connection:1082): qemu:///system capabilities:
<capabilities>

 -- knip --

</capabilities>

2015-09-19 14:46:19,705 (connection:579): Connection managed save support: True
2015-09-19 14:46:19,749 (connection:161): Using libvirt API for netdev enumeration
2015-09-19 14:46:19,749 (connection:201): Using libvirt API for mediadev enumeration

Hier nog een plaatje nadat virt-manager eenmaal verbinding heeft gemaakt:



Als ik met strace -ff virt-manager start, dan is dit de output:

code:

socket(PF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 4
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
connect(4, {sa_family=AF_INET6, sin6_port=htons(6010), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28

hier staat hij dus heel lang op de wachten... hij lijkt dus eerst verbinding te maken op ip6? Of lees ik dit verkeerd? Na een minuut of twee verschijnt er nieuwe logging:

code:

-edit-
niet meer relevant

[ Voor 76% gewijzigd door smeerbartje op 20-09-2015 13:08 ]

[CAPSLOCK2000]

ssh -X kan allerlei vreemde vertragingen veroorzaken. Je zou een lokale X-server op die server kunnen zetten om dat te testen, bv met tightvnc. Als het dan wel goed draait dan weten we dat de rond-trip-time delay van ssh het probleem is. Als het probleem dan nog optreedt dan kunnen we SSH uitsluiten.


Doe je iets met IPV6? Kan het zijn dat je systeem eerst probeert om via IPv6 te verbinden en pas nadat dit mislukt is verder gaat met IPv4? In je logs zie ik niks dat daar op wijst maar zo voelt het wel.

Heb je een ander (desktop)systeem waarop je de virt-manager client kan draaien om te testen? Ik meen me te herinneren dat er ook een port van virt-manager naar OS-X is. Die kun je native op je mac draaien. virt-manager gebruikt dan zelf ssh om met je server te communiceren. Dat is een stuk sneller en minder gevoelig voor lag. Eventueel zou je kunnen testen door een live-CD te booten.

De directe route om uit te zoeken wat er mis is heet 'strace', daarmee kun je precies zien wat die software staat te doen maar het lezen van de uitvoer van strace is wel een beetje een kunst. Vaak is echter in een oogopslag te zien waar het programma staat te wachten en heb je een goed aanknoopingspunt om verder te zoeken.

[CAPSLOCK2000]

[b]smeerbartje schreef op zaterdag 19 september 2015 @ 14:53:
Als ik met strace -ff virt-manager start, dan is dit de output:

code:

socket(PF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 4
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
connect(4, {sa_family=AF_INET6, sin6_port=htons(6010), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28

Ha!
We hebben tegelijkertijd zitten posten en zitten op hetzelfde pad!

Werkt 'ping6 ::1' op die server?

PS. je laatste logmelding is weggevallen.

[ Voor 75% gewijzigd door CAPSLOCK2000 op 19-09-2015 15:58 ]

[johnkeates]

Is het trouwens niet zinvol om voor dit soort zaken virsh te gebruiken over SSH zonder X?

[Thralas]

Of virt-manager aan de clientzijde en verbinden over SSH.. en weg was het probleem

[smeerbartje]

Nou, ik ben een stap verder . Op aanraden van CAPSLOCK2000 eens bekeken of ik kon pingen naar localhost op ip6. En het bleek inderdaad dat m'n iptables ruleset al het ip6 verkeer dropped. Dat heb ik er -als linux-noob- zelf ooit een keer ingezet:

code:

ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP

Er viel me echter iets op: als ik vanuit de server naar localhost connect naar ssh, dan probeerde de server eerst via ip6 te connecten. Waarom is dit? Ik zie dat hij het volgende een tijdje probeert (en daarna time-out):

code:

connect(3, {sa_family=AF_INET6, sin6_port=htons(777), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28

Na een tijdje wordt de ssh sessie wel degelijk tot stand gebracht. Maar ik vraag me af waarom ip6 verkeer nodig is? Als ik deze rules vervolgens flush, dan werkt alles naar behoren. Dus ssh connecten naar localhost gaat dan snel, maar ook het starten van virt-manager via SSH -X.

Dan heb ik nu nog één laatste vraag: de server dient als router. Twee NICs erin en middels NAT deel ik het internet met de rest van het huis. Ik gebruik hiervoor een setje IPTABLES, maar wat doe ik nu met het ip6 verkeer om het geheel een beetje veilig te houden? Vroeger dropte ik alles met bovenstaande regels, maar dit is dus iets teveel van het goede blijkt nu.

[ Voor 25% gewijzigd door smeerbartje op 20-09-2015 13:12 ]

[Hero of Time]

IPv6 heeft een hogere prioriteit over IPv4. Je kan wel IPv6 geheel uitschakelen, maar waarom zou je dat willen doen? Kijk eens welke IPv6 adressen je hebt. Is het alleen in de reeks van FE80: dan heb je alleen lokale IPv6 adressen en is er geen reden om IPv6 verkeer te droppen. Wil je echt het verkeer droppen, doe het dan alleen op de WAN interface.

[smeerbartje]

Hero of Time schreef op zondag 20 september 2015 @ 13:31:
IPv6 heeft een hogere prioriteit over IPv4. Je kan wel IPv6 geheel uitschakelen, maar waarom zou je dat willen doen? Kijk eens welke IPv6 adressen je hebt. Is het alleen in de reeks van FE80: dan heb je alleen lokale IPv6 adressen en is er geen reden om IPv6 verkeer te droppen. Wil je echt het verkeer droppen, doe het dan alleen op de WAN interface.

Om eerlijk te zijn heb ik geen idee of ik IPv6 gebruik. M'n provider is Ziggo. http://test-ipv6.com vertelt me dat ik geen ip6 addres heb. Ik wil voor de zekerheid toch wel al het ip6 verkeer droppen op de externe interface. Hoe doe ik dat?

[CAPSLOCK2000]

IPv6 is nieuwer dan IPv4 dus dat krijgt de voorkeur. Zelfs als je het niet gebruikt voor internet dan wordt het nog intern gebruikt.

Je kan ip6tables vertellen welke interfaces het moet gebruiken (bv met '-i eth0'). Het gaat een beejte te ver om dat hier helemaal uit te werken, er zijn zat tutorials te vinden.
Als dit de eerste keer is dat je met firewalls werkt op Linux dan ben je waarschijnlijk beter af met een wrapper om iptables, zoals UFW dat standaard door Ubuntu wordt bijgeleverd.

[smeerbartje]

Ok, thanks allemaal. Ik zal me er eens in verdiepen. Problem solved, i.i.g. .

[ Voor 20% gewijzigd door smeerbartje op 20-09-2015 18:43 ]