Execution of Linux based tools in .NET Bio

Developer
Apr 3, 2013 at 7:59 PM
Hi folks,

I'm currently working on getting Linux based tools to operate in a .NET Bio framework and I wanted to get people's thoughts on the subject. It's still in a preliminary state as I'm still reading up on some of the technologies involved.

The approach is to use Hyper-V and its associated WMI to create a Linux VM on the host machine. This of course will limit the number of viable hosts due to the nature of Hyper-V. With the Linux VM running it should be relatively simple to execute a lot of these command line tools.

Does anyone have any experience with Hyper-V and its WMI? And does this seem like the correct approach?

Thanks,
Jon
Apr 4, 2013 at 10:19 PM
Hi, Jon,

I seems don't understand your idea at all.

.NET Bio is a framework in C#, it must run on CLR (Mono for Linux).

Linux tools (mostly command line tools) are binary/script in C/C++/Python/what-ever-is-cool, they need Linux as the runtime.

Hyper-V is only a Hypervisor (a single layer, not a full OS), just like VMWare, etc.

When you get a Linux VM run on Hyper-V, you have a full Linux; if your host is a Windows, then you have Windows and Linux running same time at the same physical machine. But Windows does not know Linux, and Linux does not know Windows, there is no communication between them.

So when you run your Linux tools on Linux VM on a Windows Hyper-V, you are still running Linux. How does it work with .NET Bio?

Unless you are talking about one technology I've already forgot the name, i.e. once upon a time, on Windows 7, you can have a Windows XP only program showing an icon on the 7 desktop, when you double click it, it runs like running on 7, in fact the old program is running inside a Windows XP VM (Windows XP Mode), yet you can have the UI and control in 7.

If this is what you are thinking, then ... whoever does it shall win Turing Prize.

Or maybe I misunderstood totally?

Best regards,

Dong
Apr 4, 2013 at 10:33 PM
the idea is very interesting and complex, how I understand your idea I think is dificult deploy over Hyper-V, only one linux process, because you have to interact whit set of required processes in the linux distribution of your choose, I dont know maybe if you want to just execute linux tools over .NET arquithecture this is imposible due to Common Language runtime. is this?
Now i'm working in something relevant to this topic, to deploy a set of tools in Windows arquitectures, or maybe azure, please contact me, and tell me more. my email: leonardo {dot} montesm {at sign }gmail {dot} com
regards,


Leo
Developer
Apr 4, 2013 at 10:33 PM
Dong just made a number of good points, but out of curiosity which tools are you trying to use?

Cheers,
Nigel
Apr 4, 2013 at 10:36 PM
I agree with dong about hyper-v functions, i think windows azure is a possibility, b'cause you can deploy a set of linux distributions in azure.
Apr 4, 2013 at 10:40 PM
i think to deploy high performance tools, is a good option, something like sequence assembler tools, like MIRA and VELVET, or even thinnk in GPU based tools like GROMACS or MEME, also visualization tools, who actually only runs over linux like tablet.

regards,

Leo
Developer
Apr 4, 2013 at 11:02 PM
Hi Dong,

Those are very good points. And you haven't misunderstood. Its part of what I'm trying to figure out. So far it from what I have seen, the Hyper-V WMI has a suite of Virtual System Management Classes that appear to be able to interact with the VM. I'm not sure if its low level Virtual hardware options or if actual jobs (the documentation seems to suggest these classes are aware of processes being run on the VM) can be submitted. I'm in the process of deploying an instance of Hyper-V to test this out.

The other option if this is not the case that the WMI can interact with the VM on this level. I'm curious if it is possible to simple boot up an image of linux with some kind of .init file that will automatically run a specified job on boot. Thoughts?

Jon
Developer
Apr 4, 2013 at 11:07 PM
Edited Apr 4, 2013 at 11:08 PM
double post
Apr 4, 2013 at 11:32 PM
hi jon

is not possible to simple boot up an image of linux with some kind of .init file that will automatically run a specified job on boot. I explain this in my first post.
Apr 5, 2013 at 12:09 AM
Hi, Jon,

I had a look of Hyper-V WMI on MSDN, quick answer is this is not what you are looking for.

I guess you are looking at Virtual System Management Classes, especially "Msvm_ConcreteJob class", this class is derived from "CIM_ConcreteJob", in turn it was derived from "CIM_Job", you can have a read of what is CIM here http://msdn.microsoft.com/en-us/library/windows/desktop/aa386179(v=vs.85).aspx

If you read the CIM_Job class page to the end, you can see this "WMI does not implement this class. For classes derived from CIM_Job, see Win32 Classes." Once you see Win32, it is Windows' own territory.

CIM is the bigger picture, WMI is smaller (BTW, WMI stands for Windows Management Instrumentation), it was never WMI's task to handle the interop http://en.wikipedia.org/wiki/Interoperability

Linux also has CIMs (google CIM Linux).

If you can somehow bridge WMI and Linux CIM, otherwise this might not be the correct directon to go.

Best,

Dong
Apr 5, 2013 at 12:20 AM
One last post before sleep, look at this (read to the last comment) http://blogs.msdn.com/b/powershell/archive/2012/08/24/introduction-to-cim-cmdlets.aspx
Developer
Apr 5, 2013 at 12:26 AM
Edited Apr 5, 2013 at 12:26 AM
It looks like my approach is not going to work..... However thinking about it some more, perhaps its easier to simply start the VM instance and then just SSH into the VM and use it as any other linux machine. Does this sound feasible?
Coordinator
Apr 7, 2013 at 2:57 PM
This sounds feasible, but I'd echo, and maybe modify nigel's post: are the linux tools you have in mind computationally intensive for the uses envisaged? How regular is the communication needed between the linux tools and the .NET Bio code? I regularly use virtual box disk sharing for cross OS stuff when it is really WinProcess > Package > pass Package > LinuxProcess, but that is ridiculous if we need regular communication. Maybe start with some specific use cases and build from there?