Re: [RFC PATCH 5/8] lib/oeqa/utils/qemurunner.py: class to handle qemu instance

["Stanacar, StefanX" <stefanx.stanacar@intel.com>]

Hi Colin,

On Mon, 2013-08-05 at 21:50 +0200, Colin Walters wrote:
> On Fri, 2013-06-28 at 13:04 +0300, Stefan Stanacar wrote:
> 
> > +        self.streampath = '/tmp/qemuconnection.%s' % os.getpid()
> 
> That's a security problem on shared machines.

I know this is a late reply, sorry, I missed the email back then.
This has been changed since then to something else (but the reasons were
different)
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0ba78c1162bb125850a0ee504ca6fbe5bf21247f
That's a tcp socket localhost only now, random high port (calls bind
with 127.0.0.1, 0 so the os chooses the port).


> 
> > +                bb.note("Reached login banner")
> > +                console.write("root\n")
> > +                (index, match, text) = console.expect([r"(root@[\w-]+:~#)"],10)
> 
> So I forget if I've mentioned this here, but what I do for the
> gnome-ostree testing is at boot time, use a qcow2 overlay disk to write
> a custom systemd service that exports the journal over a virtio-serial
> channel.  Then I look for specific MESSAGE_IDs in the journal.
> 
> This is extremely reliable, no parsing of log messages etc.
> 

That sounds really cool, nice job! 
I might be wrong but doesn't that require virtio support in the target
kernel (which is something we can't expect to have)?

Cheers,
Stefan

> See:
> https://rwmj.wordpress.com/2013/07/19/half-baked-ideas-ocr-vm-console-to-diagnose-state-and-errors/
> 
>