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

[Jaime Melis]

I forgot to say that I agree with you that adding a note in the
documentation about this would be nice

On Wed, May 23, 2012 at 4:26 PM, Jaime Melis <jmelis at opennebula.org> wrote:

> 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
>



-- 
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/9ae516a0/attachment-0002.htm>