----- Original Message ----- > From: "Vitor de Lima" <vitor.l...@eldorado.org.br> > To: "Daniel Erez" <de...@redhat.com> > Cc: engine-devel@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:de...@redhat.com] > >Sent: segunda-feira, 23 de setembro de 2013 17:06 > >To: Vitor de Lima > >Cc: engine-devel@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.l...@eldorado.org.br> > >> To: engine-devel@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@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
