uvtool-libvirt needs arch specific templates

Bug #1452016 reported by Ryan Harper on 2015-05-05
38
This bug affects 4 people
Affects Status Importance Assigned to Milestone
uvtool
Undecided
Unassigned
uvtool (Ubuntu)
Wishlist
Unassigned

Bug Description

uvt-kvm currently has only one template for creating KVM guests. The template hardcodes x86-specific values which are not available on non-x86 (arm and ppc64el). Ideally, uvtool could do something like /usr/share/uvtool/$arch-template.xml though we'll need something to handle things like uname -m returning ppc64le, and the "arch" of the packages being ppc64el.

I'll attach a functional template for ppc64le that I can specify via uvt-kvm create 's cli.

1. $ lsb_release -rd
Description: Ubuntu 15.04
Release: 15.04
2. $ apt-cache policy uvtool-libvirt
uvtool-libvirt:
  Installed: 0~bzr99-0ubuntu1
  Candidate: 0~bzr99-0ubuntu1
  Version table:
 *** 0~bzr99-0ubuntu1 0
        500 http://ports.ubuntu.com/ubuntu-ports/ vivid/universe ppc64el Packages
        100 /var/lib/dpkg/status
3. uvt-kvm create --memory 512 --cpu 1 --disk 10 test1 creates a kvm instance on ppc64el host.
4. failed to create the instances because the template wasn't valid for ppc64el guest.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: uvtool-libvirt 0~bzr99-0ubuntu1
ProcVersionSignature: User Name 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic ppc64le
ApportVersion: 2.17.2-0ubuntu1
Architecture: ppc64el
Date: Tue May 5 19:52:52 2015
PackageArchitecture: all
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcLoadAvg: 0.67 0.50 0.50 2/1422 15068
ProcLocks:
 1: POSIX ADVISORY WRITE 3552 00:12:125109 0 0
 2: POSIX ADVISORY WRITE 2114 00:12:99335 0 EOF
 3: POSIX ADVISORY WRITE 2130 00:12:90143 0 EOF
 4: FLOCK ADVISORY WRITE 2181 00:12:93227 0 EOF
ProcSwaps:
 Filename Type Size Used Priority
 /swap.img file 8388544 0 -1
ProcVersion: Linux version 3.19.0-15-generic (buildd@fisher02) (gcc version 4.9.2 (User Name 4.9.2-10ubuntu13) ) #15-User Name SMP Thu Apr 16 23:32:13 UTC 2015
SourcePackage: uvtool
UpgradeStatus: No upgrade log present (probably fresh install)
cpu_cores: Number of cores present = 20
cpu_coreson: Number of cores online = 20
cpu_smt: SMT is off

Related branches

Ryan Harper (raharper) wrote :
Ryan Harper (raharper) wrote :

<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>

Robie Basak (racb) on 2015-05-06
Changed in uvtool (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
Robie Basak (racb) on 2016-10-07
tags: added: architecture
Changed in uvtool:
status: New → Triaged
ChristianEhrhardt (paelzer) wrote :

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.

ChristianEhrhardt (paelzer) wrote :

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.

ChristianEhrhardt (paelzer) wrote :

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>

ChristianEhrhardt (paelzer) wrote :

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.

ChristianEhrhardt (paelzer) wrote :

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.

ChristianEhrhardt (paelzer) wrote :

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.

tags: added: s390x
ChristianEhrhardt (paelzer) wrote :

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

ChristianEhrhardt (paelzer) wrote :

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.

ChristianEhrhardt (paelzer) wrote :

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.

ChristianEhrhardt (paelzer) wrote :

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

ChristianEhrhardt (paelzer) wrote :

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

ChristianEhrhardt (paelzer) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in uvtool (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers