Xen devel - Aug 2005 - [PATCH] Make Xend use consoled and xc_console

The attached patch removes all of the console handling code from Xend 
and changes xm to simply exec /usr/libexec/xen/xc_console.

I''ve done a pretty good amount of testing and this seems to clear up
all
of the Xend console issues in bugzilla.

This is a pretty big change to Xend though with a lot of deleted code so 
I''d appreciate if people more familiar with the Xend codebase could
look
through it critically.

In addition to the patch, the following files are no longer used:

tools/python/xen/util/console_client.py
tools/python/xen/xend/XendConsole.py
tools/python/xen/xend/server/SrvConsole.py
tools/python/xen/xend/server/SrvConsoleDir.py
tools/python/xen/xend/server/console.py

Regards,

Anthony Liguori

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

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

Sorry, forgot patch.

Anthony Liguori wrote:
> The attached patch removes all of the console handling code from Xend 
> and changes xm to simply exec /usr/libexec/xen/xc_console.
>
> I''ve done a pretty good amount of testing and this seems to clear
up
> all of the Xend console issues in bugzilla.
>
> This is a pretty big change to Xend though with a lot of deleted code 
> so I''d appreciate if people more familiar with the Xend codebase
could
> look through it critically.
>
> In addition to the patch, the following files are no longer used:
>
> tools/python/xen/util/console_client.py
> tools/python/xen/xend/XendConsole.py
> tools/python/xen/xend/server/SrvConsole.py
> tools/python/xen/xend/server/SrvConsoleDir.py
> tools/python/xen/xend/server/console.py
>
> Regards,
>
> Anthony Liguori
>
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>
> _______________________________________________
> 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

> The attached patch removes all of the console handling code 
> from Xend and changes xm to simply exec /usr/libexec/xen/xc_console.
Please can you provide some more detail, particularly how it changes
things from a user point of view. How do you disconnect and reconnect to
consoles? Does the ''-c'' option to xm still work? Can the user
control
allocation of are tty names?

Also, should consoled really line in /usr/sbin/ ?  I think it should be
in /usr/lib/xen/bin

(Didn''t we decide /usr/libexec was deprecated anyhow?)

BTW: does this fix the console output corruption bug that''s on the
books?

Thanks,
Ian 

> I''ve done a pretty good amount of testing and this seems to 
> clear up all of the Xend console issues in bugzilla.
> 
> This is a pretty big change to Xend though with a lot of 
> deleted code so I''d appreciate if people more familiar with 
> the Xend codebase could look through it critically.
> 
> In addition to the patch, the following files are no longer used:
> 
> tools/python/xen/util/console_client.py
> tools/python/xen/xend/XendConsole.py
> tools/python/xen/xend/server/SrvConsole.py
> tools/python/xen/xend/server/SrvConsoleDir.py
> tools/python/xen/xend/server/console.py
> 
> Regards,
> 
> Anthony Liguori
> 
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> 
> _______________________________________________
> 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

Ian Pratt wrote:
>>The attached patch removes all of the console handling code 
>>from Xend and changes xm to simply exec /usr/libexec/xen/xc_console.
>>    
>>
>
>Please can you provide some more detail, particularly how it changes
>things from a user point of view. How do you disconnect and reconnect to
>consoles? Does the ''-c'' option to xm still work? Can the
user control
>allocation of are tty names?
>  
>
xm console still connects and disconnects to the console.

xm create -c still works as expected.

You still disconnect from the console with C-].  The only user facing 
difference is that xm list does not have a console field (the port it 
showed previously was meaningless anyway with domain sockets) and xm no 
longer supports the consoles command (since again, the information it 
was displaying wasn''t all that useful).

If we export over tcp then we can add some info back into xm.  However, 
I''d much rather implement the NSS plugin we talked about at the Summit.

tty names are automatically chosen by the OS so there isn''t really 
anything to control.
>Also, should consoled really line in /usr/sbin/ ?  I think it should be
>in /usr/lib/xen/bin
>  
>
I put it there since that''s where we have xenstored installed.  We can 
certainly install it somewhere else though.
>(Didn''t we decide /usr/libexec was deprecated anyhow?)
>  
>
If it is, I''ll submit a patch to relocate the contents of
/usr/libexec/xen.
>BTW: does this fix the console output corruption bug that''s on the
>books?
>  
>
I''ve not been able to reproduce it.  I had 50 domains running all 
cat''ing /dev/urandom and I was able to input/output large amounts of 
data without corruption to another domain.

With that said though, I''m still not convinced it''s fixed
completely
because I don''t think xcs buffers everything correctly.  The new
console
drivers should do the trick though since we won''t need to go through
xcs.

Regards,

Anthony Liguori
>Thanks,
>Ian 
>
>
>  
>
>>I''ve done a pretty good amount of testing and this seems to 
>>clear up all of the Xend console issues in bugzilla.
>>
>>This is a pretty big change to Xend though with a lot of 
>>deleted code so I''d appreciate if people more familiar with 
>>the Xend codebase could look through it critically.
>>
>>In addition to the patch, the following files are no longer used:
>>
>>tools/python/xen/util/console_client.py
>>tools/python/xen/xend/XendConsole.py
>>tools/python/xen/xend/server/SrvConsole.py
>>tools/python/xen/xend/server/SrvConsoleDir.py
>>tools/python/xen/xend/server/console.py
>>
>>Regards,
>>
>>Anthony Liguori
>>
>>Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>>
>>_______________________________________________
>>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

> xm console still connects and disconnects to the console.
> 
> xm create -c still works as expected.
> 
> You still disconnect from the console with C-].  The only 
> user facing difference is that xm list does not have a 
> console field (the port it showed previously was meaningless 
> anyway with domain sockets) and xm no longer supports the 
> consoles command (since again, the information it was 
> displaying wasn''t all that useful).
Excellent, thanks.
> If we export over tcp then we can add some info back into xm. 
>  However, I''d much rather implement the NSS plugin we talked 
> about at the Summit.
Yep.
> >Also, should consoled really line in /usr/sbin/ ?  I think 
> it should be 
> >in /usr/lib/xen/bin
> >  
> >
> I put it there since that''s where we have xenstored 
> installed.  We can certainly install it somewhere else though.
I generally dislike the idea of having xen-specific daemons that aren''t
useful to have on one''s path under /usr/sbin/ 
 
> >(Didn''t we decide /usr/libexec was deprecated anyhow?)
> >  
> >
> If it is, I''ll submit a patch to relocate the contents of 
> /usr/libexec/xen.
Gerd said it was deprecated, and he works for a distro so it must be
true :-)

I''d go for /usr/lib/xen/bin

It would be good to do an audit of everything we install. I bet there''s
random crap in tools/misc that aren''t really user tools and
shouldn''t be
going in /usr/bin/ 
> >BTW: does this fix the console output corruption bug that''s on
the
> >books?
> >  
> >
> I''ve not been able to reproduce it.  I had 50 domains running 
> all cat''ing /dev/urandom and I was able to input/output large 
> amounts of data without corruption to another domain.
Interesting. I''ve a T42 laptop runing a CentOS4 dom0 that it happens
frequently on, but I haven''t seen it on other machines..
> With that said though, I''m still not convinced it''s fixed
> completely because I don''t think xcs buffers everything 
> correctly.  The new console drivers should do the trick 
> though since we won''t need to go through xcs.
Yep, hopefully.

Thanks,
Ian

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

Ian Pratt wrote:
>Gerd said it was deprecated, and he works for a distro so it must be
>true :-)
>
>I''d go for /usr/lib/xen/bin
>
>It would be good to do an audit of everything we install. I bet
there''s
>random crap in tools/misc that aren''t really user tools and
shouldn''t be
>going in /usr/bin/ 
>  
>
Ok, I''ll look into it.
>>I''ve not been able to reproduce it.  I had 50 domains running 
>>all cat''ing /dev/urandom and I was able to input/output large 
>>amounts of data without corruption to another domain.
>>    
>>
>
>Interesting. I''ve a T42 laptop runing a CentOS4 dom0 that it
happens
>frequently on, but I haven''t seen it on other machines..
>  
>
Sorry, I wasn''t clear.  I haven''t been able to reproduce it
with the
consoled code.  It happens quite frequently for me under the old Xend code.

Regards,

Anthony Liguori
>>With that said though, I''m still not convinced it''s
fixed
>>completely because I don''t think xcs buffers everything 
>>correctly.  The new console drivers should do the trick 
>>though since we won''t need to go through xcs.
>>    
>>
>
>Yep, hopefully.
>
>Thanks,
>Ian
>
>  
>

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

On Wed, 2005-08-03 at 17:04 -0500, Anthony Liguori
wrote:
> >(Didn''t we decide /usr/libexec was deprecated anyhow?)
> >  
> >
> If it is, I''ll submit a patch to relocate the contents of
/usr/libexec/xen.
=> /usr/lib/xen

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman


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

Ian Pratt wrote:
>BTW: does this fix the console output corruption bug that''s on the
>books?
>  
>
I wrote a regression suite that stresses the console code pretty hard 
and checks for data corruption.  We''re still losing data (although when
throttled appropriately the loss can reduced).  I''ve hunted it down a 
bit and it appears xcs is dropping the messages.

This leads to the question of how close the new console driver is.  If 
it''s going to be awhile, I''ll hunt down the xcs problem but
I''d rather
put that energy into just getting rid of xcs.

Let me know if there''s anything I can do to help out.

Regards,

Anthony Liguori
>Thanks,
>Ian 
>
>
>  
>
>>I''ve done a pretty good amount of testing and this seems to 
>>clear up all of the Xend console issues in bugzilla.
>>
>>This is a pretty big change to Xend though with a lot of 
>>deleted code so I''d appreciate if people more familiar with 
>>the Xend codebase could look through it critically.
>>
>>In addition to the patch, the following files are no longer used:
>>
>>tools/python/xen/util/console_client.py
>>tools/python/xen/xend/XendConsole.py
>>tools/python/xen/xend/server/SrvConsole.py
>>tools/python/xen/xend/server/SrvConsoleDir.py
>>tools/python/xen/xend/server/console.py
>>
>>Regards,
>>
>>Anthony Liguori
>>
>>Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>>
>>_______________________________________________
>>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 Aug 4, 2005, at 12:23, Anthony Liguori wrote:
> I wrote a regression suite that stresses the console code pretty  
> hard and checks for data corruption.  We''re still losing data  
> (although when throttled appropriately the loss can reduced). 
I''ve
> hunted it down a bit and it appears xcs is dropping the messages.
>
> This leads to the question of how close the new console driver is.   
> If it''s going to be awhile, I''ll hunt down the xcs
problem but I''d
> rather put that energy into just getting rid of xcs.
This has now become my top priority, so I''m actually working on it  
now, and I''ll hopefully have something to test by tomorrow.
> Let me know if there''s anything I can do to help out.
Your regression test sounds useful, I''ll likely be needing it soon...

robert



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

Robert Read wrote:
>> Let me know if there''s anything I can do to help out.
>
>
> Your regression test sounds useful, I''ll likely be needing it
soon...
Trying to figure out how best to submit it to the tree.  The problem is 
that it requires an initrd that can be made to execute a command during 
startup.  I''ll probably post the code with just a readme in the next 
couple hours.

Would be nice to have a general way to do this for testsuites in Xen 
though.  Any chance we''ll see XenBench2 soon?

Regards,

Anthony Liguori
> robert
>
>
>

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

> > Your regression test sounds useful, I''ll likely be needing 
> it soon...
> 
> Trying to figure out how best to submit it to the tree.  The 
> problem is that it requires an initrd that can be made to 
> execute a command during startup.  I''ll probably post the 
> code with just a readme in the next couple hours.
Excellent. Having more regression tests is always useful.
 
> Would be nice to have a general way to do this for testsuites 
> in Xen though.  Any chance we''ll see XenBench2 soon?
Yep, soon now -- it seems to be coming together nicely. The first
priority is to ''go live'' with the web display matrix and start
filling
in results, and then to get it packaged and ''documented'' so
that others
can run it and start adding tests etc. I''ve appended the first test
programme that we''re aiming for (I don''t think we''ll
quite have
everything by rev 1, but quite a lot of it)

The infrastructure is capable of taking a virgin machine and installing
everything needed to run a given test programme, co-ordinating the
tests, and then uploading the results.


Best,
Ian


phase 1: domain 0 uniprocessor tests:
 * lmbench, just the OS tests
 * ''make -j8'' build of e.g. linux 2.6.11 with the defualt
config
 * run the Linux Test Project (LTP) suite
 * run ttcp rx/tx bw tests to the supervisor, with 552 and 1500 byte
MTUs
 * run udp ping-pong msg latency tests for a few message sizes 64, 1024,
64k
 * run timed ''dd'' test to local disks to establish raw disk
performance
 * start the control tools
 * start a new VM
 * (NB: ensure all domains in these tests are configured with swap
space)

Phase 2: domain 1 uniprocessor tests:
 * lmbench, just the OS tests
 * ''make -j8'' timed build of e.g. linux 2.6.11 with the
defualt config
 * run the Linux Test Project (LTP) suite
 * run ttcp rx/tx tests to the supervisor, with 552 and 1500 byte MTUs
 * run udp ping-pong msg latency tests for a few message sizes 64, 1024,
64k
 * run timed ''dd'' read/write tests to local disks e.g. of
several GB of
data
 * run osdl reaim benchmark
 * run postmark benchmark
 * run tbench benchmark
 * run dbench benchmark
 * run ''crashme'' for a few minutes
 * run memtest-0.0.4 suite
 * run LTP in parallel stress test mode for e.g. 15mins
 * run PostgreSQL driven by osdb (this is slightly hard, but we have
experince)
 * ''make -j'' max parallel build of e.g. linux 2.6.11 with the
defualt
config
 * possibly run SPEC JBB2000 

Phase 3: inter-domain network testing
 * (dom0 to create another VM )
 * run tcp bandwidth tests between VMs using ttcp, 1500 byte MTU
 * run udp ping-pong latency tests between the two VMs, different msg
sizes
 * possibly run the fixed ACE tests between two domains
 
Phase 4: domain 2 SMP tests:
 * (domain 0 to create new SMP VM)
 * repeat the tests that were used on the uniprocessor VM

Phase 5: stress testing
 * (dom0 to create several other SMP VMs, 2-3x over commit on physcial
CPUs )
 * (for these tests we don''t care about the benchmark results)
 * in a loop in each VM (including dom0), select benchmarks to run in a
random order.
 * it would be ideal if we could have two domains that run the
inter-domain network tests throughout this phase (i.e. not participating
in the random tests)
 * we need to continue to monitor the liveness of the benchmarks and of
the VMs
 * after running this phase for an hour or two, move to phase 6

Phase 6: stress testing combined with tools testing
 * stop the random benchmark run in domain 0 but let other VMs continue
 * run the following tests for a few minutes each:
   * go through adding VCPUs to each domain, one at a time, sleep 5
   * go through removing VCPUs to each domain, one at a time, sleep 5
   * (number of VCPUs for each domain should be restored)
   * pick two domains. Use the balloon driver to increase the memory of
one 
       and reduce the memory of the other. sleep 10. repeat for several
minutes
   * pick a domain, do a ''xm migrate -l DOMID localhost''
       (NB you must have some slack memory on the machine to do this)
       check migration completes OK, repeat many times
   * (we could add other tests to check other ''xm'' commands
(e.g.
pincpu)
       but this suite will already get most of the hard cases
   * issue xend restart

Phase 7: shutdown
 * shut down each domU, then shutdown dom0
         

Tests to be run on x86_32, x86_32p and x86_64 builds of Xen / Linux, on
a range of different machines and distros. x86_64 should use a
combination of 32 and 64 bit file systems.




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

Mini-os updated to use the new timer interface.

Cheers
Gregor


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