Bug #245
Wrong mapping of CDROM devices
| Status: | Closed | Start date: | 05/28/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | % 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.