Hello everyone,

I'm working for a bank that is using applications that are running on high-performance computing clusters (hundreds of servers). Those apps are developped to run some specific calculations on Linux, and some other on Windows Server 2003/2008.

Currently, they have several HPC clusters exclusively running Linux OS, and several HPC cluster exclusively running Windows OS.

They want a solution to have both Linux and Windows installed on the same server on separate partitions, then have a way to automatically boot on Linux or Windows depending on their needs.

My thought is to install Windows 1st, then Linux.
From Linux, modify the GRUB bootloader to start next time on Windows is not a big issue. However, I have to find a way in Windows to write in GRUB to be able to boot Linux next time.

Has anyone an idea about this?

There are a few solutions like this one:http://www.platform.com/cluster-comp...c-os-multiboot , but I want to find a way to do it simply and without buying anything.

Thanks !

Greetingz!

Rather than reboot the whole server into one OS or the other, I would suggest the following;

1) Setup VMware ESX (as you work for a bank and want a support contract from a reputable vendor, which is why I'm not outright suggesting a totally free, community supported virtualization layer like Xen or VirtualBox).

2) Configure a Windows Server VM.
You might be able to get away with some sort of "Physical to Virtual" conversion, but it would be best to configure the VM outright.

3) Configure a Linux Server VM.
Should be relativly straight forward.

4) Write a script that will trawl through ESX servers and turn on/off the Windows/Linux VMs as needed.

P.S:
If you're working for a "bank" that wants to expand their IT resources, but not the budget. Mention to them that all things require $$$.
If they don't understand this now, don't walk...RUN.

Note that in a virtual machine you'll get fewer I/O operations per second on a local disk, compared to raw hardware. If the compute nodes do number crunching (like Monte Carlo stuff that mostly use CPU and memory, not a lot of local disk accesses), it won't matter much. But be aware that there is a virtualization penalty, albeit small.

If you don't want to virtualize -- and I wouldn't, for computing nodes --, you can solve this problem trivially by installing Grub or Grub2 to a FAT partition (perhaps at the end of the same disk you have your Windows partition(s) in). In Linux, you'll configure that partition to be mounted at /boot, in Windows it'll show up as a separate volume. It doesn't need to be large; I normally use 100 MB or so, just to make sure I won't run out when doing updates. (I prefer the end of the disk, to make sure Windows assigns it last; I haven't used Windows in a long time, though.)

When booting, Grub will always read grub/menu.lst and Grub2 grub/grub.cfg and grub/grubenv. If you are using Grub, create grub/menu.linux and grub/menu.windows and simply copy the correct version over grub/menu.lst when selecting the OS for subsequent boots. If you are using Grub2, create grub/grubenv.linux and grub/grubenv.windows and copy the correct version over grub/grubenv when selecting the OS for subsequent boots. Grub2 is safer for this because grub/grubenv is just a variable definition file, which the real grub/grub.cfg script reads: a problem in grubenv is unlikely to cause a boot failure, you'd just boot into the wrong OS.

Hope this helps,

Nominal Animal

1 members found this post helpful.

It's not that they don't want to pay, it's just me that is looking for a "do it yourself" way to do it! We already buy but too much products that we are under-using, and auto dual booting is a problem I want to try to solve myself before thinking of buying a dedicated software.

For the VM solution you are suggesting, we (I'm part of the windows team) have already set up a test platform using Vmware ESX and vCenter that is working well, but for some reason the head of the UNIX team prefers a dual booting solution rather than ESX... maybe because all the VMware virtualization platforms are managed by the windows team

That's why I'm looking for a way to overwrite/modify the grub bootloader from Windows.
Maybe there is another way to see this problem, any suggestions would be appreciated

Thanks!

This "bank" you work for...the UNIX servers wouldn't happen to all be named after non-controversial dead guys, would they?

There are drivers of the ext file system (ext2 and ext3 AFAIK) for Windows. So no need to have /boot mounted on an FAT-partition if you use ext...

1 members found this post helpful.

No, the servers are named using internal projects codes

Nominal Animal, the solution you are suggesting looks like what I was thinking about; I think I'll discuss that with our UNIX guys.

A quick sketch of your eventual solution (and use of the solved button for this thread, if appropriate) would be appreciated .

You mean that I can let the GRUB bootloader on the default Linux ext3 partition, use a driver to get read/write access to the ext3 partition from Windows, then overwrite menu.lst from Windows ?

Sorry if the question seems trivial, I used to work with UNIX servers a long time ago as a trainee, and I don't remember everything

Edit: I'll post a sketch of the solution when I'll have the opportunity to test it with the UNIX guys

Exactly. Nominal Animal nicely pointed out how to proceed from there.

I have another idea that is even simpler:
Is it possible to switch the OS by having a script on Windows that set the Linux partition as active, and another script on Linux that does the same to switch back to Windows ?

This way, I won't even have to bother with the bootloader settings.

Ummm. I don't really know whether that would work with GRUB which ignores the bootable flag AFAIK. What code do you have in the MBRs?

Did I mention that VMware ESX is a bare-metal hypervisor, with almost no overhead? And you can script the startup/shutdown of various VMs?
Just sayin...

For the moment, nothing !
I will try both options

Yeah, I know, that's also the solution we had in mind and tested... But unfortunately it's not always the best solutions that are selected !