[libvirt-users] Debugging TLS connection between virt-viewer and libvirt running on separate hosts
by Will Dennis
Hi all,
I'm running libvirt 1.0.2 on one host (Ubuntu 12.04), and
virt-manager/virt-viewer on another (FC18), and using TLS to secure the
comm's between the hosts. I was able to get virt-manager to connect the
the hypervisor host via qemu+tls method, but virt-viewer will not
connect (either invoked from the "Show the graphical console" option on
virt-manager's VM window, or by invoking virt-viewer directly.) Both
fail with a generic error (virt-manager's view console says "viewer
connection to hypervisor host got refused or disconnected") but does not
give a more explicit error. I did a tcpdump, and the trace does show the
client machine connecting to TCP port 16514 on the hypervisor host,
which is owned by the libvirtd daemon. From what I can see in the
packets from that dump, it looks like the endpoints are exchanging
certificate info, but of course the session is encrypted, so can't
really see what else is going on... Is there a way someone can give me
to debug the communications for either the client or server side?
(There's nothing being written to logs as far as I can see.)
Thanks,
Will
11 years, 9 months
[libvirt-users] Live external snapshot coalescing
by Skardal, Harald
On standard Fedora 18 I was attempting blockcommit on a *live* VM,
libvirt said it was not supported, so I tried fedora-virt-preview as
recommended.
We found a problem with qemu 1.4, there seems to be an acknowledged bug,
a missing library.
On a different system we loaded Fedora 18, and then pulled qemu (1.3)
and libvirt (1.0.2) from rawhide.
I tried blockcommit with domain shut down, it said must be up. Started
the domain, and voila, it seems to have worked.
Question:
The committed snap file (the one I committed to the image below) is
still in there, and virsh snapshot-list lists it.
But the base and the upstream snap file has been updated, the upstream
snap file points to the base image as per qemu-img info.
How/where do I update the metadata so that virsh displays the correct
thing? I.e. the committed snapshot should disappear?
Is it as simple as removing the committed snap? Do I have to restart
anything to get the virsh output correct?
Cheers,
Harald Skardal,
Stratus Technologies.
11 years, 9 months
[libvirt-users] Fwd: OpenVSwitch and libvirt integration problem at shutdown/reboot
by Ernesto Domato
Hi everyone, I'm forwarding this mail that I wrote to OpenVSwitch dev
list because I think that you could maybe help me a little :-)
What did you think about the patch to libvirt that I'm using?. At
least, it worked for me :-)
Thanks.
Ernesto
---------- Forwarded message ----------
From: Ernesto Domato <edomat(a)gmail.com>
Date: Mon, Mar 4, 2013 at 2:09 PM
Subject: OpenVSwitch and libvirt integration problem at shutdown/reboot
To: dev(a)openvswitch.org
Hi everyone, this mail is related to a bug report that I did on Debian
(#701760) that I wasn't able to resolve yet and want to know if
someone has the same problem and how could I fix it.
The problem that I'm having is that on shutdown/reboot of the machine
that holds the virtual machines that use OVS, the OVS-Switch is going
down before libvirt finish to shutdown the VMs.
This cause that libvirt can¡t unregister the virtual interface from
the OVS-Switch and it hangs the shutdown/reboot process. The only way
that I have to solve this at that point is to log in by SSH and
restart the OVS-Switch so libvirt can finish unregistering the
interfaces and the system continue with the task asked.
What I tried too is to patch the libvirt to use the --no-wait flag for
ovs-vsctl command that deletes the virtual interface so it doesn't
hang when OVS-Switch isn't running. It worked on the sense that the
system does shutdown/reboot but next time it boot, the VMs stop
responding, I have to delete the virtual interface from OVS-Switch and
register it again and then the VM start responding again. I guess that
this happens because the virtual interface was never deleted from
OVS-DB and when the system boots again there's like an old reference
to the virtual interface that provoke this behavior.
Have anyone had this problem?, how did you solve it?, what your
suggestion for me?.
Looking at the manpages, I'll try another patch for libvirt that will
delete the interface with the flag --if-exists before adding it back
on libvirt start of the VM so, if the OVS-DB already has the
interface, it is deleted. If this works, do you think it's a good
solution?, or should it be implemented in other ways?.
Thanks for all and excuse my english but it's not my native language.
Ernesto
11 years, 9 months
[libvirt-users] Qemu-1.4.0-2 and Qemu-1.4.0-1 is broken on virt-preview and rawhide
by Skardal, Harald
All,
Our testing seems to indicate that Qemu-1.4.0-2 and Qemu-1.4.0-1 is
broken on virt-preview and rawhide.
I'm getting undefined symbol: usbredirparser_send_start_bulk_receiving
when running qemu-system-x86_64 -version..
Do others see this issue? Is there a known solution?
Harald
Failing cases:
------------------------------------------------------------------------
--------------------------------------
Failed on Qemu-1.4.0-2
----------------------
[root@node1 ~]# rpm -q --file /usr/bin/qemu-system-x86_64
qemu-system-x86-1.4.0-2.fc18.x86_64
[root@node1 ~]# /usr/bin/qemu-system-x86_64 --version
/usr/bin/qemu-system-x86_64: symbol lookup error:
/usr/bin/qemu-system-x86_64: undefined symbol:
usbredirparser_send_start_bulk_receiving
Failed on Qemu-1.4.0-1
----------------------
[root@localhost ~]# rpm -q --file /usr/bin/qemu-system-x86_64
qemu-system-x86-1.4.0-1.fc18.x86_64
[root@localhost ~]# /usr/bin/qemu-system-x86_64 --version
/usr/bin/qemu-system-x86_64: symbol lookup error:
/usr/bin/qemu-system-x86_64: undefined symbol:
usbredirparser_send_start_bulk_receiving
------------------------------------------------------------------------
--------------------------------------
Passed on Qemu-1.3.0-9
----------------------
[root@node0 ~]# rpm -q --file /usr/bin/qemu-system-x86_64
qemu-system-x86-1.3.0-9.fc18.x86_64
[root@node0 ~]# /usr/bin/qemu-system-x86_64 --version
QEMU emulator version 1.3.0, Copyright (c) 2003-2008 Fabrice Bellard
11 years, 9 months
[libvirt-users] Secure communication from host to guest
by Shea Levy
Hi,
On boot, I'd like to pass a public key to the VM to use for root ssh
logins, and obviously only the user that started the VM on the host
should be able to send the key. What's the best way to pass this kind of
information into the VM? I thought about using a serial port connected
to a fifo on the host, but I'd rather not deal with serial programming
if I can avoid it...
Thanks,
Shea
11 years, 9 months
[libvirt-users] VM can not start
by Qinghua Cheng
Hi Experts,
I have libvirt 1.0.2 downloaded and build on my RH. And I also
downloaded qemu 1.4.0 and build on this machine.
When I tried to start my VM ubuntu12, get error messages:
error: Failed to start domain ubuntu12
error: internal error Process exited while reading console log output:
I have no idea what does this message mean. Could you please help point
out what I should do next?
Thanks,
Conny
11 years, 9 months
