RE: [libvirt] Re: [et-mgmt-tools] Virt-Manager, libvirt & TLS

Hi Daniel; Thanks for the quick response and for your help, this is working now. If you are interested in the gory details they are detailed below, at least I'll document them here for the sake of others on the list. See "Gory Details - start" While I have your attention I have another question if you don't mind. I have done all this because I wanted to see if I could use virsh to live migrate a VM between physical hosts. Actually I wanted to use libvirt but virsh is my easiest way to talk to libvirt. My two physical xen servers are connecting to the same iSCSI SAN LUN formatted and mounted with ocfs2. I have a PV vm residing on the LUN (centos 5.1 - 2.6.8.18-xen). If I use standard xen config files and don't "define" my guest using virsh (xml) I can use the XM commands to migrate without any trouble. If I try to "define" the guest and then use XM to migrate it everything gets confused. So I thought I would "define" the guest and then try to use virsh to migrate. The same confusion takes place. I just did this and got some weird behaviour. I started the VM "centpv" up on host2 and then asked it to migrate to host1 using virsh from the (now working) client. The migration worked as expected. I was able to disconnect my VNC connection to the VM on host2 and connect it to the machine on host1. This where it gets weird. Host2 (Source) virsh # list --all Id Name State ---------------------------------- 0 Domain-0 running - centpv shut off - xi-ad-01 shut off - xi3mps01h shut off Host 1 (destination) virsh # list --all Id Name State ---------------------------------- 0 Domain-0 running 1 centpv blocked As you can see centpv is now listed on both machines. The state on host2 is shutoff which is technically correct. The VM is actually running on host 1. Host 1 has it as running. If you look at virt-manager you get an even more confusing story. Host1 says that centpv is "shutoff" until you highlight the machine then it says its running, and it quickly switches to saying it's shutoff. Host 2 claims the machine is still running. Killing virt-manager and re spawning it helps somewhat in that now host1 knows the machine is running. Host 2 thinks its shutdown. (Reflecting what is listed by virsh). The next thing I did was to "virsh undefine centpv" from host2. That also worked. Now all is right with the world. How can I find out more about how the "define" command works? (read the source code?) If the machine is "defined" doesn’t this place a hard entry in the local xenstore on the Xen machine on which it was defined?. I have to go read up on xenstore as I'm not that familiar with it yet. Do we need to migrate and then undefine the machine once the machine lands at the destination? Finally could these issues be related to the way virsh handles the libvirt "migrate" or is this a problem with libvirt? My next plan is to work up a python script that will talk directly to libvirt and execute a migration. This will take me some time as I don't know python... but let's see what happens. In the interest of time (and my sanity) does anyone have any basic python script that talk directly to libvirt that they would be willing to share? Thanks in advance. Gory Details - start. Your suggestion to use Virsh in the first instance was key. libvir: QEMU error : internal error cannot create bridge 'virbr0' : File exists So I checked iptables and despite the fact that I don't remember configuring it, there were rules present. I think libvirtd does some stuff to iptables. After shutting down iptables and kicking the libvirtD I stopped getting that error. Now both virsh and virt-manager are working using TLS. Strangely the URI I had to use for virt-manager and virsh were different. Virt-manager URI = xen://vxen-01.domain.com Virsh URI = xen://vxen-01.domain.com/ Virsh needed the trailing "/". Without it I get console messages (on the server) that say "libvir: error : invalid argument in could not parse connection URI". I have typed it exactly, that grammar problem is not a typo, that's what it says. Best Regards -----Original Message----- From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf Of Daniel P. Berrange Sent: 24 July 2008 12:19 To: Fedora/Linux Management Tools Cc: libvir-list(a)redhat.com Subject: [libvirt] Re: [et-mgmt-tools] Virt-Manager, libvirt & TLS On Thu, Jul 24, 2008 at 11:13:28AM +0100, Geoff Wiener wrote: That's all fine. That's fine - any CA will do the job. No need to uncomment any of these - its fine to use the the default settings built-in to libvirt Ok, no problem there. I'd recommend getting it working using virsh as a client first - this gives clearer diagnostics. Once virsh is working, then virt-manager should just work too, although it has an extra step required for VNC access. Yes, the CA certificate needs to be on all machines - in the same location as for the server - /etc/pki/CA/cacert.pem. The client server needs to be in the loication /etc/pki/libvirt/clientcert.pem There are some additional docs on the virt-manager wiki about the VNC setup steps too http://virt-manager.org/page/RemoteTLS Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list