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 <[email protected]> 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 < > [email protected]> wrote: > >> Hi. >> >> On Mon, 21 May 2012 15:16:38 +0200, Olivier Berger < >> [email protected]> 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 >> [email protected] >> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >> > > > > -- > Jaime Melis > Project Engineer > OpenNebula - The Open Source Toolkit for Cloud Computing > www.OpenNebula.org | [email protected] > -- Jaime Melis Project Engineer OpenNebula - The Open Source Toolkit for Cloud Computing www.OpenNebula.org | [email protected]
_______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
