uvtool-libvirt needs arch specific templates

<domain type='kvm'>
  <os>
    <type arch="ppc64le" machine="pseries">hvm</type>
    <boot dev='hd' />
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <devices>
    <interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/3'/>
      <target port='0'/>
    </serial>
    <graphics type='vnc' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>
    <video/>
  </devices>
</domain>

I didn't track when, but the current default template just specifies less arch specific options:
For the diff of arch/machine it does:
  <type>hvm</type>

That gets autoextended to:
<type arch='ppc64le' machine='pseries-xenial'>hvm</type>

And is working just fine.

That said, I still like the suggested approach of a /usr/share/uvtool/$arch-template.xml in general.
And OTOH for s390 we really still need a different template.

From the Dup to keep s390 in mind:

s390 needs as known atm:
--- /usr/share/uvtool/libvirt/template.xml 2015-04-13 16:32:11.000000000 +0000
+++ s390-template.xml 2016-09-16 08:00:36.359676789 +0000
@@ -13,13 +13,10 @@
       <source network='default'/>
       <model type='virtio'/>
     </interface>
- <serial type='pty'>
+ <console type='pty' tty='/dev/pts/3'>
       <source path='/dev/pts/3'/>
- <target port='0'/>
- </serial>
- <graphics type='vnc' autoport='yes' listen='127.0.0.1'>
- <listen type='address' address='127.0.0.1'/>
- </graphics>
- <video/>
+ <target type='sclp' port='0'/>
+ <alias name='console0'/>
+ </console>
   </devices>
 </domain>

But needs more thinking as Rbasak stated:
We think that this template change may break the --log-console-output uvt-kvm create option, so how we approach this may need a rethink.

The following would be a template for a cavium thunderx arm server.
Other arm systems might need slightly different.

TL;DR changes to the default:
- virt + gic version 3 feature
- host cpu match (as detection is broken)

Details:
<domain type='kvm'>
        <os>
                <type arch='aarch64' machine='virt'>hvm</type>
                <boot dev='hd'/>
        </os>
        <features>
                <pae/>
                <gic version='3'/>
        </features>
        <cpu mode='custom' match='exact'>
                <model fallback='allow'>host</model>
        </cpu>
        <devices>
                <interface type='network'>
                        <source network='default'/>
                        <model type='virtio'/>
                </interface>
                <serial type='pty'>
                        <source path='/dev/pts/3'/>
                        <target port='0'/>
                </serial>
        </devices>
</domain>

For Arm to really do something we also need a loader section.
Something that worked for me with cloud images was:

   <loader readonly='yes' type='pflash'>/usr/share/AAVMF/AAVMF_CODE.fd</loader>
   <nvram template='/usr/share/AAVMF/AAVMF_CODE.fd'>/tmp/<insertsomegeneratednamelikeguestname>-flash1.img</nvram>

Unfortunately that depends a lot on the platform, but FYI to track it here with the other per arch things.

The template should end in _VARS not CODE, but since the only important bit seems to be the size it is working as well as above. But if ever implemented, take _VARS please if it changes.

For the controller to really work on arm you'd also need:
 <controller type='virtio-serial' index='0'>
   <address type='virtio-mmio'/>
 </controller>

Unfortunately it still lacks an easy way to boot from the cloud image.

I was able today to use the rally to sort out the arm issues we had on console.
The following is the most simple template that works on arm atm:

Along that the undefine calls on arm will need --nvram to be able to delete it.

<domain type='kvm'>
        <os>
                <type arch='aarch64' machine='virt'>hvm</type>
                <loader readonly='yes' type='pflash'>/usr/share/AAVMF/AAVMF_CODE.fd</loader>
                <nvram template='/usr/share/AAVMF/AAVMF_CODE.fd'>/tmp/AAVMF_CODE.fd</nvram>
                <boot dev='hd'/>
        </os>
        <features>
                <acpi/>
                <apic/>
                <pae/>
        </features>
        <cpu mode='custom' match='exact'>
                <model fallback='allow'>host</model>
        </cpu>
        <devices>
                <interface type='network'>
                        <source network='default'/>
                        <model type='virtio'/>
                </interface>
                <console type='pty'>
                        <target type='serial' port='0'/>
                </console>
        </devices>
</domain>

Steps:
1. add guest-arch option defaulting to current systems arch
2. deliver all arches (we know templates) xml files
3. select by guestarch
4. -L adds some console things, if on s390 refuse since it isn't working
well there
5. add --nvram to undefine on arm
6. get all that into a a MP for review

I have some preliminary tests in https://bileto.ubuntu.com/#/ticket/2972 but yet need to fix them up.
Storing that info here to re-find it after PTO.

After some checks of the old MP (to carry all that was discussed / invented before) I deleted the old MP. Now started testing the new one before pushing.

Testable builds in https://bileto.ubuntu.com/#/ticket/2972
But have to wait until I handled more urgent issues

After one more iteration testing is good on arm, s390x and power (as well as regression checks on x86).
So I pushed the commits for review and acceptance.

I needed no changes in debian/* (other than debian/changelog).
As discussed I propose against upstream but I'll add a suggested changelog content as commit message.

Proposal at: https://code.launchpad.net/~paelzer/uvtool/+git/uvtool/+merge/332412

Proposal is merged, looking forward to the next set of uploads to fix it in a release.

This bug was fixed in the package uvtool - 0~git136-0ubuntu1

---------------
uvtool (0~git136-0ubuntu1) bionic; urgency=medium

  * New upstream snapshot: ship tested templates for some non-Intel
    architectures and use them automatically when on those platforms.
    Thanks to Christian Ehrhardt. LP: #1452016.

 -- Robie Basak <email address hidden> Thu, 07 Dec 2017 10:26:51 +0000