Re: [Users] EL5 support for VirtIO SCSI?

Hello Itamar. The specific use case is a particular propriety filesystem that needs to see a scsi device. It will do scsi inquiry conmmands to verify suitability. In talking to the devs - of the filesystem - there is no way around it. I'd previously tried virtio-block - resulting in the /dev/vd* device - and the filesystem would not work. From doing a bit of web searching it appears the kvm/qemu supports (or did support) an emulated LSI scsi controller. My understanding is that the various virtualization platforms will emulate a well supported device (by the guest OSes) so that drivers are not an issue. For example this should allow a VM on Vmware vsphere/vcenter to be exported to Ovirt and have it boot up. The potential for further optimising the guest is there by installing ovirt/qemu/kvm guest utils that then allow the guest OS to understand the virtio nic and scsi devices. The guest could then be shut down, the nic and scsi controller changed and the guest booted up again. You can do the same thing in the Vmware world by installing their guest tools, shutting down the guest VM, then reconfiguring it with a vmxnet3 nic and pvscsi scsi adapter, then booting up again. It does seem somewhat inconsistent in Ovirt that we allow a choice of Intel e1000 or virtio nics, but do not offer any choice with the scsi adapter.

Again, in Vmware land you can choose to have a scsi disk, but you choose which controller type it is attached to. In the current Ovirt 3.3.0 release you just chose a virtio-scsi disk, rather than there being a separation of the scsi disk and scsi controller. The messy situation with importing VMs from other platforms could be eased by allowing an emulated scsi controller as well as the preferred virtio controller. As mentioned previously, the support for this seems to be present in kvm/qemu. I wonder if there was a specific design decision (ie: some particular reason) to not support the approach I've just described? I can understand that in some cases simplicity is something to aim for though. I think this would make migration away from the dominant market leader - Vmware - easier and is something that would make ovirt/RHEV that more compelling. Getting back to my original query - 'open-vm-tools' support the vmware paravirtual scsi adapter and I am able to install these on EL5 and then see that adapter. It would be great if there was a similar initiative for the various virtio devices where you could install a packge/kmod and then allow some of the older OSes (of which there are still lots of VMs around for various reasons). There are obviously drivers for the various Windows flavours that take this approach. I'm surprised that for Linux it is just a case of 'if it's in the kernel you are running then it is supported'. I'm really pleased with the progress the ovirt has been making. I'm like to see it continue to knock down the various reasons out there as to why people with Vmware vcenter shops can't migrate over to it. Cheers, Paul On Wednesday, 13 November 2013 8:57 PM, Itamar Heim <iheim(a)redhat.com&gt; wrote: On 11/13/2013 03:58 AM, Paul Jansen wrote: > Hi Rene. > I specifically need the scsi support (virtio-scsi). > I do know about the virtio-block support, which results in /dev/vd* > devices as you say. > From what I read even EL6 earlier than 6.3 does not support virtio-scsi > > Alternatively, does oVirt support an emulated scsi adapter of a > different type that would allow me to see scsi disks? may i ask why do you need the virtual disks to specifically be scsi? > > Regards, > Paul > > > On Wednesday, 13 November 2013 7:23 PM, René Koch (ovido) > < r.koch(a)ovido.at > wrote: > On Wed, 2013-11-13 at 09:41 +0100, Sander Grendelman wrote: > > According to https://access.redhat.com/site/solutions/20511 > < https://access.redhat.com/site/solutions/20511 >virtio > > work on > rhel5.3. > > > > You have to edit /etc/modprobe.conf and generate a new initrd. > > > If you're installing the OS on a VirtIO disk this is done automatically > by anaconda. I just installed RHEL 5 on oVirt 3.3 with VirtIO disk and > everything worked out of the box. > > > > > > On Wed, Nov 13, 2013 at 9:32 AM, Sven Kieske < S.Kieske(a)mittwald.de > <mailto: S.Kieske(a)mittwald.de >> wrote: > > > Hi, > > > > > > afaik the rhel 5 kernel series just has not the necessary drivers for > > > all virtio stuff, so it's not supported and does not work, unless > > > you want to patch your own kernel. > > > > > > Am 13.11.2013 06:44, schrieb Paul Jansen: > > >> I have just set up an Ovirt 3.3.0 install and have done a test > install of Centos 6.4 in a VM. The VM was configured with an IDE drive > and a virtio-scsi drive. The Centos 6.4 install sees both drives OK. > > >> I'm wanting to do some testing on a product that is based on EL5, > but I'm finding that it cannot see the virtio-scsi drive. It does show > up in the output of 'lspci', but I don't see a corresponding 'sd' device. > > >> > > > There's no /dev/sd* device - the devices are named /dev/vd*... > > > > >> I've just tried installing Centos 5.10 and the support is not there. > > > Didn't test CentOS but RHEL 5 is working fine. > > > Regards, > René > > > > > >> > > >> Does anyone know of any tricks to allow EL5 to see the virtio-scsi > device? > > > > > > > > > -- > > > Mit freundlichen Grüßen / Regards > > > > > > Sven Kieske > > > > > > Systemadministrator > > > Mittwald CM Service GmbH & Co. KG > > > Königsberger Straße 6 > > > 32339 Espelkamp > > > T: +49-5772-293-100 > > > F: +49-5772-293-333 > > > https://www.mittwald.de < https://www.mittwald.de/ > > > > Geschäftsführer: Robert Meyer > > > St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad > Oeynhausen > > > Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad > Oeynhausen > > > _______________________________________________ > > > Users mailing list > > > Users(a)ovirt.org <mailto: Users(a)ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/users > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org <mailto: Users(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/users > > > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users