[Engine-devel] Issues with VirtIO-SCSI

[Daniel Erez]

----- Original Message -----
> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, September 24, 2013 12:34:17 AM
> Subject: RE: [Engine-devel] Issues with VirtIO-SCSI
> 
> Hi Daniel,
> 
> I asked this question because I have implemented a filter to show only
> compatible disk interfaces (in change #17964). The main purpose of this
> patch is to hide the IDE interface type when creating disks for PPC64 VMs
> (since IDE is not supported on this architecture). If it was decided that
> the VirtIO-SCSI interface type should be hidden from the user in case it was
> disabled, I would have to modify that patch a little bit.

For consistency, I'll filter the interface from the list when VirtIO-SCSI is disabled.
So yeah, keep that in mind when modifying your patch.

> 
> Another issue is that in change #18622 the support for a PPC64-specific
> controller, the SPAPR VSCSI controller, was introduced. But the code was
> created based on the assumption that the VirtIO-SCSI controller was always
> present, and this isn't the case anymore. And another patch that I will work
> on really soon will add support to create disks that are connected to this
> interface.

Can you filter the option out or add a warning when VirtIO-SCSI is disabled?

> 
> So, I would like some feedback before changing these patches. Is a validation
> on the backend enough to block the user from using an inexistent controller?
> Should the frontend be changed as well? What would be a good approach to
> handle multiple SCSI controllers in a VM (were the presence of one of them
> is optional)?

You should block it in the engine on canDo and filter the option / warn about it in the UI.
Regarding multiple controllers, are you referring to multiple types of controllers
or just multiple VirtIO-SCSI devices?

> 
> Thanks,
> Vitor
> 
> 
> 
> >-----Original Message-----
> >From: Daniel Erez [mailto:derez at redhat.com]
> >Sent: segunda-feira, 23 de setembro de 2013 17:06
> >To: Vitor de Lima
> >Cc: engine-devel at ovirt.org
> >Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
> >
> >Hi Vitor,
> >
> >The new VirtIO-SCSI enabled checkbox is an indication whether to attach a
> >VirtIO-SCSI controller when running the VM.
> >It should be enabled automatically on cluster >= 3.3.
> >
> >When disabled, I think it's preferable not to add a new controller
> >automatically
> >when running the VM as it requires creating/attaching a new VmDevice -
> >which we refrain of on VmInfoBuilder flows (and since it might be confusing
> >to
> >the user...).
> >
> >As an alternative, I've planned to add a warning in the dialog or create a
> >canDo
> >message to prevent running the VM at all.
> >I'm not sure we should hide the option from disk interfaces list as it's
> >already
> >being filtered using VirtIoScsiEnabled ConfigurationValue (and using OsInfo
> >soon...).
> >
> >Let me know what you think and thanks a lot for the input!
> >
> >Daniel
> >
> >----- Original Message -----
> >> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
> >> To: engine-devel at ovirt.org
> >> Sent: Monday, September 23, 2013 10:42:39 PM
> >> Subject: [Engine-devel] Issues with VirtIO-SCSI
> >>
> >> Hi everyone,
> >>
> >> I have found some issues with this patch:
> >>
> >> http://gerrit.ovirt.org/#/c/18638/
> >>
> >> It allows the user to disable the VirtIO-SCSI disk interface during
> >> the VM creation. The problem is that the user still can add, attach
> >> and hotplug disks with the VirtIO-SCSI interface type, but when the
> >> user does so, libvirt automatically creates a LSI Logic SCSI
> >> controller and connects the new disk to it.
> >>
> >> How can this problem be solved? Should the VirtIO-SCSI interface type
> >> be hidden from the user in case it wasn't enabled, or should the
> >> engine enable the VirtIO-SCSI controller, hotplug it, then hotplug the
> >> disk into it transparently?
> >>
> >> Thanks,
> >> Vitor de Lima
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
>