On Thu, Nov 09, 2017 at 02:54:35PM +0100, Markus Armbruster wrote:
> Max Reitz writes:
>
> > On 2017-11-02 13:02, Daniel P. Berrange wrote:
> > [...]
> >> One alternative approach to doing this would be to suggest that we should
> >> instead just spawn qemu-system-x86_64 with
Max Reitz writes:
> On 2017-11-02 13:02, Daniel P. Berrange wrote:
> [...]
>> One alternative approach to doing this would be to suggest that we should
>> instead just spawn qemu-system-x86_64 with '--machine none' and use that
>> as a replacement for qemu-nbd, since it
On Fri, Nov 03, 2017 at 10:04:57AM +, Stefan Hajnoczi wrote:
> On Thu, Nov 02, 2017 at 12:50:39PM -0500, Eric Blake wrote:
> > On 11/02/2017 12:04 PM, Daniel P. Berrange wrote:
> >
> > > vm-a-disk1.qcow2 open - its just a regular backing file setup.
> > >
> > >>
> > >>> |
On Thu, Nov 02, 2017 at 12:50:39PM -0500, Eric Blake wrote:
> On 11/02/2017 12:04 PM, Daniel P. Berrange wrote:
>
> > vm-a-disk1.qcow2 open - its just a regular backing file setup.
> >
> >>
> >>> | (format=qcow2, proto=file)
> >>> |
> >>> +- vm-a-disk1.qcow2
On Fri, Nov 03, 2017 at 02:00:46PM +0800, Fam Zheng wrote:
> On Thu, 11/02 12:02, Daniel P. Berrange wrote:
> > One alternative approach to doing this would be to suggest that we should
> > instead just spawn qemu-system-x86_64 with '--machine none' and use that
> > as a replacement for qemu-nbd,
On Thu, Nov 02, 2017 at 10:38:16PM +0100, Max Reitz wrote:
> On 2017-11-02 13:02, Daniel P. Berrange wrote:
> [...]
> > One alternative approach to doing this would be to suggest that we should
> > instead just spawn qemu-system-x86_64 with '--machine none' and use that
> > as a replacement for
On 2017-11-02 13:02, Daniel P. Berrange wrote:
[...]
> One alternative approach to doing this would be to suggest that we should
> instead just spawn qemu-system-x86_64 with '--machine none' and use that
> as a replacement for qemu-nbd, since it already has a built-in NBD server
> which can do
On 02/11/2017 13:02, Daniel P. Berrange wrote:
>
> After all that long background explanation, what I'm wondering is whether
> there is any interest / desire to extend qemu-nbd to have more advanced
> featureset than simply exporting a single disk image which must be listed
> at startup time.
>
On 11/02/2017 12:04 PM, Daniel P. Berrange wrote:
> vm-a-disk1.qcow2 open - its just a regular backing file setup.
>
>>
>>> | (format=qcow2, proto=file)
>>> |
>>> +- vm-a-disk1.qcow2 (qemu-system-XXX)
>>>
>>> The problem is that many VMs are wanting to use
On Thu, Nov 02, 2017 at 05:40:28PM +0100, Kashyap Chamarthy wrote:
> [Cc: Matt Booth from Nova upstream; so not snipping the email to retain
> context for Matt.]
>
> On Thu, Nov 02, 2017 at 12:02:23PM +, Daniel P. Berrange wrote:
> > I've been thinking about a potential design/impl
[Cc: Matt Booth from Nova upstream; so not snipping the email to retain
context for Matt.]
On Thu, Nov 02, 2017 at 12:02:23PM +, Daniel P. Berrange wrote:
> I've been thinking about a potential design/impl improvement for the way
> that OpenStack Nova handles disk images when booting virtual
11 matches
Mail list logo