----- Original Message ----- > From: "Kevin Wolf" <kw...@redhat.com> > To: "Federico Simoncelli" <fsimo...@redhat.com> > Cc: "Eric Blake" <ebl...@redhat.com>, qemu-devel@nongnu.org, > stefa...@linux.vnet.ibm.com, lcapitul...@redhat.com, > "Paolo Bonzini" <pbonz...@redhat.com>, "Markus Armbruster" <arm...@redhat.com> > Sent: Wednesday, March 14, 2012 10:34:08 AM > Subject: Re: [Qemu-devel] [PATCH v4 10/10] Add the drive-reopen command > > > * We could leave it as it is, a distinct command that is not part > > of > > the transaction and that it's closing the old image before > > opening > > the new one. > > Yes, this would be the short-term preliminary solution. I would tend > to > leave it to downstreams to implement it as an extension, though. > > > This is not completely correct, the main intent was to not spread > > one image chain across two storage domains (making it incomplete if one > > of them was missing). In the next oVirt release a VM can have > > different disks on different storage domains, so this wouldn't be a special > > case but just a normal situation. > > The problem with this kind of argument is that we're not developing > only for oVirt, but need to look for what makes sense for any management > tool (or even just direct users of qemu).
That is a general rule, and it's perfectly agreeable, but it has nothing to do with what I was saying. Do you know any management tool or any reason to forbid to a VM to have different disks on different storages? In fact qemu-kvm doesn't even know where the images are coming from (what particular iscsi connection or what particular NFS server). What I was asking was a tool (mirroring) to avoid the split of an image chain between multiple storages, and not a tool to avoid the ability to have full image chains on different storages. There is nothing oVirt specific here, it came into play only when I said that for us is not a problem (for once :-). -- Federico
