Re: [libvirt] Xen network interface behavior with 0.6.2

On Mon, Apr 20, 2009 at 12:58:57PM -0700, Kaitlin Rupert wrote: > Daniel P. Berrange wrote: > >On Mon, Apr 20, 2009 at 12:06:16PM -0700, Kaitlin Rupert wrote: > >>Daniel P. Berrange wrote: > >>>On Fri, Apr 17, 2009 at 01:29:12PM -0700, Kaitlin Rupert wrote: > >>>>Hi, > >>>> > >>>>I'm using libvirt 0.6.2 to create a Xen guest with a network type > >>>>interface (see XML below). When the guest is defined, the interface is > >>>>converted to an ethernet type interface. If the guest is started, the > >>>>interface is then converted to a bridge type interface. > >>>This sounds bad :-) Can you provide the output of 'xm list --long > >>>hd_domain' > >>>immediately after defining it, and then again immediately after starting > >>>the guest. > >>> > >>Here's the whole create process. Probably more than you needed, but > >>included for clarity ;) > >> > >> > >># virsh list --all > >> Id Name State > >>---------------------------------- > >> 0 Domain-0 running > >> > >># virsh define hd_domain > >>Domain hd_domain defined from hd_domain > >> > >># xm list --long hd_domain > >>Error: Domain 'hd_domain' does not exist. > >>Usage: xm list [options] [Domain, ...] > >> > >>List information about all/some domains. > >> -l, --long Output all VM details in SXP > >> > >> --label Include security labels > > > >I guess you muyst be using an old Xen without inactive domain > >support ? Would this be RHEL-5 Xen by chance ? If so, can you > >also provide the /etc/xen/$GUESTNAME config file at this point > > Yes, this is with RHEL 5 - I meant to mention that in my original mail. > > # cat /etc/xen/hd_domain > name = "hd_domain" > uuid = "f99fd6b6-1434-4bc2-88e0-1ed9c8c6f8e9" > maxmem = 128 > memory = 128 > vcpus = 1 > kernel = "/tmp/default-xen-kernel" > ramdisk = "/tmp/default-xen-initrd" > on_poweroff = "destroy" > on_reboot = "restart" > on_crash = "destroy" > vfb = [ "type=vnc,vncunused=1,vnclisten=127.0.0.1,keymap=en-us" ] > disk = [ "file:/tmp/default-xen-dimage,xvda,w" ] > vif = [ "mac=00:11:22:33:44:aa" ] So its obvious what the problem is here - we're not writing out any bridge info at all. Turns out this chunk of code was just plain missing This patch makes sure that we write the correct info the /etc/xen config file. This will make sure it at least shows up as type=bridge.

The harder bit is to make it correctly round-trip, so it shows up as type=network again. This particular aspect has never worked in the Xen driver and will be a more involved fix. We need to add an API to translate froma bridge device name back to a virNetworkPtr object, otherwise its just horribly inefficient. THis will have to wait till next release.