Re: xenopsd success for booting mirage kernels

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 14 Feb 2013, at 22:25, Dave Scott <Dave.Scott@xxxxxxxxxxxxx> wrote:
> 
> Yeah, I've been using "xl". However I just packaged squeezed, the memory 
> ballooning daemon... If this is working properly then it'll balloon dom0 
> down-- I'll test this in a while.

Superb; xl failed to set the memory for some other reason (my notes are at 
home), but I'll ignore that in favour of squeezed.

>> 
>> - the VM UUIDs are hidden, but the cmdline only takes the VM name.  This 
>> means I can add multiple VMs with the same text name, but only address the 
>> last one.
> 
> Oops, probably should accept both names and uuids. To clean up you can delete 
> the json files from /var/run/nonpersistent/xenops if you need to.

Sounds good. What do you think about just defaulting it to the memory fs 
instead of the filesystem one to be even more zero-configuration by default?

> Will mirari talk the xenops API directly? In my dev branch I automatically 
> chgrp'd the xenops socket to the "xapi" group to give me access without 
> sudo-- would that help?

Ideally, yes.  The xenops-cli JSON interface is very simple to use, and it 
would be easier/nicer to just manage the lifecycle of the VM directly.

Do be careful about depending on the filesystem permissions for domain sockets. 
 Linux respects this, but traditionally they've been ignored by BSD variants.

How about listening on HTTP with a RESTful interface?  That would make 
debugging via curl quite easy.  Just need to write a nice cohttp_rest.ml, 
perhaps as a lens?

(PS: could you upstream the Cohttp_posix_unbuffered_io when you get a chance?  
I need to think about how to best support this in the overall interface.  
You're using it to be able to pass off the fd to another process, but does this 
also handle the case of weird body encodings that require knowledge from the 
HTTP headers?)


-anil