Raid Array/read-write Permissions, passing images through virtualbox shared folders, fog read-write.

[Chris Shanks]

Morning All,

Bit of an interesting one that I’m trying to solve however there’s so many variables it’s a tad confusing so the set up is this:
Ubuntu server (booting from a separate SSD):
Running a raid5 array - mounted at /storage. This works perfectly fine, I can copy/paste files to and from this.
–Within /storage is /storage/images. This is a copy of all of my fog images backed up from my old fog server, once again, I can at the moment access/delete all files within.
The server is running virtual box of which the host is ubuntu desktop.
–I have set up a shared folder from within the virtualbox settings which shares /storage/images with the host. Called “images” and does not automount so solve previous problems.

Ubuntu desktop host:
Fog 2890
default storage node: /images

/etc/fstab: images /images vboxsf noauto 0 0
All of the image subfolders from within /storage/images have mounted properly within the host /images.
Fog gui disk information shows the free and used space to be the same as the raid array.

The problem appears to be linking all this so that fog can read/write images from it’s /images storage node which just happens to be a raid5 array on the main server. Reason being, we have nearly 1TB of images as we use fog A LOT! So to become more stable, we built a new server, created a raid5 array for all the images to be saved on. Then since the ubuntu desktop host (Fog server) is virtualised and only 10GB big, it can be copied/cloned easily and is held completely seperate from the image data store so if for instance the fog server goes down, we can just reboot a different virtual machine, pass the raid array with the images back through and all is well, likewise if the raid goes down, we just use a back up/rebuild the raid but you know your fog server itself is still functioning.

Hope all that makes sense,
Thanks in advance!

Chris

[Tom Elliott]

This doesn’t seem to be a problem, as I’m reading this, with fog, but rather the way the Server is mounting the shared folder. If the system can’t mount /storage/images (or the shared name images) to /images, the rest of the FOG system would use the root (10GB part) as that’s where /images is created.

Maybe this may help?
[url]http://superuser.com/questions/146763/my-virtualbox-fstab-will-not-auto-mount-on-reboot[/url]

[Chris Shanks]

Hey Tom
Yer, I didn’t exactly think it was a problem with fog or the svn, more a ubuntu problem trying to line all the mount points/permissions.
I have stopped using fstab and found this command:
[CODE]sudo mount -t vboxsf -o rw,uid=1000,gid=1000 FogImages /images[/CODE]
Where FogImages is the name of the shared folder in oracle virtualbox and /images is the mount point within the 10GB ubuntu host.

I can now as a regular user, access, alter, delete files from within /images so the mount appears to be working. I have attempted to point the storage node at /images and given it the username/password of the 10GB virtual host as that is the filesystem it needs to access I think. Created a new image, pointed it to a folder within /images then tried to quick image but still getting:
mount: mounting 10.10.3.171 /images/ on /images failed: permission denied.

So would i be correct in thinking that although I (the user account on the host) have access/modify rights to the shared mounted folder /images, I need to give fog access/modify rights?

[Tom Elliott]

No, I think you need to give everyone RWX on the share as most likely the share is directly related to the uid You’re assigning to it. So if you change fstab, and/or, the mount command to :

mount -t vboxsf -o rw,uid=0,gid=0 FogImages /images; chmod -R 777 /images; service nfs-kernel-server restart

I think things May work, though I haven’t tested it to be honest.
Also,

the fstab would then look like:

FogImages /images vboxsf noauto,uid=0,gid=0,rw 0 0

[Chris Shanks]

Have tried the mount command and the fstab ( given they do exactly the same). They still mount correctly and as a user, I can modify/edit the files, though I did need to be sudo to save the changes. Fog quick image still complains about the mounting problem.
Have given the tftpd-hpa service a restart as well as I wondered if I am constantly mounting/unmounting the/images folder, I can see that the disk info gui is constantly switching between the raid array disk space and the disk space left on the 10GB Vdi that the host is running so it is clearly mounting and picking it up as otherwise fog wouldn’t change from using the VDI to using the raid array space.

[Tom Elliott]

Is there a possibility is that the problem is directly related to the way VBox is working with shared folders? For example, does VirtualBox Shared Folders allow for NFS mounts as they’re already shared?

[Chris Shanks]

Hey Tom,

So after trying what feels like a million different combinations of mount points, shared folders, directories, I am still no closer to getting it work but I know it is possible as I managed to do this exact thing once before, I just didn’t save the example
My latest stumbling block is an Input/output error. ipxe.org/1d0c6139.
Had a quick flick through a previous thread to do with the same code, but his was regarding macs so no use and I’m using the svn so it won’t be the geotag problem.

Thanks,
A very stressed and tired Chris!

[Sebastian Roth]

You could use raw disk access instead of shared folders (which might be even faster I suppose). At first create a RAW VMDK file which actually is just kind of a link to your real raid array device file:

[CODE]VBoxManage internalcommands createrawvmdk -filename “/tmp/rawarray.vmdk” -rawdisk “/dev/md0”[/CODE]

Check it out if you want:
[CODE]$ cat /tmp/rawarray.vmdk

Disk DescriptorFile

version=1
CID=44799ca3
parentCID=ffffffff
createType=“fullDevice”

Extent description

RW 234441648 FLAT “/dev/md0” 0
…[/CODE]

Then add this VMDK to your VirtualBox and startup. It should be ‘/dev/sdb’ inside your VirtualBox host if I remember right. Check ‘dmesg’…