[Engine-devel] Issues with IBM POWER support in oVirt engine

[Michal Skrivanek]

On Aug 16, 2013, at 22:02 , Vitor de Lima <vitor.lima at eldorado.org.br> wrote:

> Hi everyone,
>  
> I wrote some code to run a VM on a IBM POWER host, but I stumbled in some issues that will need a little bit of refactoring in the current code and I would like some feedback.
>  
> The first issue is that KVM on POWER requires a special SCSI interface (called SPAPR), which is not available in x86-64. Currently I’m solving this problem by using (in the VmInfoBuilder class):
>  
> if (vm.getArchitecture().equals(ArchitectureType.ppc64)) {
>            Map<String, Object> struct = new HashMap<String, Object>();
>             struct.put(VdsProperties.Type, VmDeviceType.CONTROLLER.getName());
>             struct.put(VdsProperties.Device, VdsProperties.Scsi);
>  
>            // Create a controller in the index 1, the VirtIO_SCSI interface is in index 0
>             struct.put(VdsProperties.Index, "1");
>  
>             Map<String, String> spaprAddress = new HashMap<String, String>();
>  
>             spaprAddress.put("type", "spapr-vio");
>  
>             struct.put(VdsProperties.Address, spaprAddress);
>              devices.add(struct);
> }
>  
> But this is a poor solution, because this class would be polluted by architectural differences. Another thing to notice is that since in IBM POWER there are two SCSI controllers, all the SCSI devices must have their SCSI address explicitly defined (it was not needed before, since there was just one controller before). It was proposed that a “strategy” class could solve the problem, but I would like to have some feedback on which package it should be, since it will also be used in the bll package to validate other stuff.
>  
> The second issue is that the CD-ROM interface is SCSI on POWER guests (and must be attached to the SPAPR interface) and IDE on the x86_64, this information could be retrieved from the osinfo (by creating a property there) or It could be hard-coded in the strategy class.
> Which would be the best way to handle this difference?

the strategy class might be sufficient for now, if it's not difficult/ugly

>  
> The third and final issue is that when the VNC protocol is used in a VM, by default a Cirrus Logic VGA device is created. This device is not supported on POWER guests, but the standard VGA device is. I made a workaround, but the issue is where to put this association between the device type and the display protocol.
> Should it also be a property in the osinfo? Or it should be handled in the strategy class?

we have a sort of mapping today that qxl means SPICE and cirrus means VNC, going forward we'd like to give a bit more flexibility, so elsewhere it was suggested to put into osinfo the list of supported devices/cards to pick from. I think it's still fine to use the simple "mapping", just add standard vga.
The meaning would be qxl means SPICE or VNC(user can pick - this is to allow both spice and vnc console access as you can use both on qxl in fact.), cirrus means VNC, vga would also mean VNC
osinfo would contain the list of devices and we just need to make sure cirrus and vga is exclusive as they both mean the same value in Edit VM protocol drop down box 

Thanks,
michal


>  
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel