Bug #245
Wrong mapping of CDROM devices
Status: | Closed | Start date: | 05/28/2010 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | Tino Vázquez | % Done: | 0% | |
Category: | Core & System | |||
Target version: | Release 1.4.2 | |||
Resolution: | fixed | Pull request: | ||
Affected Versions: |
Description
The original description of the problem is from Florian in the mailing list:
Hi, Is it normal that when you create a virtual machine and you configure one of its disk as a cdrom : #########Open nebula VM Template ######### ... OS = [ BOOT = \"cdrom\" ] ... DISK = [ TYPE = "cdrom" , SOURCE = "/srv/cloud/one/IM_template/debian-504-i386-netinst.iso" , TARGET = "hdc" , CLONE = "no" , SAVE = "no" , READONLY = "no" ] DISK = [ TYPE = "disk" , SOURCE = "/srv/cloud/one/IM_template/test.qcow2" , TARGET = "hda" , CLONE = "no" , SAVE = "no" , READONLY = "no" ] ... ################################ the libvirt driver translate it like this : #########LibVirt VM Template ######### ... <os> <type>hvm</type> <boot dev='"cdrom"'/> </os> <devices> <emulator>/usr/bin/kvm</emulator> <disk type='file' device='disk'> <source file='/srv/cloud/one/var/94/images/disk.0'/> <target dev='hdc'/> </disk> <disk type='file' device='disk'> <source file='/srv/cloud/one/var/94/images/disk.1'/> <target dev='hda'/> </disk> ... ################################ That is to say the translation doesn't care about my cdrom type . And the vm failed. but if I put cdrom in the device attirbute it works ... I searched in the code and I realized that if the type is block in the ON template the device attirbute will be set as disk and if not it will be set at disk again : root / src / vmm / LibVirtDriver.cc line 687 to 697 ...
Associated revisions
bug #245: cdroms are now mapped to disks of type cdrom
bug #245: cdroms are now mapped to disks of type cdrom
(cherry picked from commit 18313d25cc5ea692e845ff538d54ea75012b40d8)
History
#1 Updated by Ruben S. Montero about 11 years ago
- Status changed from New to Closed
- Resolution set to fixed
This bug has been solved in one-1.4 and master branches.