Re: [Xen-API] Move blktap2.reset_leaf call to new SR command "epoch_begin"

[Rushikesh Jadhav <2rushikeshj@xxxxxxxxx>]

Hi Mike and Andrei,

Thanks for making the discussion open about this famous issue.

Many times we face this issue. If a host is hang then the VMs from that host are unable to boot on any other host until the database VDI RW flag is reset. Usual error is "The VDI is already attached in RW mode".  The solution procedure is to reboot the hang host or resetvdis manually.

If we can do on-boot=reset then this will help to quickly boot failed VMs on new host without errors. As mentioned this will apply to start and restart operation but will "xe vm-reset-powerstate" be affected ?

Regards,
Rushikesh

On Tue, Nov 27, 2012 at 5:45 PM, Andrei Lifchits <Andrei.Lifchits@xxxxxxxxxx> wrote:

Hi Mike,

Sounds good to me. Should be pretty easy to change.

Andrei

________________________________________
From: Mike McClurg
Sent: Monday, November 26, 2012 4:13 PM
To: xen-api@xxxxxxxxxxxxx; Andrei Lifchits
Subject: Move blktap2.reset_leaf call to new SR command "epoch_begin"

Hi Andrei,

(Note that I'm CC'ing the xen-api list to encourage more open
development discussions.)

I'm working on the VDI reset bug we talked about last week, where
setting on-boot=reset on a VDI, and then migrating the VM, triggers the
VDI reset after the migration is complete, because VDI reset is called
on VDI attach.

The fix for this should be to only call blktap2.reset_leaf when the VDI
attach operation is performed during a VM start or reboot. There is a
set of new SMAPIv2 calls in Xapi: begin_epoch, end_epoch, which are
called by Xapi when a VM is started and stopped (respectively), and also
during a VM reboot. These functions are not called during a VM migrate.

My proposal is that we add two new SR commands, begin_epoch and
end_epoch, and that we move the VDI reset code into begin_epoch. The two
corresponding Xapi functions would then call these SR commands.

Does this sound like a good solution to the migrate triggers VDI reset
bug? Did I miss anything here? Thanks,

Mike

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api