custom libvirt xml configs

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I need to "play" with custom xml configs, in order to get hardware
info via dmidecode inside a VM.

According to these - it should be possible.:
https://github.com/QubesOS/qubes-issues/issues/1798
https://github.com/woju/qubes-core-admin/commit/9dc37c1ee7feaf72fc90d4eb
1677ea1ca2275b7f
https://libvirt.org/formatdomain.html


I just tried to extend the default xml template, according to this:
https://dev.qubes-os.org/projects/core-admin/en/latest/libvirt.html

so created a new file:
/usr/share/qubes/templateslibvirt/xen/by-name/<name>.xml
where <name> is the VM name I would need the effect.

I can get "some effect" as if I make a mistake in that file content,
the corresponding VM will fail to start...

When the content seems correct, the VM starts fine, but dmidecode
still has no output.

attached the content of the custom xml config.

(for the final result, I would needs to include a SLIC data as well,
for activating OEM windows VM)

using Qubes 4.0.1-rc

Am I missed something?

Thanks.
- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlwkykAACgkQVjGlenYH
FQ1d8BAAqUowPxa2cBrgBM9sNwEsoA6zQuWE3SRM6rTK8lAAZxP+tKi/AbZ1uCWB
Kvx+7qI5rgJ4cliET/1rqBsqcsFXAdEgcRczfqU5IkThC1UQUEqHxtFlm2abybLQ
mQ98bRVsCsDx6A+S0eveSTvUAf7GO8uXUbaIrKx+wNZFS6oji/Hoe1mXzaL8bJCP
P2qR/PveUHiizxjwDFEUy484OvGRs4N3JDYJZmJ9qrzZ8AuU3TxUT6Gn8RdmoQpx
ME3E0raltEFWRQ6idAGbl5E/mjZN3glsmAAs7Czfcs8f1M33onkTJwmfwDhkem97
24kTMXvDCsB+HyL3/fY4B0pWJzQ4eeQfNCbgNWmyjcMR4lQAv5N5IOB14j+Hj6FN
7UvmozC3Qzk3KCpZe6xYHaaGT94acjlHhic6Mb2TM4m8VqYDw79x0twuYLr/vXuC
pwjlWcD6MXjEdwgrvPnW9uPZe393AImp7AJOjcxpyc1YErqb/id0YHIVbWwbHIrL
hNNqq8YVMFsoHsxWfEiEEyL8uDpx/hEAVOZf/ReAfdXu4cIxFR69K5T/upEFP9RE
AACO21JnvOmRHOK81Su7C8CQFXIq9dBm5xUGKIJ8adJYs1OAQBlMVakSYZX+sXju
FvB5ogh1Usj2xa4KEDWghi1CakmixSvVaiS5pF9KEtfSk0uZ/LQ=
=SS8j
-----END PGP SIGNATURE-----

[Wojtek Porczyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 27, 2018 at 01:49:14PM +0100, Zrubi wrote:
> I need to "play" with custom xml configs, in order to get hardware
> info via dmidecode inside a VM.

(...)
> Am I missed something?

That's not how jinja template inheritance works. After {% extends %} clause
nothing is generated unless it is part of {% block %} that references
preexisting block in parent template.

http://jinja.pocoo.org/docs/2.10/templates/#template-inheritance

Only this has any effect:

> {% extends 'libvirt/xen.xml' %}
> {% block os %}
> {{ super() }}
> <smbios mode='sysinfo'/>
> {% endblock %}

The following goes to /dev/null:

> <sysinfo type='smbios'>
> {% block sysinfo %}
> <bios>
> <entry name='Vendor'>Lenovo</entry>
> </bios>
> <system>
> <entry name='manufacturer'>Fedora</entry>
> <entry name='product'>Virt-Manager</entry>
> <entry name='version'>0.9.4</entry>
> </system>
> <baseBoard>
> <entry name='manufacturer'>LENOVO</entry>
> <entry name='product'>20BE0061MC</entry>
> <entry name='version'>0B98401 Pro</entry>
> <entry name='serial'>W1KS427111E</entry>
> </baseBoard>
> <chassis>
> <entry name='manufacturer'>Dell Inc.</entry>
> <entry name='version'>2.12</entry>
> <entry name='serial'>65X0XF2</entry>
> <entry name='asset'>40000101</entry>
> <entry name='sku'>Type3Sku1</entry>
> </chassis>
> <oemStrings>
> <entry>myappname:some arbitrary data</entry>
> <entry>otherappname:more arbitrary data</entry>
> </oemStrings>
> {% endblock %}
> </sysinfo>

1) <sysinfo> and </sysinfo> lines are not inside any {% block %}
2) there is no "sysinfo" block in parent template

For a quick-and-dirty hack, if you intend this <sysinfo> node to be a child of
<domain>, just append it to some preexisting block using super():

{% block basic %}
{{ super() }}
<sysinfo type='smbios'>
{# ... #}
</sysinfo>
{% endblock %}

Alternatively, we'd accept a patch against libvirt/xen.xml to add something
like this:

<sysinfo>
{% block sysinfo %}{% endblock %}
</sysinfo>

After that patch being merged, you could write in your config:

{% extends 'libvirt/xen.ml' %}
{% block sysinfo %}
<bios/>
<system/>
<baseBoard/>
{# ... #}
{% endblock %}

- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAlwk1FsACgkQv2vZMhA6
I1H9mhAAl4nBKfOiTx9EewX3PH0yisxWCfG+WRJADeaSS107HCl73g3BObqF52t2
De6zbCRqh0hAovFBxSz7OY00py9RpboO3/nduoScQkOxMoEIfRNkzxX6yHT6HsSU
KtY9FKzhaxAGZSqeni2te+CYc0UobZkvwS/Sm3v7o6E52sctBvNkg/Sr4bzmulxo
OvvShRU//DizPi9wXjNTBwykWIgx62CsSDa9fO9SO49S/EAtULxM3X1dGp7mVfeW
8Di0dDMLZNhzm0NczVVNnJUdG3ar1C8GuZzrNwRU7/ylWSj+PEE2zHT/asTZlSdp
16KDx6bXicwIfcNwH56LUxvMy5TQ/qm26DtKmd7+TGq0V5pjtdvjxPse5D8nA/83
BKwGyKmt8KtKeXXDv7UtcMXL8CKmt2C0+ijXR1mLGxmxmLnfTAvZT1KNCA0jnqvO
aewUAHZ7YD7Zx1jBQmEJj9PjXUf+3GzadhtYygnRG755YodPrSxzpOOPbQ5zFgta
I5Mi3pq+sJY99YgIjfMSwKlvB1Ii8Dd+V1TKSdUnjnmKlEIB9GhqjH64kF7sk00P
yHleLnETvkUh/Tk38LgP5Rk6DOGZQsiZZmF3BZEI9werKpf7aSWDKeqzohPvy6do
tKnNV084Yq+XGhf7ecSRQJZv4Wi2er2Xgm0KiY5jFP+HXPaqAuk=
=6KEz
-----END PGP SIGNATURE-----

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/27/18 2:32 PM, Wojtek Porczyk wrote:

> 1) <sysinfo> and </sysinfo> lines are not inside any {% block %} 2)
> there is no "sysinfo" block in parent template
>
> For a quick-and-dirty hack, if you intend this <sysinfo> node to be
> a child of <domain>, just append it to some preexisting block using
> super():
>
> {% block basic %} {{ super() }} <sysinfo type='smbios'> {# ... #}
> </sysinfo> {% endblock %}
>
> Alternatively, we'd accept a patch against libvirt/xen.xml to add
> something like this:
>
> <sysinfo> {% block sysinfo %}{% endblock %} </sysinfo>
>
> After that patch being merged, you could write in your config:
>
> {% extends 'libvirt/xen.ml' %} {% block sysinfo %} <bios/>
> <system/> <baseBoard/> {# ... #} {% endblock %}

Thanks, that part is much more clear now :)


Just tested several variations, including modifying the original xen.xml
However I have no success. It seems Xen always emulate smbios data, no
matter what settings are found in the xml.

According to libvirt documentation, it would be able to use the real
host data:
<os>
<smbios mode='host'/>
</os>

Is there any way to debug this part?
and/or to get the active configuration of a running domain?

Thanks.
- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlwk9Y4ACgkQVjGlenYH
FQ31nhAAin48KuCSwrHVukZRqo7wbaIEwzeOSK0tnmAl9xyF1GUurzgGdy3QfSOf
XZMtLUY+usQrSqyGi5bqq3M82P/iWQ3mNm95+lHIozVfJfeWs87K1fL+N7msA9kp
Pm9PK7dS+L1+eErbz5+Q85YFByFxE9CSdLavB0qQYeRHoj8d0wRpnM6gKrz//wwK
D/gr/csuF6o+CD29jNsoWyamS1z5CLOQ7Ti5CbJ7dMQTGOtbjFH60hwJ+Kdc/D09
smRpOhszOhsKAU1ruuQtWNqOxBYqPGZ5jWJUXAVo5KDlHlmg7uvesuNJhwhCUQ65
BLkLCkBkJGlt2Bk4qO1AJ/2VMDO6NAEYiDeWuz+X2kKLxnx7Cwm5H/LyQbdcWfBX
cHUExxRp3xBkZhBVgx9NSan6NV5Oe3XTmhvE1xJCwpd37I3RgEonmRfHn0hoKc8N
gFnwBESdpQwj7rnTDV9NJGhBq2UXj6oUDnA0ctyftXyaPoxMlmhBTLE0qiEYm7G8
ponQXFapYbTcVu+M4N58+rVSmtLR8vnhT/6Y/N87tqr0rVkj+drsfnvXhhlrFF0q
7fOSOd6NdbAA6I1sgsryXXl6eeeymf58cJV4wDtuhrsSIsMxXCaC+8N+IAEIzqWP
HRS1WR5q1U8B8jTCTaG024ibJkagXd1XLM3gcfedUUDeK7chvu0=
=P+t0
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It think libvirt Xen (libxl) driver does not support smbios options. Quick grep
on the sources says its supported only in qemu/kvm...
xl.cfg man page says something about smbios_firmware="STRING", but
doesn't look to be available through libvirt :/

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlwlB3AACgkQ24/THMrX
1yzjtQf/YNyfPhxelC7q4FtkjheWD03Q3i2u/UBr4/ZW6Q4afwIWoEpk5GQuYVV+
GqqlQUGvCu1yVahbW/Nnb+KlyLonCXCP7SDV/MOzsQCijk9W0BanqAjc4kNmvCjz
ZaiJCvP5yYbMSERgArHowi3vm04yvplgak6JmsbMaEPVGk0WYFnUqQGnZhdNwX4s
jfnmI6UK+pmysjnWB/pK4NMaUmk8sS6lwdEQt19tA/kbAYei6+RT9g+Rl/yd7Q9M
kR50U/c49lhjDBxkde1sLPp+46BAImqtWmHIUsMGlZXOMeORQ9oX2vmL8p7o0jfU
QUFn42eSfz3N7GvTcZg7eeah9NpVxg==
=aFRj
-----END PGP SIGNATURE-----

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/27/18 6:10 PM, Marek Marczykowski-Górecki wrote:

> It think libvirt Xen (libxl) driver does not support smbios
> options. Quick grep on the sources says its supported only in
> qemu/kvm... xl.cfg man page says something about
> smbios_firmware="STRING", but doesn't look to be available through
> libvirt :/

That's what I suspected :(

Thanks for the confirmation.

- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlwlKFIACgkQVjGlenYH
FQ3XCxAAj64RlXyAQ9LEXVT9gd0wxy7FgRasf/DrgNkdMUnJoVORPkFt9qhmIXRq
YUMGPXgF6SRDzm7L9G1EDKEc7UD5SkQz427xYCRf1XRuRNaEH8U8xpX8Tk1bVspS
zS62g0ucrz5zFX9hcGP/wSjU6I/jdAldl3BkN0450xUuXBOygEiSkANm5WCMQkgD
6LqxVWWrbVVFP47kufz10k5JK1i1tjQP6n9vYxdnYlgF1GVxzn2wP3mT0qGUctqt
JKeO/KI91esKX+SIlmUFxYstBXlwAw6W4eIlkU2tcQfSnTYdWcBkdBjUZm4DjXg/
T3PTRKrmFZmPLNw5hDAcp/php5rogcRC57FQ+6rCRs2tLsXstFIYhH4st/F8EN/w
4SCEz3Y+fm4M3STRDiOX+3DEZM0O8muy1sOQP+8lX0Pr2ecrNXEiT9CG/fUenUIj
usM3o8DIVlvjRFHrB+IRRb4V3Gxb6ibIT69I5G0e0ybFgWhEkHpHTGJSTe/6VO/8
KIjuaEIWRm/XdBhGDCnyIQIqCxM0osJzqZDt2VH7mgMhacUahKw1YZLw5jYQ7laz
uzjR9scVj4L//0Jfq4VBYBxb5uxmvMiPz7PUt2rjjEaEcjr9MNPx26hLRZ+Ukl5W
rCjS9hna9H4n9T+AikMgY1WM5rUOA9H9Wkpo2oRyLAy0c7VJNDQ=
=tYPx
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 27, 2018 at 08:30:48PM +0100, Zrubi wrote:
> On 12/27/18 6:10 PM, Marek Marczykowski-Górecki wrote:
>
> > It think libvirt Xen (libxl) driver does not support smbios
> > options. Quick grep on the sources says its supported only in
> > qemu/kvm... xl.cfg man page says something about
> > smbios_firmware="STRING", but doesn't look to be available through
> > libvirt :/
>
> That's what I suspected :(
>
> Thanks for the confirmation.

AFAIU, you try to provide licence key to Windows directly, right? Is
that about the key extracted from the same machine, or arbitrary one?
Having ability to automatically provide license key for Windows
installation, for those who got Windows with the hardware already would
be really cool! Maybe cool enough to convince me to make a libvirt patch
;)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlwlMCgACgkQ24/THMrX
1yzGwQf/XCJV9++ljdfZmG3W4MLTUwi8gr0SxkmGe/vM5xPu4ijAxtfespNe5LOX
wTBG72FiqD4kpdS18y+VCE7V9cijki4L6/E4Grdi+eAeShrv2lxS79D41337qosi
8VQdhqfzf6Uq0OEdsuw9038gx5wwM8p8l9iSUoFeRLFanZYgMnVHwGYzrDAT2bTj
wrtpGLKlclJa8mAks5wZlqP/5YkVcdmc1J1iFpyyYigcnjP3z/G9mBAv1DAYLw7M
0bAIjija/ORQnBVhVfrcH4CW0+xFMYZfjfxQwbIdB4udnGXF5ajPZ1tbcrmNGZD3
9Wg8GckxO+wM51fUFous3rkI5ip5iQ==
=a+vD
-----END PGP SIGNATURE-----

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/27/18 9:03 PM, Marek Marczykowski-Górecki wrote:

> AFAIU, you try to provide licence key to Windows directly, right?
> Is that about the key extracted from the same machine, or arbitrary
> one?

Yes, from the same one. As (nearly) all the machines are sold with a
BIOS integrated licence key. I found articles about how to ectract
this license:
https://github.com/ghuntley/seaslic

And according to the mentioned links, the resulted file can be
injected, and then your windows VM wold be happy and activated just as
your original hardware :)

To make this work, the smbios values are also needed, as most of these
keys are working only with a hardware provided by a specific vendor.
That would be the use case for a copy from host option:
<smbios mode='host'/>

> Having ability to automatically provide license key for Windows
> installation, for those who got Windows with the hardware already
> would be really cool! Maybe cool enough to convince me to make a
> libvirt patch ;)

Well, VMware workstation, and quemu/kvm/libvirt combo already provide
this feature for sure... So it would be a nice catch-up ;)

- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlwlNkEACgkQVjGlenYH
FQ2RaxAAtXqNimzJpuuPEQvDOl1XLioO7XKVM7Zyq23JEVsOSF0rsBlo3xdq4om1
0nI2KJU9jhYNzk+gFSAQqa3Qg0zuayEhwKHehJQLldONn9i+PyceDR0GJxVOxglj
DI6vCFZ4BKyoUEr0gzOP1ta4j+U4AOnSfz0z/QNAUAFrxqs7mPRPaiB40rAosieF
IWBxd37c5WnZLglnqok+2AZSSoGrG3kibhtzeGmHsyBuM842eVHnvIzpOhdL1eSa
5aYnS2ZoBasrFnNfg99LbU2NzCHioyEjspl2BCjIny17zhLqpGonBfgcfJztr3ko
vFlbsbeSrzdc5y7RHDcwMWu77I9OOyB4NlqgTobLsbH/QwzcxdxjsGv4bf5Qv+v2
3BIAHtALmKEPMqKZ6Qt94nYIlMAJHQPXlN9pKGF5flmqZxN4bc3WOCe8hmPoHTG+
dD4Xe7nP13Q5zwo7mFpqhOb1kCJtWNbjDt7ZBPcKQnmr9xvBOGmrimbw/tY3nu1l
8DhrUfdbYYxNXW8nH+7COT7fa+lkGQSLEdVXN01nh7UakltG8LfRk0fJNBFw1LtS
p+Q2appXXR1mwDdUPnRghipNBs7SbBl3YFcku2msiL64DJzbNidpDQHMfzceY2GK
GWAmSkR+gEepRxpAD863FeOGCuOO5zOAPonsBYvCqv4TBaOW0gc=
=eIJy
-----END PGP SIGNATURE-----

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/27/18 9:30 PM, Zrubi wrote:

> And according to the mentioned links, the resulted file can be
> injected, and then your windows VM wold be happy and activated just
> as your original hardware :)

here is te relevant part from the libvirt xml:
...
<os>
...
<acpi>
<table type='slic'>/path/to/slic.dat</table>
</acpi>
</os>
...

And here the doc clearly stats that this is a qemu only feature:

The table element contains a fully-qualified path to the ACPI table.
The type attribute contains the ACPI table type (currently only slic
is supported) Since 1.3.5 (QEMU only)

- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlwlO9kACgkQVjGlenYH
FQ1K8w/+PPIWwNnjzx9phHplxVHQPRruE2oagPsBKxfiQitq7zYD3bkupPWK/wpy
8Q4JbgSg9JDipqcIs5nty60wpADuRziibv/yVsuZU+K7/kuAiIWwQIOk/nLLz7SW
4EbJTYPadQa9QGlYgw58oiHKJSvXHGWZ6PFduDHpgpRk2g76X1XEqcGozdcw7uik
vkA9vJnMo1GJW6jNCN8HqxYrqXghoixd2qbDweBheCUjgMYLW5IcIFMdfmai02WV
lhk4aR3bYzXy0go049cziROu0sbLHSFhwEIKABtxuDIEwvc55T+9r3bt8sPVic1l
cqSgousyrvgShGFiVA5SQ5zyXB23bUvZ/6vmsk30wQ3K/ue38Gma+kp4kLCUTR0G
c8b6fi832oP0c2igk5yYaTNKU8IevZrb7SYFpeKUEGcftsL+YgmrgM+bhZ6dLxu4
BtMXQyzfw0n5IHqgNEjo8aAaf5mviPk4+Vy8E2HG0Gy944SDaZvE5dk6n0Qfozuc
ElutuHLA4qg9/50NWKzh4sYVGJyFD8ImkCmgTyr4LjiDP1TrOFE6Hl1B3VUrG9mJ
t9H/GCNXnkWPIezMlzYysE+agn1RDhjQhMyDX17cGFDEuQG0Y5BV1A+DwTAyFskC
tBCxfD5R4dT2xneluKXmUySswperaBmnjEaC7az8rRoTe+U15kk=
=HdZ/
-----END PGP SIGNATURE-----