Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy

[Avi Kivity]

On 03/01/2011 05:51 PM, Anthony Liguori wrote:
> > > Do a hot unplug of a network device with upstream libvirt with 
> > > acpiphp unloaded, consult libvirt and then consult the monitor to 
> > > see who has the right view of the guests config.
> >
> > libvirt is right and the monitor is wrong.
> >
> > On real hardware, calling _EJ0 doesn't affect the configuration one 
> > little bit (if I understand it correctly).  It just turns off power 
> > to the slot.  If you power-cycle, the card will be there.
>
> It's up to the hardware vendor.  Since it's ACPI, it can result in any 
> number of operations.  Usually, there's some logic to flip on an LED 
> or something.
>
> There's nothing that prevents a vendor from ejecting the card.  My 
> point is that there aren't cleanly separated lines in the real world.

We can implement out virtual hardware like real hardware, or we can do 
some new stuff, and break our management model in the process.

> > >
> >
> > Unless I'm hallucinating, you're suggesting quite a bit more.  A 
> > revolution in how qemu is to be managed.
>
> Let me take another route to see if I can't persuade you.
>
> First, let's clarify your proposal.  You want to introduce a new block 
> format
> that references to block devices.  It may also store a dirty bitmap to 
> keep
> track of which blocks are out of sync.  Hopefully, it goes without saying
> that the dirty bitmap is strictly optional (it's a performance 
> optimization) so
> let's ignore it.

(as was related elsewhere, the state is also optional)

> Your format, as a text file, looks like:
>
> [raid1]
> primary=diska.img
> secondary=diskb.img
> active=primary
>
> To use it, here's the sequence:
>
> 0) qemu uses disk A for a block device
>
> 1) create a raid1 block device pointing to disk A and disk B.
>
> 2) management tool asks qemu to us the new raid1 block device.
>
> 3) qemu acks (2)
>
> 4) at some point, the mirror completes, writes are going to both disks
>
> 5) qemu sends out an event indicating that the disks are in sync
>
> 6) management tool then sends a command to fail over to disk B
>
> 7) qemu acks (6)
>
> We're making the management tool the "authoritative" source of how to 
> launch
> QEMU.  That means that the management tool ultimately determines which 
> command
> line to relaunch QEMU with.
>
> Here are the races:
>
> A) If QEMU crashes between (2) and (3), it may have issues a write to 
> the new
>    raid1 block device before the management tool sees (3).  If this 
> happens,
>    when the management tool restarts QEMU with disk A, we're left with a
>    dangling raid1 block device.  Not a critical failure, but not ideal.

You can restart qemu with the RAID1 blockdev.

> B) If QEMU crashes between (6) and (7), QEMU may have started writing 
> to disk
>    B before the management tool sees (7).  This means that the 
> management tool
>    will create the guest with the raid1 block device which no longer 
> is the
>    correct disk.  This could fail in subtly bad ways.  Depending on 
> how read
>    is implemented (if you try to do striping for instance), bad data 
> could be
>    returned.  You could try to implement a policy of always reading 
> from B if
>    the block has been copied but this gets harry really quickly.  It's
>    definitely not RAID1 anymore.

As related elsewhere, you restart qemu with image B.

The trick is to partition the problem into idempotent commands; these 
allow you to recover from any failure.

> You may observe that the problem is not the RAID1 mechanism, but 
> changing from
> using a normal device and the RAID1 mechanism.  It would then be wise 
> to say,
> let's always use this image format.  Since that eliminates the race, 
> we don't
> really need the copy bitmap anymore.
>
> Now we're left with a simple format that just refers to two 
> filenames.  However,
> block devices are more than just a filename.  It needs a format, cache
> settings, etc.  So let's put this all in the RAID1 block format.  We 
> also need
> a way to indicate which block device is selected.
>
> Let's make it a text file for purposes of discussion.  It will look 
> something
> like:
>
> [primary]
> filename=diska.img
> cache=none
> format=raw
>
> [secondary]
> filename=diskb.img
> cache=writethrough
> format=qcow2
>
> [global]
> active=primary
>
> Since we might want to mirror multiple drives at once, we should 
> probablyn
> support having multiple drives configured which means we need to not 
> just have
> a single active entry, but an entry associated with a particular device.

Or you have one file per RAID-1 image set.  This is important because 
images are not associated with a qemu instance.  You can hot-unplug an 
image from one qemu and hot-plug it into another.

> [drive "diskA"]
> filename=diska.img
> cache=none
> format=raw
>
> [drive "diskB"]
> filename=diskb.img
> cache=writethrough
> format=qcow2
>
> [device "vda"]
> drive=diskB
>
> And this is exactly what I'm proposing. 

It's exactly what I'm opposing.  Making qemu manage all this stuff.

> It's really the natural generalization
> of what you're proposing.
>
> So basically, the only differences are:
>
>  1) always use the new RAID1 format
>  2) drop the progress bitmap
>  3) support multiple devices per file
>  4) let drive properties be specified beyond filename
>
> All reasonable things to do.

Well, I dislike 3, and the whole "qemu is authoritative source of 
configuration" thing.

--
error compiling committee.c: too many arguments to function