qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] tcmu-runner and QEMU


From: Benoît Canet
Subject: Re: [Qemu-devel] tcmu-runner and QEMU
Date: Sat, 30 Aug 2014 00:46:27 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

The Friday 29 Aug 2014 à 15:36:41 (-0700), Andy Grover wrote :
> On 08/29/2014 11:51 AM, Benoît Canet wrote:
> >QMP is just a way to control QEMU via a socket: it is not particularly block 
> >related.
> >
> >On the other hand bringing the whole block layers into a tcmu-runner handler
> >would mean that there would be _one_ QMP socket opened
> >(by mean of wonderfull QEMU modules static variables :) to control multiple 
> >block devices
> >exported.
> >
> >So I think the configuration passed must be done before an individual open 
> >occurs:
> >being global to the .so implementing the tcmu-runner handler.
> >
> >But I don't see how to do it with the current API.
> 
> This discussion leads me to think we need to step back and discuss our
> requirements. I am looking for flexible backstores for SCSI-based fabrics,
> with as little new code as possible.

> I think you are looking for a way to
> export QEMU block devices over iSCSI and other fabrics?

true

> 
> I don't think making a LIO userspace handler into basically a full-fledged
> secondary QEMU server instance is the way to go. What I think better serves
> your requirements is to enable QEMU to configure LIO.

Ok as long as there is an efficient way for QEMU to process LIO requests.

> 
> In a previous email you wrote:
> >Another reason to do this is that the QEMU block layer brings
> >features like taking snapshots or streaming snaphots that a cloud
> >provider would want to keep while exporting QCOW2 as ISCSI or FCOE.
> 
> Whether a volume is exported over iSCSI or FCoE or not shouldn't affect how
> it is managed. QMP commands should go to the single QEMU server, which can
> then optionally configure LIO to export the volume. That leaves us with the
> issue that we'd need to arbitrate access to the backing file if taking a
> streaming snapshot (qemu and tcmu-runner processes both accessing the img),
> but that should be straightforward, or at least work that can be done in a
> second phase of development.

That makes sense that QEMU trigger the LIO export by itself because it will be
easier to integrate this feature into libvirt or another management stack.

Best regards

Benoît

> 
> Thoughts?
> 
> Regards -- Andy
> 
> p.s. offline Monday.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]