Xen devel - Jul 2004 - Inconsistent domain parameter passed to vif-bridge

It seems that the "domain" parameter passed to the vif-bridge script
isn''t always consistent.  When calling "vif-bridge up",
domain refers to
the name assigned to the domain.  When "vif-bridge down" is called,
domain is of the form "DOM<n>", where <n> is the numeric
identifier for
the domain.

This is a problem since I''m using modifying the vif-bridge script for a
different network configuration, and was encoding the vmid used when
creating the domain into the domain''s name.  The vmid is then used in
configuring network settings.  This works fine when bringing the network
up, but I have trouble when bringing the network down--specifically, I
want to remove a firewall rule, but need to know the vmid to specify the
firewall rule to delete.

Passing the name seems a more useful behavior to me, or perhaps both
name and id should be supplied to vif-bridge.  In any case, the current
behavior (different for up and down) seems broken.

So far I''ve tracked the problem as far as noticing that NetDev.destroy
in python/xen/xend/server/netif.py isn''t passed the name of the domain,
but I haven''t figured out how to best fix this.  I''m willing
to work on
it a bit; any suggestions for how to approach it?

--Michael Vrable


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> It seems that the "domain" parameter passed to the vif-bridge
script
> isn''t always consistent.  When calling "vif-bridge up",
domain refers to
> the name assigned to the domain.  When "vif-bridge down" is
called,
> domain is of the form "DOM<n>", where <n> is the
numeric identifier for
> the domain.
Oops -- that''s a bug not a feature.

We probably should be making both the name and the domid
available to the script anyhow. 
> So far I''ve tracked the problem as far as noticing that
NetDev.destroy
> in python/xen/xend/server/netif.py isn''t passed the name of the
domain,
> but I haven''t figured out how to best fix this.  I''m
willing to work on
> it a bit; any suggestions for how to approach it?
Mike would be the best person to fix this, but he''s on holiday
for a week. Any takers?

Ian






-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Sat, Jul 31, 2004 at 12:16:10PM +0100, Ian Pratt
wrote:
> > It seems that the "domain" parameter passed to the
vif-bridge script
> > isn''t always consistent.  When calling "vif-bridge
up", domain refers to
> > the name assigned to the domain.  When "vif-bridge down" is
called,
> > domain is of the form "DOM<n>", where <n> is the
numeric identifier for
> > the domain.
> 
> Oops -- that''s a bug not a feature.
> 
> We probably should be making both the name and the domid
> available to the script anyhow. 
> 
> > So far I''ve tracked the problem as far as noticing that
NetDev.destroy
> > in python/xen/xend/server/netif.py isn''t passed the name of
the domain,
> > but I haven''t figured out how to best fix this.  I''m
willing to work on
> > it a bit; any suggestions for how to approach it?
> 
> Mike would be the best person to fix this, but he''s on holiday
> for a week. Any takers?
I took a closer look at the problem this week and came up with a fix.
My approach for now is to store the domain name as well as the domain ID
in the Controller instance for the domain''s network interfaces.  Right
now I have the code structured so that the domain name can be made
available to block devices, console devices, etc., but I only have
everything implemented for network devices.

I don''t know if this is the best approach to take.  I also considered
making the full XendDomainInfo object available, but decided for now
just to pass the name along.

Preliminary patch is attached, but it shouldn''t be applied because
I''d
at least like to do some other cleanup first.  Plus, it might be decided
that another approach is better.  But it works for me.

--Michael Vrable