Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables"

[Gabriel L. Somlo]

On Wed, Feb 04, 2015 at 03:24:32PM +0000, Daniel P. Berrange wrote:
> Yes, there is some overhead in setting up QEMU on the host to provide
> the data cloud-init needs, but it isn't all that difficult. For example
> Rich Jones describes how to setup a virtual disk for cloud-init
> 
>   
> https://rwmj.wordpress.com/2013/12/10/creating-a-cloud-init-config-disk-for-non-cloud-boots/
> 
> Given the prevalence of cloud-init across distros, I think you'll be hard
> pressed to get them to support an alternative method, even if it is a bit
> simpler at the QEMU setup level.

Have a look at this:

http://www.vmware.com/pdf/Scripting_API_23.pdf

(page 36, GuestInfo Variables).

It's a rather generic, flexible feature. Some people use it for
early boot, but that's just one of the many use cases, so maybe
focusing on "how to implement early boot configuration" is going
a bit off on a tangent :)

I'd like to add that mechanism (or at least the host->guest bits)
to qemu, for "feature parity". That should be a good thing, making
it easier to port "whatever" to qemu, without having to massively
rearchitect it to work around a missing feature...

Also, it's really non-intrusive. At this point, I could implement it
by passing environment strings in via "-smbios file=./Type11EnvStrBlob",
and read them on the guest side via 'dmidecode -t11', with some grep
and awk magic thrown in for good measure :)

But I'd really love to wrap it in some syntactic sugar, so that
it could eventually be exposed via virsh and virt-manager, so that
people used to VMWare and guestinfo variables can migrate things
over to qemu/kvm in a relatively painless way. And some of them will
use it for early boot, but hey, who am I to argue. I'm all about
"mechanism", and prefer leaving "policy" to the user :)

Thanks much,
--Gabriel