Xen devel - Nov 2005 - Is it possible to disable vif completely?

Now I''m enabling multiple domain support on IA64 (Once again, though
working one month ago). The issue what I''m seeing now is:
	"xm create -c" doesn''t return with error in createDevices()
and
thus all subsequent xm commands don''t return.

My work based on xen-ia64-unstable identical to Rev 7646 on
xen-unstable.hg ("Fix pagetable pinning logic for xen/i386 kernels.").
However xend/xm works well two weeks ago identical to Rev 7483 on
xen-unstable ("Added a timestamp to the logging output by trace_io").

After killing above thread and check /var/log/xend.log, which warns
"Device (vif) could not be connected. Hotplug scripts not working".
What''s the necessary environmental setting to support said hotplug
scripts? Any special requirement happens between these two weeks?

Actually I saw that "xm create -c" thread pending on select() when
createDevices() and seems the issue coming from synchronization issue
between main thread and device controller thread. Current the vnif
backend/frontend doesn''t work for ia64 yet, so is there easy way to
disable vnif setup completely, thus to let us bypass this issue now?
Then we can focus on vbd stuff first...

Thanks,
Kevin

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

Ooops, I also saw "Device (vbd) could not be connected" warning. So
seems that this issue can''t be bypassed. After looking in the list,
seems that some people are claiming udevd is a must now, is that right?
(Anything more?) If yes, why is there no check upon udevd when installing tools,
like for brctrl, etc? I think it''s better to check whether all required
tools installed before running xend/xm...

Thanks,
Kevin
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Tian, Kevin
>Sent: 2005年11月8日 21:14
>To: xen-devel@lists.xensource.com
>Subject: [Xen-devel] Is it possible to disable vif completely?
>
>Now I''m enabling multiple domain support on IA64 (Once again,
though
>working one month ago). The issue what I''m seeing now is:
>	"xm create -c" doesn''t return with error in
createDevices() and
>thus all subsequent xm commands don''t return.
>
>My work based on xen-ia64-unstable identical to Rev 7646 on
>xen-unstable.hg ("Fix pagetable pinning logic for xen/i386
kernels.").
>However xend/xm works well two weeks ago identical to Rev 7483 on
>xen-unstable ("Added a timestamp to the logging output by
trace_io").
>
>After killing above thread and check /var/log/xend.log, which warns
>"Device (vif) could not be connected. Hotplug scripts not
working".
>What''s the necessary environmental setting to support said hotplug
>scripts? Any special requirement happens between these two weeks?
>
>Actually I saw that "xm create -c" thread pending on select() when
>createDevices() and seems the issue coming from synchronization issue
>between main thread and device controller thread. Current the vnif
>backend/frontend doesn''t work for ia64 yet, so is there easy way to
>disable vnif setup completely, thus to let us bypass this issue now?
>Then we can focus on vbd stuff first...
>
>Thanks,
>Kevin
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Nov 08, 2005 at 09:13:45PM +0800, Tian, Kevin wrote:
> Now I''m enabling multiple domain support on IA64 (Once again,
though
> working one month ago). The issue what I''m seeing now is:
> 	"xm create -c" doesn''t return with error in
createDevices() and
> thus all subsequent xm commands don''t return.
> 
> My work based on xen-ia64-unstable identical to Rev 7646 on
> xen-unstable.hg ("Fix pagetable pinning logic for xen/i386
kernels.").
> However xend/xm works well two weeks ago identical to Rev 7483 on
> xen-unstable ("Added a timestamp to the logging output by
trace_io").
> 
> After killing above thread and check /var/log/xend.log, which warns
> "Device (vif) could not be connected. Hotplug scripts not
working".
> What''s the necessary environmental setting to support said hotplug
> scripts? Any special requirement happens between these two weeks?
There is a bug here that is fixed in 7651.  You ought to be on that changeset
at the least.  A lot of ia64 patches went in today, so you probably want to
look at those too.

Ewan.

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

On Tue, Nov 08, 2005 at 09:28:50PM +0800, Tian, Kevin wrote:
> Ooops, I also saw "Device (vbd) could not be connected" warning.
So seems
> that this issue can''t be bypassed. After looking in the list,
seems that
> some people are claiming udevd is a must now, is that right? (Anything
> more?) If yes, why is there no check upon udevd when installing tools, like
> for brctrl, etc? I think it''s better to check whether all required
tools
> installed before running xend/xm...
As I understand it, you need udevd >= 059, or hotplug otherwise.  If you want
to write a check for that, that would be great.

Ewan.

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

Hi, Ewan,
	Thanks for suggestion. However nothing changed after pull your Rev 7651 in. I
still see following message:
	" Device 0 (vif) could not be connected. Hotplug scripts not working"

	However actually the hotplug works on my target system. You can see from
following xenstore info that vbd backend has been connected successfully:

   backend = ""
    vbd = ""
     1 = ""
      769 = ""
       domain = "ExampleDomain3"
       params = "loop0"
       frontend-id = "1"
       type = "phy"
       dev = "hda1"
       frontend = "/local/domain/1/device/vbd/769"
       physical-device = "0x0700"
       node = "/dev/loop0"
       hotplug-status = "connected"	<<<<<<<
   error = ""
    backend = ""
     vbd = ""
      1 = ""
       769 = ""
        error = "2 reading /local/domain/1/device/vbd/769/ring-ref and
event-channel"
^^^^(That error comes from that blkback watch handler tried to read before domU
is started)
    vif = ""
   device-misc = ""
    vif = ""
     nextDeviceID = "1"

	However, since netfront/netback hasn''t been ported to IA64 now, it
always caused failure here after timout connecting to vif backend node.
I''ll try to add a hack to prevent connecting to vif backend and see
whether forward progress. If you have simple way to do test, please help me. ;-)
	
	By the way, the loopback driver is also not compiled into xen0/xenU currently
for XEN/IA64. Is there similar case to check vif0.0 for dom0 after above point?
That would make another failure obviously due to same reason. In current stage,
we only promise vbd working on IA64.

Thanks,
Kevin
>-----Original Message-----
>From: Ewan Mellor [mailto:ewan@xensource.com]
>Sent: 2005年11月8日 21:41
>To: Tian, Kevin
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] Is it possible to disable vif completely?
>
>On Tue, Nov 08, 2005 at 09:13:45PM +0800, Tian, Kevin wrote:
>
>> Now I''m enabling multiple domain support on IA64 (Once again,
though
>> working one month ago). The issue what I''m seeing now is:
>> 	"xm create -c" doesn''t return with error in
createDevices() and
>> thus all subsequent xm commands don''t return.
>>
>> My work based on xen-ia64-unstable identical to Rev 7646 on
>> xen-unstable.hg ("Fix pagetable pinning logic for xen/i386
kernels.").
>> However xend/xm works well two weeks ago identical to Rev 7483 on
>> xen-unstable ("Added a timestamp to the logging output by
trace_io").
>>
>> After killing above thread and check /var/log/xend.log, which warns
>> "Device (vif) could not be connected. Hotplug scripts not
working".
>> What''s the necessary environmental setting to support said
hotplug
>> scripts? Any special requirement happens between these two weeks?
>
>There is a bug here that is fixed in 7651.  You ought to be on that
changeset
>at the least.  A lot of ia64 patches went in today, so you probably want to
>look at those too.
>
>Ewan.

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

On Wed, Nov 09, 2005 at 06:20:43PM +0800, Tian, Kevin wrote:
> 	However, since netfront/netback hasn''t been ported to IA64 now,
it always caused failure here after timout connecting to vif backend node.
I''ll try to add a hack to prevent connecting to vif backend and see
whether forward progress. If you have simple way to do test, please help me. ;-)
So you don''t want any networking at all?  In that case, set nics=0 in
your xm
create configuration file, and all should be well!
> 	By the way, the loopback driver is also not compiled into xen0/xenU
currently for XEN/IA64. Is there similar case to check vif0.0 for dom0 after
above point? That would make another failure obviously due to same reason. In
current stage, we only promise vbd working on IA64.
Dom 0''s networking is handled separately.  You want to disable the
network-script option in /etc/xen/xend-config.sxp, and that should be all that
is necessary.

Ewan.

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

>From: Ewan Mellor [mailto:ewan@xensource.com]
>Sent: 2005年11月9日 18:36
>
>On Wed, Nov 09, 2005 at 06:20:43PM +0800, Tian, Kevin wrote:
>
>> 	However, since netfront/netback hasn''t been ported to IA64
now, it always
>caused failure here after timout connecting to vif backend node.
I''ll try to add a
>hack to prevent connecting to vif backend and see whether forward progress.
If you
>have simple way to do test, please help me. ;-)
>
>So you don''t want any networking at all?  In that case, set nics=0
in your xm
>create configuration file, and all should be well!
Yes, that''s the current status for IA64. ;-( And, thanks for you
expertise suggestion and it does work for me! ;-) Previously, I think comment
" #vif = [ ''mac=aa:00:00:00:00:11, bridge=xen-br0''
]" can hide vif but failed try. Actually this way by setting
"nics=0" is most preferable way now since only ia64 specific example
file required to be changed.

Thanks a lot,
Kevin

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

On Wed, Nov 09, 2005 at 07:30:28PM +0800, Tian, Kevin wrote:
> I think comment " #vif = [ ''mac=aa:00:00:00:00:11,
bridge=xen-br0'' ]" can
> hide vif but failed try.
If you comment out the vif line, but don''t set nics=0 then you will get
the
default nics value, which is 1.  This means that it will try to create a nic
with default configuration, which will fail.  If you need no nics, you need to
explicitly say so, with nics=0.

This is confusing, and a mess, but I don''t want to alter configuration
file
behaviour this close to release, if I can help it.

Ewan.

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

> If you comment out the vif line, but don''t set nics=0 then 
> you will get the default nics value, which is 1.  This means 
> that it will try to create a nic with default configuration, 
> which will fail.  If you need no nics, you need to explicitly 
> say so, with nics=0.
> 
> This is confusing, and a mess, but I don''t want to alter 
> configuration file behaviour this close to release, if I can help it.
Conversely, I''d much rather change the config file format before the
3.0.0 release rather than changing it before 3.1.0 -- there''ll be a lot
more configuration files out there to break. I see changes to
configuration parsing code as fairly low risk -- you''re certainly not
likely to get ''complex'' breakage. If its going to happen, it
would have
to be in the next week, though.

I think after the last email discussion we have a clear idea of what the
syntax should be, and it would only require most people to ubdate their
vbd specifiers. I''d really like to sort out the kernel command line
generation at the same time, though...

Ian


vbd = [ ''device=hda1, source=phy:/dev/vg/myroot, options=rw'',
        ''device=hda2, source=file:"/root/dumb, name!",
options=ro'' ]

vif = [ ''device=eth0, mac=aa:00:00:00:00:11, bridge=xen-br0'',
        ''device=eth1, mac=aa:00:00:00:00:12, bridge=xen-br1'' ]

(for vif, the device= can be optional for backward compatibility.
''nics='' must die!)






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

Then maybe an outstanding comment like what you described below can be added to
warning user right way to enable/disable vif?

Thanks,
Kevin
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ewan Mellor
>Sent: 2005年11月9日 19:45
>To: Tian, Kevin
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] Is it possible to disable vif completely?
>
>On Wed, Nov 09, 2005 at 07:30:28PM +0800, Tian, Kevin wrote:
>
>> I think comment " #vif = [ ''mac=aa:00:00:00:00:11,
bridge=xen-br0'' ]" can
>> hide vif but failed try.
>
>If you comment out the vif line, but don''t set nics=0 then you will
get the
>default nics value, which is 1.  This means that it will try to create a nic
>with default configuration, which will fail.  If you need no nics, you need
to
>explicitly say so, with nics=0.
>
>This is confusing, and a mess, but I don''t want to alter
configuration file
>behaviour this close to release, if I can help it.
>
>Ewan.
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Then maybe an outstanding comment like what you described below can be added to
warning user right way to enable/disable vif?

Thanks,
Kevin
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ewan Mellor
>Sent: 2005年11月9日 19:45
>To: Tian, Kevin
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] Is it possible to disable vif completely?
>
>On Wed, Nov 09, 2005 at 07:30:28PM +0800, Tian, Kevin wrote:
>
>> I think comment " #vif = [ ''mac=aa:00:00:00:00:11,
bridge=xen-br0'' ]" can
>> hide vif but failed try.
>
>If you comment out the vif line, but don''t set nics=0 then you will
get the
>default nics value, which is 1.  This means that it will try to create a nic
>with default configuration, which will fail.  If you need no nics, you need
to
>explicitly say so, with nics=0.
>
>This is confusing, and a mess, but I don''t want to alter
configuration file
>behaviour this close to release, if I can help it.
>
>Ewan.
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Ian Pratt
>Sent: 2005年11月9日 20:51
>
>
>vbd = [ ''device=hda1, source=phy:/dev/vg/myroot,
options=rw'',
>        ''device=hda2, source=file:"/root/dumb, name!",
options=ro'' ]
>
>vif = [ ''device=eth0, mac=aa:00:00:00:00:11,
bridge=xen-br0'',
>        ''device=eth1, mac=aa:00:00:00:00:12,
bridge=xen-br1'' ]
>
>(for vif, the device= can be optional for backward compatibility.
>''nics='' must die!)
Yep, it looks clearer to me.

Thanks,
Kevin

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