[Engine-devel] Issues with VirtIO-SCSI

Tue Sep 24 17:58:04 UTC 2013

----- 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 6:52:46 PM
> Subject: RE: [Engine-devel] Issues with VirtIO-SCSI
> 
> Hi Daniel,
> 
> I was referring to multiple types of controllers. For now, I think it is
> enough to have only one optional VirtIO-SCSI controller per VM, and (on the
> ppc64) one obligatory SPAPR VSCSI controller. The main question is how to
> handle the addresses when the VirtIO-SCSI is disabled and there is only the
> SPAPR VSCSI controller, and how to handle if the user enables VirtIO-SCSI
> after the creation of the VM (I think the addresses for the existing disks
> must remain stable, so the controller index must be 1 for the VirtIO-SCSI
> and 0 for the SPAPR VSCSI in this case).
> 
> Do you have any tips on how to implement the disk/cdrom addressing in these
> cases?

Regarding the controllers, the address of each controller should be kept
separately - i.e. saved as a VmDevice for maintaining a stable address.
Most changes should probably be done on VmDeviceUtils (look at updateVmDevices 
and copyVmDevice methods) and VmInfoBuilder. Disk/cdrom devices should
be treated similarly. 
As for changing the disk interface, we're clearing the device's address
when switching an interface; so I don't think there's an issue there.
More info on stable addresses can be found here:
http://www.ovirt.org/Features/Design/StableDeviceAddresses

> 
> Thanks,
> Vitor
> 
> 
> >-----Original Message-----
> >From: Daniel Erez [mailto:derez at redhat.com]
> >Sent: terça-feira, 24 de setembro de 2013 09:31
> >To: Vitor de Lima
> >Cc: engine-devel at ovirt.org
> >Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
> >
> >
> >
> >----- 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
> >> >>
> >>
>