Hello Olivier,<div><br></div><div>short answer: the device mapping is unpredictable, as you said</div><div><br></div><div>long answer:</div><div><br></div><div>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).</div>
<div><br></div><div>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 :-)</div>
<div><br></div><div>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.</div><div><br>
</div>
<div>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...</div>
<div><br></div><div>So I can only say that the best approach here is trial and error in a per-hypervisor/per-vm basis.</div><div><br></div><div>cheers,</div><div>Jaime</div><div><br></div><div><div class="gmail_quote">On Mon, May 21, 2012 at 6:07 PM, Olivier Berger <span dir="ltr"><<a href="mailto:olivier.berger@it-sudparis.eu" target="_blank">olivier.berger@it-sudparis.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br>
<div class="im"><br>
On Mon, 21 May 2012 15:16:38 +0200, Olivier Berger <<a href="mailto:olivier.berger@it-sudparis.eu">olivier.berger@it-sudparis.eu</a>> wrote:<br>
> Hi.<br>
><br>
> I've read<br>
> <a href="http://opennebula.org/documentation:rel3.4:template#disks_device_mapping" target="_blank">http://opennebula.org/documentation:rel3.4:template#disks_device_mapping</a><br>
> which states that :<br>
><br>
> OpenNebula will mount the disks as follows:<br>
><br>
> sda: OS type Image.<br>
> sdb: Contextualization CDROM.<br>
> sdc: CDROM type Image.<br>
> sdd: Swap disk.<br>
> sd[e,f,g…]: DATABLOCK type Images.<br>
><br>
> However, from what I can see (under 3.2, but the docs are the same), I<br>
> have<br>
><br>
> sda : boot disk ln-ed from my persistent image<br>
> sdb : swap<br>
> sr0 : contextualization CD<br>
><br>
> Is this mapping dependant of the virtulizer (I'm using KVM).<br>
><br>
> Is the docs wrong, or is this an hypothetical example ?<br>
><br>
<br>
</div>Furthermore, I've tested ab it more on my Debian testing system with<br>
3.2.1, and it seems that adding a new DISK with TYPE fs with TARGET =<br>
sdc will actually result in Debian booted in the VM mapping it to sda<br>
:-/<br>
<br>
Hopefully, the disks in the Debian image use UUID and not fixed path,<br>
but that's a bit confusing.<br>
<br>
Maybe the order of the disks detection by Linux inside the VM isn't<br>
predictable, and there's a very good use case for UUIDs here, but,<br>
then... is the sda,sdb... numbering style values for TARGET really<br>
accurate ?<br>
<br>
AFAICT from the kvm generated command line generated from the template,<br>
they're mapped to numbered ide disks... maybe that's in fact just a<br>
numbering depending on the order of appearance in the template file ?<br>
<br>
Maybe using ide0,ide1,ide2 and not sda,sdb,sdc would not convey some<br>
kind of idea that the mapping would be respected inside the running VM ?<br>
<br>
I must admit I haven't dug any further in the libvirt definition file<br>
generated, and the likes, so there's maybe other parameters I've<br>
overlooked...<br>
<br>
Does this make sense ?<br>
<br>
Should there be a warning in the "Disks Device Mapping" section of the<br>
Virtual Machine Definition File docs that the order detected in the<br>
running Linux VMs can't be guaranteed ?<br>
<div class="HOEnZb"><div class="h5"><br>
Thanks in advance.<br>
<br>
Best regards,<br>
--<br>
Olivier BERGER<br>
<a href="http://www-public.it-sudparis.eu/~berger_o/" target="_blank">http://www-public.it-sudparis.eu/~berger_o/</a> - OpenPGP-Id: 2048R/5819D7E8<br>
Ingenieur Recherche - Dept INF<br>
Institut Mines-Telecom, Telecom SudParis, Evry (France)<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
</div></div></blockquote></div><br></div><br clear="all"><div><br></div>-- <br>Jaime Melis<br>Project Engineer<br>OpenNebula - The Open Source Toolkit for Cloud Computing<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a><br>