[one-users] Disks device mapping wrong in docs ?

[Jaime Melis]

Hello Olivier,

short answer: the device mapping is unpredictable, as you said

long answer:

There are two different things here: how the hypervisor connects the drives
and presents them to the guest VM, and what the operating system of the
guest VM does with these drives (udev is the responsible for this for
linux).

We have control over how the hypervisor connects the drives. To do that we
used the sd{a,b,c,...} notation since its a common notation for
qemu-kvm/libvirt/xen and we figured it would make sense for people used to
hypervisors (However, I would personally prefer to do exactly as you said:
ide0, ide1, scsi0, scsi1, etc...) in any case this is mostly an issue that
should be taken up in the libvirt or kvm mailing lists. Although they're
unlikely to change it :-)

Once the vm starts we basically have no control as to where the operating
systems puts the drives. The use of LABEL= and UUID= in the guest vms helps
a lot, as you have already noticed.

For instance, in ubuntu, hdX is never used, always sdX. If you connect one
drive to the IDE bus  (ide0) and one drive to the SCSI bus (scsi0), you'll
have sda (scsi0) and sdb (ide0) which is rather unintuitive, at least for
me...

So I can only say that the best approach here is trial and error in a
per-hypervisor/per-vm basis.

cheers,
Jaime

On Mon, May 21, 2012 at 6:07 PM, Olivier Berger <
olivier.berger at it-sudparis.eu> wrote:

> Hi.
>
> On Mon, 21 May 2012 15:16:38 +0200, Olivier Berger <
> olivier.berger at it-sudparis.eu> wrote:
> > Hi.
> >
> > I've read
> > http://opennebula.org/documentation:rel3.4:template#disks_device_mapping
> > which states that :
> >
> >   OpenNebula will mount the disks as follows:
> >
> >     sda: OS type Image.
> >     sdb: Contextualization CDROM.
> >     sdc: CDROM type Image.
> >     sdd: Swap disk.
> >     sd[e,f,g…]: DATABLOCK type Images.
> >
> > However, from what I can see (under 3.2, but the docs are the same), I
> > have
> >
> > sda : boot disk ln-ed from my persistent image
> > sdb : swap
> > sr0 : contextualization CD
> >
> > Is this mapping dependant of the virtulizer (I'm using KVM).
> >
> > Is the docs wrong, or is this an hypothetical example ?
> >
>
> Furthermore, I've tested ab it more on my Debian testing system with
> 3.2.1, and it seems that adding a new DISK with TYPE fs with TARGET =
> sdc will actually result in Debian booted in the VM mapping it to sda
> :-/
>
> Hopefully, the disks in the Debian image use UUID and not fixed path,
> but that's a bit confusing.
>
> Maybe the order of the disks detection by Linux inside the VM isn't
> predictable, and there's a very good use case for UUIDs here, but,
> then... is the sda,sdb... numbering style values for TARGET really
> accurate ?
>
> AFAICT from the kvm generated command line generated from the template,
> they're mapped to numbered ide disks... maybe that's in fact just a
> numbering depending on the order of appearance in the template file ?
>
> Maybe using ide0,ide1,ide2 and not sda,sdb,sdc would not convey some
> kind of idea that the mapping would be respected inside the running VM ?
>
> I must admit I haven't dug any further in the libvirt definition file
> generated, and the likes, so there's maybe other parameters I've
> overlooked...
>
> Does this make sense ?
>
> Should there be a warning in the "Disks Device Mapping" section of the
> Virtual Machine Definition File docs that the order detected in the
> running Linux VMs can't be guaranteed ?
>
> Thanks in advance.
>
> Best regards,
> --
> Olivier BERGER
> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>



-- 
Jaime Melis
Project Engineer
OpenNebula - The Open Source Toolkit for Cloud Computing
www.OpenNebula.org | jmelis at opennebula.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20120523/1dcf75a8/attachment-0002.htm>