marionnet-dev team mailing list archive

["Jean-Vincent Loddo" <Jean-vincent.Loddo@xxxxxxxxxxxxxxxxxxxx>]

Hey Alexey,

I have played this morning with VirtualBox and I like it. I'm seriously thinking 
to support it in Marionnet. It's not so easy but it may be worth the trouble.
I still have some minor doubts about the size of the "frontend" snapshots. I 
have tried with an Ubuntu 11.04 as guest (Ubuntu 10.10 as host) following your 
instructions with, I think, a meaningless difference: the virtual disks had the 
extension .vdi (instead of .vhd), and I'm was not able to "detach" a disk from 
the GUI (3.2.8_OSE_r64453) as you suggest. However, the command line:

$ VBoxManage modifyhd Ubuntu_11.04_32_bits.vdi --type immutable

gave the expected result.

Once the children machine was launched, the size of the snapshot file (observed 
from the host) jumped to 56 Mb immediately, without doing anything, just the 
boot. Can we somehow reduce this initial size? I can't understand what those 56 
megs are used for. In your opinion, could it be useful to switch to a non-
journalized filesystem? (I have used ext4 for this test).

The second question is: what happens when the backend and/or the frontend are 
moved (to another host and/or directories)? In other words, where the link 
between the backend and the frontend is written in the host?

Thanks for your help,
Jean-Vincent

Le lundi 16 mai 2011 20:58:16, Alexey Eromenko a écrit :
> > About the VirtualBox integration, it seems to us, with our limited
> > knowledge of VirtualBox, that there could be a problem. Actually,
> > Marionnet takes advantages of the UML ability to deal with cow
> > filesystems. When a Marionnet virtual machine is created, its virtual
> > disk is a couple (B,F) where B is a (big) cow "Backend" and F is a
> > (small, sparse file) cow "Frontend". In this way, when the user defines
> > a project with some machines M1,..,Mn, we store in the project file
> > (which is a tar archive) only the set of frontends F1,..,Fn. The project
> > can be sent and re-used in another host only if the set of backends
> > B1,..,Bn are also installed in the new host. Backends are a sort of
> > "prerequisite" to run a project in a host.
> > 
> > VirtualBox provides a snapshot mechanism that seems equivalent: as far as
> > I can see, the backend is the virtual disk (.vdi) and the frontend is
> > the snapshot (again a .vdi). But what about the disk space?
> > 
> > Could a snapshot be
> > a sparse file, i.e. a small piece of data that we could put in the
> > project file, as we do with cow files? This is our main doubt about the
> > introduction of VirtualBox in Marionnet. Maybe, you will dissipate it
> > immediately...
> 
> VirtualBox has several types of images:
> 
> -normal images (read-write, those can be assigned to only one running
> VM) -- this is what VirtualBox GUI offers for newbies, but probably
> not suitable for your project.
> -immutable images (read-only, and can be assigned to many running VMs)
> -- this is what you need, it seems. This is the equivalent of UML's
> 'Backend' images.
> -differencing images - (read-write) this is the cow images, that are
> roughly equivalent to UMLs 'frontend' images. You will need to use
> them. Differencing images can be done over normal images, or over
> immutable images.
> 
> VDI is a container disk format, used by VirtualBox, but it can have
> different types.
> 
> NOTE: VirtualBox has built-in management layer. This is quite a huge
> difference from UML or Qemu engines, from programmer's point of view
> -- it changes the programming paradigms in a big way.
> 
> This management layer has several consequences:
> 1. You don't have to store a lot of things in your projects (Hard Disk
> attachments, MAC addresses, RAM size, etc...) - a VM in VirtualBox is
> really an object, that has everything attached and pre-configured.
> You can rely on VirtualBox GUI for basic VM settings (this is what GNS3
> does)
> 
> 2. Management layer is a protection layer against user's mistakes: In
> UML or Qemu if you attach the same 'Backend' image in two VMs and
> mount them both as 'read-write', it will corrupt the filesystem in the
> image.
> No such thing possible in VirtualBox.
> 
> With immutable image as base, VirtualBox enables 'cow' mode
> automatically, while with 'normal' image as base, it will refuse to
> start second VM.
> 
> This management layer is a singleton, per user. (called 'VBoxSVC').
> 
> Practical Example:
> 1. in GUI, create new VM, called "Linux-Motherimage" -- install Linux into
> it. 2. convert it to immutable:
> 2.a. in GUI, detach "Linux-Motherimage.vhd" from "Linux-Motherimage" VM.
> 2.b:
> $ VBoxManage modifyhd Linux-Motherimage.vhd --type immutable
> 
> 3. create children VMs:
> 3.a. In GUI, create new VM "Linux-child-VM01", choose "Use Existing
> Disk" = "Linux-Motherimage.vhd"
> Now it will use it as 'cow', and create 'frontend' differencing image
> automatically.
> Look in folder:
> ../Linux-child-VM01/Snapshots/{UUID}.vdi
> NOTE: This is not a standard snapshot, and therefore it is invisible from
> GUI.
> 
> This file is a differencing image COW image, based on immutable
> "Linux-Motherimage.vhd".
> 
> 3.b. By default, VirtualBox discards all changes on VM shutdown, and
> reverts back to original state. (equals to "Linux-Motherimage.vhd")
> To prevent this from happening, use:
> VBoxManage modifyhd ./Linux-child-VM01/Snapshots/{UUID}.vdi --autoreset off
> 
> 3.c. Create more children:
> "Linux-child-VM02", choose "Use Existing Disk" = "Linux-Motherimage.vhd"
> VBoxManage modifyhd ./Linux-child-VM02/Snapshots/{UUID}.vdi --autoreset off
> ....
> 
> 4. Differencing images are linked to the base image (to either
> 'normal' or 'immutable' image).
> You can look on this images hierarchy in GUI->File->Virtual Media Manager

-- 
============================================
Jean-Vincent Loddo
Maître de Conférences
IUT Villetaneuse Dép. R&T
Laboratoire LIPN - UMR 7030
Université Paris 13
Avenue J.B. Clément 
F-93430 Villetaneuse, FRANCE
tel : +33 1 49 40 36 84 
fax : +33 1 48 26 07 12
============================================