Xen users - Nov 2007 - Slackware 12 DomU NIC increments on each start

Hi,

Just wondering if anyone can help shed some light on a problem I''m
facing. I''ve got a whole bunch of Xen machines working just fine
already. Recently I''ve been testing procedures for "P2V" -
just taking
an existing Linux system and converting it over to a Xen VM.

So - I have a Slackware 12.0 system running. I used rsync to copy the
system over to a partition on an already running Xen system with several
guests running. I just copied everything over apart from /proc and /sys.
I used my standard, "nothing special" Xen configuration file - pretty
much all the default settings (vif = [ '''' ], etc) apart from I
change
which disk partition I''m going to run from. Simple enough.

The problem is that networking doesn''t work properly. Each time I
shutdown and restart, the NIC increments... eth0, eth1, eth2... I''m on
eth12 right now! Once the system starts I can use ifconfig & route to
assign an IP and a default gateway, and I get a network connection.
Weird stuff.

Does anyone have any ideas what is going on / what I need to do? I just
want my nice eth0...

Tia.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Fri Nov 16, 2007 at 13:21:58 -0000, Russell Packer wrote:
> The problem is that networking doesn''t work properly. Each time I
> shutdown and restart, the NIC increments... eth0, eth1, eth2...
I''m on
> eth12 right now! Once the system starts I can use ifconfig & route to
> assign an IP and a default gateway, and I get a network connection.
> Weird stuff.
> 
> Does anyone have any ideas what is going on / what I need to do? I just
> want my nice eth0...
  This is almost certainly udev being "helpful".

  If you don''t have a special vif line each time your guest will
 receive a new MAC address for the nic.  The first time it boots
 udev will think "Hmmmm MAC xxxx thats new.  I''ll call that
eth0".

  The next time you boot you''ll have a different MAC address so
 udev thinks "Hmmm this is new!  I''ll call this eth1 in case that
other
 one comes back...".

  Solution:  Setup a static MAC address in your Xen configuration
 file with something like:

    vif = ['' mac=aa:bb:cc:dd::ee::ff'' ]

  Once you''ve done that you can remove the stored mac addresses
 from /etc/udev/rules.d/ and all will be well.

  Failing that you could have random MAC addresses and just delete
 the relevant udev files. I  guess they will be called something like
 persistent-net-generator..

Steve
-- 
# The Debian Security Audit Project.
http://www.debian.org/security/audit


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

>   Solution:  Setup a static MAC address in your Xen configuration
>  file with something like:
>
>     vif = ['' mac=aa:bb:cc:dd::ee::ff'' ]
>
>   Once you''ve done that you can remove the stored mac addresses
>  from /etc/udev/rules.d/ and all will be well.
>

Aaaah - Please can this be stuck in a FAQ somewhere? I got up to eth5
before I managed to get back to sanity on my 1st Xen server....


Thanks for the udev rules cleanup tho - will make life simpler i it
ever happens again



Andrew

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Fri, 16 Nov 2007, Steve Kemp wrote:
> On Fri Nov 16, 2007 at 13:21:58 -0000, Russell Packer wrote:
>
>> The problem is that networking doesn''t work properly. Each
time I
>> shutdown and restart, the NIC increments... eth0, eth1, eth2...
I''m on
>> eth12 right now! Once the system starts I can use ifconfig & route
to
>> assign an IP and a default gateway, and I get a network connection.
>> Weird stuff.
>>
>> Does anyone have any ideas what is going on / what I need to do? I just
>> want my nice eth0...
>
>  This is almost certainly udev being "helpful".
I suspect it''s kudzu ... which IMHO is not really appropriate on domUs
and
should be disabled, but I don''t like/trust automagic... With kudzu
turned
off (chkconfig kudzu off) and making sure there is no MAC= line in your 
/etc/sysconfig/network-scripts/ifcfg-eth0 file, you should be ok even if 
the mac address is changing.... at least this is true for my old and new 
redhat based systems. -Tom


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hi all,

just a little proposal ;)

2007/11/16, Tom Brown
<xensource.com@vmail.baremetal.com>:
> On Fri, 16 Nov 2007, Steve Kemp wrote:
>
> > On Fri Nov 16, 2007 at 13:21:58 -0000, Russell Packer wrote:
> >
> >> The problem is that networking doesn''t work properly.
Each time I
> >> shutdown and restart, the NIC increments... eth0, eth1, eth2...
I''m on
> >> eth12 right now! Once the system starts I can use ifconfig &
route to
> >> assign an IP and a default gateway, and I get a network
connection.
> >> Weird stuff.
> >>
> >> Does anyone have any ideas what is going on / what I need to do? I
just
> >> want my nice eth0...
> >
> >  This is almost certainly udev being "helpful".
>
> I suspect it''s kudzu ... which IMHO is not really appropriate on
domUs and
> should be disabled, but I don''t like/trust automagic... With kudzu
turned
> off (chkconfig kudzu off) and making sure there is no MAC= line in your
> /etc/sysconfig/network-scripts/ifcfg-eth0 file, you should be ok even if
> the mac address is changing.... at least this is true for my old and new
> redhat based systems. -Tom
I posted about this like half a year ago, and still think it would be
the best if there was
some xen magic to save back the GUID and MAC autogenerated on first
startup into the
domU config.
it might not be the right way to mess with the domU conf file, but
maybe someone has a more elegant idea, still it''d be best if they only
got auto-generated once and be committed "somewhere" automatically.
back on Xen2 i still generated the MAC addresses manually, but ever
since a valid mac specification is valid people trip over this as it
just seems unnatural *unless* you know how xen currently handles it. I
think in the long run it''d be better to handle it the way anyone would
expecpt it. "if it can generate it, then why can''t it remember
it?"

florian


-- 
''Sie brauchen sich um Ihre Zukunft keine Gedanken zu machen''

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Florian Heigl wrote:
> Hi all,
>
> just a little proposal ;)
>
> 2007/11/16, Tom Brown <xensource.com@vmail.baremetal.com>:
>   
>> On Fri, 16 Nov 2007, Steve Kemp wrote:
>>
>>     
>>> On Fri Nov 16, 2007 at 13:21:58 -0000, Russell Packer wrote:
>>>
>>>       
>>>> The problem is that networking doesn''t work properly.
Each time I
>>>> shutdown and restart, the NIC increments... eth0, eth1, eth2...
I''m on
>>>> eth12 right now! Once the system starts I can use ifconfig
& route to
>>>> assign an IP and a default gateway, and I get a network
connection.
>>>> Weird stuff.
>>>>
>>>> Does anyone have any ideas what is going on / what I need to
do? I just
>>>> want my nice eth0...
>>>>         
>>>  This is almost certainly udev being "helpful".
>>>       
>> I suspect it''s kudzu ... which IMHO is not really appropriate
on domUs and
>> should be disabled, but I don''t like/trust automagic... With
kudzu turned
>> off (chkconfig kudzu off) and making sure there is no MAC= line in your
>> /etc/sysconfig/network-scripts/ifcfg-eth0 file, you should be ok even
if
>> the mac address is changing.... at least this is true for my old and
new
>> redhat based systems. -Tom
>>     
>
> I posted about this like half a year ago, and still think it would be
> the best if there was
> some xen magic to save back the GUID and MAC autogenerated on first
> startup into the
> domU config.
>   
It''s possible to run "xm list --long [DOMAIN]" to extract
them. It''s
better to preset them, if possible, to avoid conflicts among a large 
cluster of guest domains. Some tools, like virt-install from RedHat, can 
prescribe MAC addresses. But I wanted the vifname too, to make MRTG 
network monitoring report the same interface consistently the last time 
I did this, and wound up writing a little wrapper to hardcode those.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Fri November 16 2007 8:21:58 am Russell Packer wrote:
> So - I have a Slackware 12.0 system running. I used rsync to copy the
> system over to a partition on an already running Xen system with several
> guests running. I just copied everything over apart from /proc and /sys.
> I used my standard, "nothing special" Xen configuration file -
pretty
> much all the default settings (vif = [ '''' ], etc) apart
from I change
> which disk partition I''m going to run from. Simple enough.
As mentioned by other knowledgeable people on this list, try assigning a mac 
address to your virtual card: vif = [ ''mac=00:16:3e:xx:xx:xx, 
script=vif-whatever, bridge = your-choice'' ] .

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Another try...
please note i do not intent to offend single people giving the below
advice, but just try to wake up the hand-typing mac=xx:xx: fraction of
xen gurus on this list. The very question below has probably come up
dozens to hundreds of times over the last years and I feel sad a large
number of people still thinks it''s a good thing to live with.[1]

2007/11/23, jim burns <jim_burn@bellsouth.net>:
> On Fri November 16 2007 8:21:58 am Russell Packer wrote:
> > So - I have a Slackware 12.0 system running. I used rsync to copy the
> > system over to a partition on an already running Xen system with
several
> > guests running. I just copied everything over apart from /proc and
/sys.
> > I used my standard, "nothing special" Xen configuration file
- pretty
> > much all the default settings (vif = [ '''' ], etc)
apart from I change
> > which disk partition I''m going to run from. Simple enough.
>
> As mentioned by other knowledgeable people on this list, try assigning a
mac
> address to your virtual card: vif = [ ''mac=00:16:3e:xx:xx:xx,
> script=vif-whatever, bridge = your-choice'' ] .
...There''s about 20 auto-assignment scripts floating
And some people found the guid/mac-querying from xm list --long and
hacked something around that.

But what''s it with understanding that 20 different wheels will never
run as smooth as 4 round ones?

This is a functionality best placed with Xen
- as half of it is already there
- as xend is the best thing to query other members in
clustered/load-balanced setups
- as there is NO point in everyone being asked to handle it manually
or hack scripts
- as it will save time for everyone.

Please try to see my point, there are some people trying to use Xen
for more than a dev box and I''m getting really desparate seeing how a
load of topics for advanced deployment are generally being put off,
just because it [editing by hand] works nicely while you only handle
3-20 domUs, plus it''s even a waste of energy for one single domU.
And I don''t think pointing yet another person at a hack (manually
setting MAC or having a script autoincrement it) that had already
grown a beard when Xen 2.0.1 was still hot makes any sense.


Florian

[1] Yes... I know a lunatic was defined as a minority of one.

-- 
''Sie brauchen sich um Ihre Zukunft keine Gedanken zu machen''

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Florian Heigl wrote:
> Another try...
> please note i do not intent to offend single people giving the below
> advice, but just try to wake up the hand-typing mac=xx:xx: fraction of
> xen gurus on this list. The very question below has probably come up
> dozens to hundreds of times over the last years and I feel sad a large
> number of people still thinks it''s a good thing to live with.[1]
>
> 2007/11/23, jim burns <jim_burn@bellsouth.net>:
>   
>> On Fri November 16 2007 8:21:58 am Russell Packer wrote:
>>     
>>> So - I have a Slackware 12.0 system running. I used rsync to copy
the
>>> system over to a partition on an already running Xen system with
several
>>> guests running. I just copied everything over apart from /proc and
/sys.
>>> I used my standard, "nothing special" Xen configuration
file - pretty
>>> much all the default settings (vif = [ '''' ], etc)
apart from I change
>>> which disk partition I''m going to run from. Simple enough.
>>>       
>> As mentioned by other knowledgeable people on this list, try assigning
a mac
>> address to your virtual card: vif = [ ''mac=00:16:3e:xx:xx:xx,
>> script=vif-whatever, bridge = your-choice'' ] .
>>     
>
> ...There''s about 20 auto-assignment scripts floating
> And some people found the guid/mac-querying from xm list --long and
> hacked something around that.
>
> But what''s it with understanding that 20 different wheels will
never
> run as smooth as 4 round ones?
>
> This is a functionality best placed with Xen
> - as half of it is already there
> - as xend is the best thing to query other members in
> clustered/load-balanced setups
> - as there is NO point in everyone being asked to handle it manually
> or hack scripts
> - as it will save time for everyone.
>
> Please try to see my point, there are some people trying to use Xen
> for more than a dev box and I''m getting really desparate seeing
how a
> load of topics for advanced deployment are generally being put off,
> just because it [editing by hand] works nicely while you only handle
> 3-20 domUs, plus it''s even a waste of energy for one single domU.
> And I don''t think pointing yet another person at a hack (manually
> setting MAC or having a script autoincrement it) that had already
> grown a beard when Xen 2.0.1 was still hot makes any sense.
>
>
> Florian
>
> [1] Yes... I know a lunatic was defined as a minority of one.
>   
You''ve a reasonable point. I don''t know what the commercial
Xensource
tools do about this: Some system tools, like "virt-install" in RHEL, 
will allow you to hard-code the MAC address at run-time. This is handy. 
Unfortunately, that tool does not allow you to set other useful 
characteristics, like multiple disk images or a hard-coded vifname. We 
seem to see a big divorce between the capabilities of the modest 
freeware tools (like virt-install) and the commercial grade ones, such 
as the fairly expensive RHN tool suite from RedHat.

Is anyone out there using the Xensource tools? Do they have these 
capabilities?

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hi Florian,

On Sat, Nov 24, 2007 at 01:22:24AM +0100, Florian Heigl wrote:

[MAC address selection]
> This is a functionality best placed with Xen
> - as half of it is already there
> - as xend is the best thing to query other members in
> clustered/load-balanced setups
> - as there is NO point in everyone being asked to handle it manually
> or hack scripts
> - as it will save time for everyone.
I''d be happy with that as long as there is still a way to override
it.  I have more than one dom0 on the same LAN so I need to keep my
MAC address assignments in a database.  In theory one dom0 could be
made to query all others, but I see the open source version of Xen
to be just one (admittedly major) building block of a larger system
and it does not need to do everything.

Cheers,
Andy


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hi Andy,

2007/11/24, Andy Smith <andy@strugglers.net>:
> Hi Florian,
>
> On Sat, Nov 24, 2007 at 01:22:24AM +0100, Florian Heigl wrote:
>
> [MAC address selection]
>
> > This is a functionality best placed with Xen
> > - as half of it is already there
> > - as xend is the best thing to query other members in
> > clustered/load-balanced setups
> > - as there is NO point in everyone being asked to handle it manually
> > or hack scripts
> > - as it will save time for everyone.
>
> I''d be happy with that as long as there is still a way to override
> it.  I have more than one dom0 on the same LAN so I need to keep my
> MAC address assignments in a database.  In theory one dom0 could be
> made to query all others, but I see the open source version of Xen
> to be just one (admittedly major) building block of a larger system
> and it does not need to do everything.
I agree on both points...
The easiest thing would be to have a "pluggable" script like, for
example, xen-block or network-bridge are called, or the way you select
different loaders in the domU config.

one could simply define mac_handling = auto

Having this script replacable would allow for useful extensions - i.e.
if someone uses dom0 firewalling for egress filtering the dom0 could
do an actual first dhcprequest and set up firewalling before the
(untrusted) domU is launched - just an example.

i''d say it''s a good job for xend''s to handle as with
loadbalancing or
some other features the amount of dom0-dom0 xmlrpc communications will
probably increase anyway.
my feeling is the current approach is half-baked ... "if it generates
it, it should deal with it, too"

but easy management of such a feature (enable/disable, replace and
influence it''s options) is definitely crucial, on the other hand i
think thats easy enough to accomplish

one could start with
mac_handler=/path/to/the/script/that/already/does/the/autogeneration
vif [ ''bridge=xxx'',''mac=auto,persistent'' ]

then you can have scripts with backend support (xend, a textfile, a
database table from Enomalism), without backend support, with extra
functions (like the dhcp+firewall) example, and so on without changing
standard behaviour.


regards,
florian


-- 
''Sie brauchen sich um Ihre Zukunft keine Gedanken zu machen''

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users