3:02 p.m.
--_000_B2CAFC4D5E2D574A883EF61ACD5ADE330180A712SERV070corpeldo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi everyone,
I wrote some code to run a VM on a IBM POWER host, but I stumbled in some i=
ssues 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 (cal=
led SPAPR), which is not available in x86-64. Currently I'm solving this pr=
oblem by using (in the VmInfoBuilder class):
if (vm.getArchitecture().equals(ArchitectureType.ppc64)) {
Map<String, Object> struct =3D new HashMap<String, Object <head <meta http-equiv=3D"Content-Type"
content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft
Word 14 (filtered medium)" <style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" / </xml><![endif]--><!--[if gte mso
9]><xml <o:shapelayout
v:ext=3D"edit" <o:idmap v:ext=3D"edit"
data=3D"1" /
</o:shapelayout></xml><![endif]--
</head <body lang=3D"PT-BR"
link=3D"blue" vlink=3D"purple" <div
class=3D"WordSection1" <p
class=3D"MsoNormal"><span lang=3D"EN-US">Hi
everyone,<o:p></o:p></span><=
/p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">I wrote some code to run a VM o=
n a IBM POWER host, but I stumbled in some issues that will need a little b=
it of refactoring in the current code and I would like some feedback.<o:p><=
/o:p></span></p <p
class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">The first issue is that KVM on =
POWER requires a special SCSI interface (called SPAPR), which is not availa=
ble in x86-64. Currently I’m solving this problem by using (in the Vm=
InfoBuilder class):<o:p></o:p></span></p <p
class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">if (vm.getArchitecture().equals=
(ArchitectureType.ppc64)) {<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; Map<String, Object>
struct =3D new=
HashMap<String, Object>();<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; struct.put(VdsProperties.Type,
VmDevice=
Type.CONTROLLER.getName());<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; struct.put(VdsProperties.Device,
VdsPro=
perties.Scsi);<o:p></o:p></span></p <p
class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; // Create a controller in the index 1, the
Vi=
rtIO_SCSI interface is in index 0<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; struct.put(VdsProperties.Index,
"1=
");<o:p></o:p></span></p <p
class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; Map<String, String>
spaprAddress =
=3D new HashMap<String,
String>();<o:p></o:p></span></p <p
class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp;
spaprAddress.put("type", &quo=
t;spapr-vio");<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; struct.put(VdsProperties.Address,
spapr=
Address);<o:p></o:p></span></p <p
class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp;
devices.add(struct);<o:p></o:p></=
span></p <p
class=3D"MsoNormal"><span
lang=3D"EN-US">}<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">But this is a poor solution, be=
cause this class would be polluted by architectural differences. Another th=
ing to notice is that since in IBM POWER there are two SCSI controllers, al=
l 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” clas=
s 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.<o:p></o:p></span></p <p
class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">The second issue is that the CD=
-ROM interface is SCSI on POWER guests (and must be attached to the SPAPR i=
nterface) and IDE on the x86_64, this information could be retrieved from t=
he osinfo (by creating a property there)
or It could be hard-coded in the strategy
class.<o:p></o:p></span></p <p
class=3D"MsoNormal"><span lang=3D"EN-US">Which would be the
best way to =
handle this difference?<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">The third and final issue is th=
at when the VNC protocol is used in a VM, by default a Cirrus Logic VGA dev=
ice is created. This device is not supported on POWER guests, but the stand=
ard VGA device is. I made a workaround,
but the issue is where to put this association between the device type and=
the display protocol.<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">Should it also be a property in=
the osinfo? Or it should be handled in the strategy
class?<o:p></o:p></spa=
n></p <p
class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p </div
</body </html
--_000_B2CAFC4D5E2D574A883EF61ACD5ADE330180A712SERV070corpeldo_--
();
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 =3D 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 archit=
ectural differences. Another thing to notice is that since in IBM POWER the=
re are two SCSI controllers, all the SCSI devices must have their SCSI addr=
ess 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 inform=
ation 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 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?
--_000_B2CAFC4D5E2D574A883EF61ACD5ADE330180A712SERV070corpeldo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml"
xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word"
=
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"
xmlns=3D"http:=
//www.w3.org/TR/REC-html40"
5:52 a.m.
On Aug 16, 2013, at 22:02 , Vitor de Lima <vitor.lima(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4214
days inactive
4218
days old
1 comments
2 participants
participants (2)
-
Michal Skrivanek -
Vitor de Lima