Build a vm server to host legacy systems re: SHARED DISK

[tburt11]

First, let me say that I am an old fart. I setup my first UNIX box (AT&T 3B2) in about 1985. I have written some software, some C and lots of PHP, and a kernel driver for a tape subsystem. I know a bit about Unix/Linux, so hopefully, my contribution will be a benefit, and not another rehash on how to install Win7 on a Linux VM.

I manage an aging IT infrastructure that unfortunately contains some older (win 2K server, win 2k workstation) operating systems that are running apps that cannot be upgraded (or even reinstalled! no key!). The hardware is aging, and I fear the worst when the disk fails, as it must do.

I have done some investigation and I am thrilled to report that I can successfully load these OS's on VBox, and the possibility exists to move the existing images (with their complete software installs) to the new VM's.

I am thrilled !

I have run into a couple of problems/questions that I could use some assistance on. I have googled, and not found any direct answers, so I hope someone here can help me shed some light.

PROBLEM 1 - WHICH TYPE OF DISK TO USE FOR A VIRTUALIZED FILE SERVER.

OK, I know, this is not a great idea, but it is where I am forced to go... I tried setting up an expanding VDI, and it was great, until it needed to grow the file, and the slowdown was extraordinary. It was a large file system 50+GB, I had to abandon that idea after several hours of copy copy copy.

The idea of creating a 100GB file to house a file system seemed less than ideal, so I was encouraged to try the shared storage feature. It worked, but to my dismay, all of the files in this filesystem were owned by the user running VBox on the host system.

Q1 ) Would running VBox on the host, as root, allow the guest to save files with the UID of the user on the guest system?

Consider a host running ubuntu 10.10 as user "vbox" UID 1001, and a guest running unbuntu 10.10. Guest has a user "luser" with UID 1100. luser writes a file to a shared disk, and the file ends up with UID 1001, and not 1100. OK, I can see the complications.. Guest could write a SUID root executable to the partition, and log into the host as an unprivileged user, and get root. So I get it. Would running VBox on the host box allow files to be created as the correct UID? This would be ideal.

Q2 ) Is a fixed size disk image the only real option here? I am a little shy of using a disk image, because I am more comfortable with maintaining real filesystems on real disks when it comes to enterprise data. Are images robust enough? Should I not worry?

DOES ANYONE HAVE ANY EXPERIENCE HERE?

[vbox4me2]

When it comes to storage consider SAS and a good LSI cached SAS controller, 2TB 6gb sas disks are cheap and blazing fast with lsi. You could use 10 of them in raid51 for speed and extra redundancy.

VDI files are pretty sturdy but as always a full backup is more then handy. Raw access can be done but more prone to corruption and backing it up can be a challenge.

Whats the idea of users writing with different uids? how are you envisioning this to work? shared folders? a host is a host, why do VM's have to write to the Host?

[tburt11]

Thanks for your reply vbox4me2.

I am not needing recommendations for hardware. Thanks anyway.

UID's are the problem, not my choice.

Raw disk access to a partition on the host machine is my goal.

Problem is that UID's for files created by guest, are not translated to the partition on the host.

Files created in the partition get the UID of the user running Vbox on the host.

I know it is confusing. It is OK if you don't understand. Perhaps someone has seen this.

[ikar.us]

You don't want the raw partition to be accessed by host and guest at the same time, do you?

[mpack]

I think you were too quick to dismiss the idea of expanding VDIs, perhaps based on prejudiced reports you've read elsewhere.

Yes, certainly, when an expanding VDI is new and empty it will spend most of its young life expanding, with all of the overhead that entails. It should quickly reach an equilibrium state however. If you optimize the system at that point, meaning defrag inside and out and then clone using CloneVDI to optimize the block order - then I think performance should be acceptable, though only you can be the final arbiter on that.

But, I feel obliged to add... given that you've found migrating the OS to new (albeit virtual) hardware was relatively easy, have you considered migrating P2P instead of P2V? The P2P option should mean you can stop worrying about hard disk failure: and disk imagers such as Acronis make an excellent backup tool in the meantime.

[tburt11]

I think you were too quick to dismiss the idea of expanding VDIs, perhaps based on prejudiced reports you've read elsewhere.

Yes, certainly, when an expanding VDI is new and empty it will spend most of its young life expanding, with all of the overhead that entails. It should quickly reach an equilibrium state however. If you optimize the system at that point, meaning defrag inside and out and then clone using CloneVDI to optimize the block order - then I think performance should be acceptable, though only you can be the final arbiter on that.

But, I feel obliged to add... given that you've found migrating the OS to new (albeit virtual) hardware was relatively easy, have you considered migrating P2P instead of P2V? The P2P option should mean you can stop worrying about hard disk failure: and disk imagers such as Acronis make an excellent backup tool in the meantime.

OK.. Just for S**ts and giggles.

I have a windows vista box that has an intermittent hardware problem. I want to move the OS to a VM. I got into Vista and changed my display adapter and controller, then deleted the data partition (750 GB). I ran gparted on the boot partition and winnowed it down from 250 GB to about 140 GB. Clean up and reboot. Every thing looks great.

Now mount the disk on a Linux box and make a dynamic VDI from the disk. Hmm. Gotta do the whole disk? 1 TB in size. I read warnings that doing a partition alone will bring grief. So:

cat /dev/sdc | VBoxManage convertfromraw stdin mynewvirtual.vdi 100....0000

It has been running now for 7 hours, and the VDI is about 127 GB in size. At this rate, it will need another 32 + hours to complete. I hope it speeds up when it gets to the unpartitioned part of the disk. I won't know yet for a few days.

How quick should I judge?

Sorry, I am not clear on how you are using P2P and P2V. Is that Physical to Physical vs Physical to Virtual? My problem is mulifold. P2P is not an option for me.

Thanks!

[mpack]

P2P is not an option for me

Obviously that isn't true or you would be dead regardless of what action you chose. You anticipate that the hard disk might fail in the future. You anticipate that at that time you will either replace the failed hard disk or else the entire host machine. In either case, rather than installing a new OS on the hard disk you could perhaps install an image of your old host - the image being the most recent (eg.) Acronis whole disk backup (if you have a bootable cd drive then I believe you can use Acronis or similar). That's P2P, and I don't really understand why you think it's impossible for you.

I'm not sure what you are doing, virtualizing a Linux host drive?? I thought it was a Windows drive you were trying to virtualize?