Le Tuesday 29 Jan 2013 à 14:25:42 (+0100), Kevin Wolf a écrit : > Am 29.01.2013 14:07, schrieb Benoît Canet: > >> Wait, what's happening here? I don't understand this patch and how it's > >> related to snapshotting non-file protocols (if this is even what you > >> mean). What is your exact scenario, what does the existing code do in > >> it, and how does this change improve it? An empty commit message is > >> definitely not appropriate for such a change. > >> > >> In any case, using NULL as drv for bdrv_open() looks plain wrong. > > > > When passing drv bdrv_open tries to open the url as qcow2 or another plain > > file > > format and fail. > > What exactly is a "plain file format" and what is the difference between > it and other file formats?
Quorum is a protocol which encapsulate n BlockDriverState. > > Anyway, this is not a problem description, let alone a description of > your exact scenario. A scenario would be: A user want to create a new quorum snapshot made of n qcow2 snapshots. The user specify qcow2 as format so the new quorum files are created as qcow2. Then the code try to open the quorum file as a qcow2 file and it fail. > > If qcow2 is specified as the format in the QMP command, why is it then > wrong to try and open the file as qcow2? Why does it fail? What is the > correct driver? It's correct to format the individual quorum files as qcow2 so specifying qcow2 in the qmp command seems ok. But opening a "quorum:" url which agregate these qcow2 files will fail if drv is the qcow2 driver. Would passing the quorum protocol driver to bdrv_open be ok ? Benoît > > > bdrv_file_open is not a better option because it won't return a > > BlockDriverState > > constructed in the same way as the old one. > > (raw as bs and quorum as ->file) > > > > I agree that this patch is a hack and I am looking for a better way of > > doing it. > > Let's talk about the problem first before discussing solutions. > > Kevin
