Hi everyone,<=3D /p>

I wrote some code to run a = VM o=3D n a IBM POWER host, but I stumbled in some issues that will need a little b= =3D it of refactoring in the current code and I would like some feedback.<= =3D /o:p>

The first issue is that KVM= on =3D POWER requires a special SCSI interface (called SPAPR), which is not availa= =3D ble in x86-64. Currently I’m solving this problem by using (in the Vm= =3D InfoBuilder class):

if (vm.getArchitecture().eq= uals=3D (ArchitectureType.ppc64)) {

&nb= sp;&=3D nbsp; Map<String, Object> struct =3D3D n= ew=3D HashMap<String, Object>();

&nb= sp;&=3D nbsp; struct.put(VdsProperties.Type, VmDevice= =3D Type.CONTROLLER.getName());

&nb= sp;&=3D nbsp; struct.put(VdsProperties.Device, VdsPro= =3D perties.Scsi);

&nb= sp;&=3D nbsp; // Create a controller in the index 1, the Vi= =3D rtIO_SCSI interface is in index 0

&nb= sp;&=3D nbsp; struct.put(VdsProperties.Index, "1= =3D ");

&nb= sp;&=3D nbsp; Map<String, String> spaprAddress = =3D =3D3D new HashMap<String, String>();

&nb= sp;&=3D nbsp; spaprAddress.put("type", &quo= =3D t;spapr-vio");

&nb= sp;&=3D nbsp; struct.put(VdsProperties.Address, spapr= =3D Address);

&nb= sp;&=3D nbsp; devices.add(struct);

}

But this is a poor solution= , be=3D cause this class would be polluted by architectural differences. Another th= =3D ing to notice is that since in IBM POWER there are two SCSI controllers, al= =3D l the SCSI devices must have their SCSI address explicitly defined (it was not needed before, since there was just= =3D one controller before). It was proposed that a “strategy” clas= =3D s could solve the problem, but I would like to have some feedback on which = =3D package it should be, since it will also be used in the bll package to validate other stuff.

The second issue is that th= e CD=3D -ROM interface is SCSI on POWER guests (and must be attached to the SPAPR i= =3D nterface) and IDE on the x86_64, this information could be retrieved from t= =3D he osinfo (by creating a property there) or It could be hard-coded in the strategy class.

Which would be the best way= to =3D handle this difference?

The third and final issue i= s th=3D at when the VNC protocol is used in a VM, by default a Cirrus Logic VGA dev= =3D ice is created. This device is not supported on POWER guests, but the stand= =3D ard VGA device is. I made a workaround, but the issue is where to put this association between the device type and= =3D the display protocol.

Should it also be a propert= y in=3D the osinfo? Or it should be handled in the strategy class?