On Mon, 2023-05-22 at 17:41 +0200, Gorka Eguileor wrote:

On 20/05, Work Ceph wrote:

...

Hello guys, We have a situation where an image requires an IDE bus in KVM. Therefore, we configured it in OpenStack to have the IDE bus being used. However, when we add new volumes to this VM (server), all of them are being allocated as IDE volumes; therefore, we are limited to 4 volumes in total in the VM. Is it possible to mix different types of volumes in a VM in OpenStack? I know that in other platforms, such as when we use KVM directly, proxmox, Apache CloudStack, we can do such combinations, but we were not able to achieve it in OpenStack.

Have you guys worked with similar use cases? I know that I can convert the image to use virtIO or iSCSI bus, and to do that I need to fix/patch the operating system inside the image. However, I would like to check if there is a method to use a root volume of a VM as IDE, and other volumes as virtio to avoid the limit of volumes that IDE has.

Hi,

I think I heard some Nova people talking about a new feature to support different buses for different volumes. Unfortunately I don't remember if it's something they were considering doing or something they were already working on. it was something we were considering supporting in the future if someone volenterred to work on it. i was suggesting it shoudl be a preriqustit to supprot vdpa for cinder volumes in the futrue.

currently we do not supprot using multiple buses for block devices in general. even when not using cinder. the hw_disk_bus option applies to all volumes (local or cinder) of type block. the only real excption to that is we have ha_rescue_bus in the event you are rescuing an instance in that case you can be using virtio for evernty else and then use ide or another bus for the rescue disk i.e. hw_disk_bus=virtio hw_rescue_bus=ide libvirt can supprot this as evident by the fact we cann support this for the rescue usecase but there is a non zero amount of work that woudl be required. no one is currenlty working on this we have a downstream tracker to look at this in some future release but based on our internal backlog i doubth anyone form redhat will have capsity to work on this in the next 12 months. if you want to propose such a feature the nova team are open to reviweing a spec code proposal but it would take a effort form member of the comunity to advance this this cycle. effectlivly it would require using metadata on the volume to allow requesting a disk bus per volume. form the ptg conversation i belive nothing is required on the cinder side for that. on the nova side we would need ot modify nova to use this metadata from the vlome and cache it in the instance_system_metadta table or the bdm in our db so that change to the bus after its attach to an instance would have no effect unless the volume was detached and reattached. there is a related edge case. currently you cannot create a cinder volume form an iso and boot form it. the reason for this is the voluem is treated liek a blockdevice instead of a cdrom image. the same or a similar mechinium could be used to say this volume is a block device vs removable media. this would be useful for things like driver disk for windows but if the driver you are tyring to install is virtio-blk or virtio scsi you need a way to attach that driver voluem to a differnt bus to install it. which is why this is related.

Cheers, Gorka.