[libvirt] Xen network interface behavior with 0.6.2

Daniel P. Berrange berrange at redhat.com
Fri Apr 24 09:42:01 UTC 2009


On Thu, Apr 23, 2009 at 06:29:03PM +0200, Daniel Veillard wrote:
> On Thu, Apr 23, 2009 at 02:20:16PM +0100, Daniel P. Berrange wrote:
> > 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.
> 
>   ACK
> 
> > 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.
> 
>   Okay, another thing I noticed in the patch is that the default bridge
> name prefix is different on Solaris, what happen there on "make check" ?

This will almost certainly fail make check on Solaris. That said the
existing XenD XML -> SEXPR tests will also fail for same reason, so it'd
not be making it significantly worse. I need to figure  out a solution 
for this somehow...

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 :|




More information about the libvir-list mailing list