[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Driver domains communication protocol proposal

George Dunlap writes ("Re: [Xen-devel] Driver domains communication protocol 
> Ah, so what you're calling "vdi" in this case is a thing into which
> vbd's can plug -- what we might call the backend "node" for a
> particular disk image?


> So we have:
> [A] <--> [B] <--> { [C], [D], [E] }
> Where:
> * A is the actual disk image on stable storage somewhere
> * B is the instance of the code that can access A and provide access
> to VMs which connect to it (not persistent)
> * C D and E are instances of code running inside the guest which
> connect to B and provide a block device to the guest OS which looks
> like A (again not persistent)
> Is that correct?


> I think calling A a "virtual disk image" makes the most sense; reusing
> that name for B is a bad idea given that it's already used for A in
> XenServer terminology.  (Jonathan, correct me if I'm wrong here.)


> I think that calling C D and E "vbd"s also makes sense.
> So we just need to have a good name for the running instance of a
> blockback process / thread / whatever that accesses a particular VDI.
> Virtual disk provider (VDP)? Block back instance (BBI)?  Virtual block
> backend (VBB)?

Anything with "backend" in it is probably wrong because in general C,
D and E are backend/frontend pairs.

The thing that B has that A (the vdi) hasn't is that B has done all
the preparatory work necessary for accessing the vdi apart from
anything that involves exclusivity.

"nonexclusive image context" aka "nic" ? :-)
"nonexclusive image handle" aka "nih" :-)
"preparatory exclusive (not) image session" ?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.