Re: [Condor-users] condor and co-linux

[Craig Struble <craig.struble@xxxxxxxxxxxxx>]

Hi Vladimir,

We're considering an approach like this for our "Pools of Virtual  
Boxes" project (http://poolsofvirtualb.sourceforge.net) which was  
modeled after coLinux but uses VirtualBox as a hypervisor because of  
many advantages over coLinux (64-bit support, multiple CPU, very  
active development for VirtualBox). We have bootstrapping routines for  
building CentOS and Fedora based images, Windows services to monitor  
Windows usage and configure the virtual machine, and some enhancements  
to pre-package software for deployment.

You could probably accomplish some of this by first submitting a  
vanilla Windows job to launch coLinux on demand, and then creating  
some logic within the coLinux Condor to shut down coLinux after enough  
idle time (or other conditions). Using Hawkeye comes to mind. I  
believe some care is needed to make sure coLinux is launched with  
administrator privileges.

With VirtualBox, we're trying to integrate with the Condor virtual  
machine universe, which should provide some advantages for controlling  
the process of starting and stopping on demand. In practice though,  
having VirtualBox running a Linux image all the time hasn't caused  
problems, even in very busy student labs.

    Craig

P.S. coLinux should be detecting user presence. We were using this  
functionality before switching to VirtualBox (and it is implemented in  
our current releases, but is getting increasingly difficult to  
implement with each new version of Windows).

On Dec 14, 2009, at 11:26 AM, Vladimir Konrad wrote:

> Hello,
>
> While in cardiff, I learnt that running condor under cooperative  
> linux works well (this
> way, one gets linux environment under condor without having linux as  
> main os on the computer.
>
> One draw-back is that the co-linux allocates memory while running,  
> borrowing this
> from the host os (windows). Also, co-linux does not detect user  
> presence (so the
> job cannot be evicted when user starts using machine again) - but  
> this was solved
> to have co-linux to run as idle process.
>
> Did anyone consider a 2 way approach - having condor client on  
> natively on windows,
> this client starting co-linux on demand (1st layer), and then the  
> jobs would
> run under condor under co-linux (2nd layer).
>
> This way, the co-linux would only run on demand, being evicted/shut  
> down when
> user starts using windows again.
>
> Any draw-backs with this approach (too much work to integrate, some  
> show-stoppers and such)?
>
> Kind regards,
>
> Vladimir Konrad
>
> ------
> > because it reverses the logical flow of conversation + it is hard  
> > to follow.
> > > why not?
> > > > do not put a reply at the top of the message, please...
>
> Please access the attached hyperlink for an important electronic  
> communications disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm
> _______________________________________________
> Condor-users mailing list
> To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx  
> with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/condor-users/

--
Craig A. Struble, Ph.D. | 369 Cudahy Hall  | Marquette University
Associate Professor of Computer Science    | (414)288-3783
Director, Master of Bioinformatics Program | (414)288-5472 (fax)
http://www.mscs.mu.edu/~cstruble | craig.struble@xxxxxxxxxxxxx