March 2013 - Users - libvirt List Archives

[libvirt-users] Debugging TLS connection between virt-viewer and libvirt running on separate hosts
by Will Dennis 05 Mar '13

05 Mar '13

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

1 0

[libvirt-users] Live external snapshot coalescing
by Skardal, Harald 05 Mar '13

05 Mar '13

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.

3 2

[libvirt-users] Fwd: OpenVSwitch and libvirt integration problem at shutdown/reboot
by Ernesto Domato 04 Mar '13

04 Mar '13

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

2 1

[libvirt-users] Qemu-1.4.0-2 and Qemu-1.4.0-1 is broken on virt-preview and rawhide
by Skardal, Harald 04 Mar '13

04 Mar '13

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

2 1

[libvirt-users] Secure communication from host to guest
by Shea Levy 02 Mar '13

02 Mar '13

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

2 1

[libvirt-users] VM can not start
by Qinghua Cheng 01 Mar '13

01 Mar '13

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

2 2