[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
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@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
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. 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. 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)? Thanks, Vitor
-----Original Message----- From: Daniel Erez [mailto:derez@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.lima@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
----- Original Message -----
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.
That is not the case. Point is to allow users to add a scsi controller to a VM that does not have any scsi disks. This is needed in case the user would later on like to hotplug scsi disks. Without this, hotplug would fail since there is no scsi controller in the VM. When the VM is down, you can always attach a scsi disk and if there is no scsi controller then engine will automatically add one.
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.
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)?
If you have a need for a VM with more than 256 LUNs then I'd say that the easiest behaviour to understand would be to hide the existence of the controllers from the user altogether and just add support to automatically hotplug controllers on the fly when existing controllers are reaching their limit.
Thanks, Vitor
-----Original Message----- From: Daniel Erez [mailto:derez@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.lima@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
----- Original Message -----
From: "Vitor de Lima" <vitor.lima@eldorado.org.br> To: "Daniel Erez" <derez@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:derez@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.lima@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
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? Thanks, Vitor
-----Original Message----- From: Daniel Erez [mailto:derez@redhat.com] Sent: terça-feira, 24 de setembro de 2013 09:31 To: Vitor de Lima Cc: engine-devel@ovirt.org Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
----- Original Message -----
From: "Vitor de Lima" <vitor.lima@eldorado.org.br> To: "Daniel Erez" <derez@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:derez@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.lima@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
----- Original Message -----
From: "Vitor de Lima" <vitor.lima@eldorado.org.br> To: "Daniel Erez" <derez@redhat.com> Cc: engine-devel@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@redhat.com] Sent: terça-feira, 24 de setembro de 2013 09:31 To: Vitor de Lima Cc: engine-devel@ovirt.org Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
----- Original Message -----
From: "Vitor de Lima" <vitor.lima@eldorado.org.br> To: "Daniel Erez" <derez@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:derez@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.lima@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
participants (3)
-
Ayal Baron -
Daniel Erez -
Vitor de Lima