Re: [Xen-API] trouble with VDI relocation

[Germano Percossi <germano.percossi@xxxxxxxxxx>]

Hi Farkhad,

Happy you solved your problem.

However, it is just a brute force way of cleaning up
the sm-config for that specific vdi, a job that is supposed
to be done by resetvdis.py.

Your version of XenServer, whatever it is, is not up to date
because the logs I have seen can be produced only by obsolete
code.

With updated versions this problem is self repaired.
Apart from that, resetvdis.py is still supposed to clean
your configuration (even though automatically).

Forgetting the VDI is another viable method, as you
have noticed, but it is not an option for many people.

Cheers,
Germano

On 08/22/2016 09:55 AM, Farkhad Badalov wrote:
> Dear Germano,
> 
> I'm already solved the problem using method of change VDI uuid. Taking
> in account that it could be useful for other community members please
> note or place it on community wall.
> 
> 
> host# xe vdi-forget uuid=510523ef-5328-4130-ba0f-e3aa7264cae2
> host# xe sr-scan uuid=510523ef-5328-4130-ba0f-e3aa7264cae2
> The uuid you supplied was invalid.
> type: SR
> uuid: 510523ef-5328-4130-ba0f-e3aa7264cae2
> host# xe sr-scan uuid=60b09150-6ed3-f93a-eb59-64b355eddde3
> The uuid you supplied was invalid.
> type: SR
> uuid: 60b09150-6ed3-f93a-eb59-64b355eddde3
> host# xe sr-scan uuid=daca991b-8083-9d5c-f654-d87d43b84e4d
> host# xe vdi-param-set name-label=ns02smarthd
> uuid=510523ef-5328-4130-ba0f-e3aa7264cae2
> 
> After it VM was start without any problem. Special thanks for Xen
> specialist Dmitriy Rubashkin from Israel whose help has been invaluable.
> 
> Regards,
> 
> 2016-08-17 18:24 GMT+04:00 Germano Percossi <germano.percossi@xxxxxxxxxx
> <mailto:germano.percossi@xxxxxxxxxx>>:
> 
>     Hi Farkhad,
> 
>     I had a look at the logs you sent.
>     A bug report (xenserver-status-report) would have been more effective
>     but that's fine.
> 
>     It is not clear to me which version XenServer you are running (dunno
>     how XCP 1.6 maps to XenServer) but it seems the code producing the
>     following
> 
>     [14100] 2016-08-06 16:49:30.468365
>       File "/opt/xensource/sm/blktap2.py", line 1297, in _add_tag
>         raise util.SMException("VDI %s already attached RW" % vdi_uuid)
> 
>     is obsolete.
> 
>     Our latest versions are supposed to "self-heal". By latest, I mean
>     all the hotfixed or SP version of XenServer releases.
> 
>     The only way for that code to be triggered is if you don't have
>     a specific file (but it is fine not to have it) or if
>     util.is_attached_rw returns True.
> 
>     The latter is what is causing your problem, meaning that sm_config
>     of that specific VDI contains a reference to a host where this
>     VDI is (supposed) to be attached RW, already.
> 
>     I recommend the following:
>     - Check if you have all the hotfixes or service packs applied
>     - post the output of /etc/xensource-inventory (just to know exactly
>       which version are you running)
> 
>     Cheers,
>     Germano
> 
>     On 08/06/2016 01:14 PM, Farkhad Badalov wrote:
>     > Hello Germano,
>     >
>     > Sorry for delay, here is bunch of logs which you ask and I don't want to
>     > make bugreport.
>     > Just little note - trouble begins at August 2th after 11 30 am
>     >
>     > xnode101 - server which available now
>     > xnode102 - server which going switch off
>     >
>     > problematic vm name ns02smart
>     >
>     > Thank you for help.
>     >
>     > 2016-08-04 13:50 GMT+04:00 Germano Percossi 
> <germano.percossi@xxxxxxxxxx <mailto:germano.percossi@xxxxxxxxxx>
>     > <mailto:germano.percossi@xxxxxxxxxx
>     <mailto:germano.percossi@xxxxxxxxxx>>>:
>     >
>     >     Farkhad,
>     >
>     >     Would you mind sending a bunch of logs, starting with
>     /var/log/SMlog?
>     >
>     >     If you want to post a bugreport, instead, provide a link for
>     >     downloading it.
>     >
>     >     Cheers,
>     >     Germano
>     >
>     >
>     >     On 08/03/2016 02:39 PM, Farkhad Badalov wrote:
>     >
>     >         Dear community members,
>     >
>     >         We use XCP 1.6 on 2 servers wich joined in pool and iSCSI
>     shared
>     >         storage . Couple of days before we lost 2nd server in the
>     result of
>     >         power loss in datacenter. After it I try to relocate the VM
>     >         harddisks
>     >         but every time get this error "The VDI is not available"
>     >         In cli it gives little bit more info
>     >         Error code: SR_BACKEND_FAILURE_46
>     >         Error parameters: , The VDI is not available [opterr=VDI
>     >         510523ef-5328-4130-ba0f-e3aa7264cae2 already attached RW]
>     >
>     >         I've tried this manual
>     >         http://support.citrix.com/article/CTX132387
>     <http://support.citrix.com/article/CTX132387>
>     >         <http://support.citrix.com/article/CTX132387
>     <http://support.citrix.com/article/CTX132387>> with
>     >         vm powerstate reset and resetvdis script but unfortunately
>     even if I
>     >         moved VM in list of available for start it's still continue to
>     >         give such
>     >         kind error.
>     >
>     >         After it I remove troubled host from pool via this
>     >         manual
>     >       
>      http://discussions.citrix.com/topic/271368-remove-xenserver-from-pool/
>     <http://discussions.citrix.com/topic/271368-remove-xenserver-from-pool/>
>     >       
>      <http://discussions.citrix.com/topic/271368-remove-xenserver-from-pool/
>     <http://discussions.citrix.com/topic/271368-remove-xenserver-from-pool/>>
>     >         and use powerstate reset again with same result as above.
>     >
>     >         Since all VHD files placed on storage I'm absolutely sure that
>     >         this hdd
>     >         images are untoched, but I can't re-attach them on new host.
>     >
>     >         So could you recommend something for successful solving of
>     this
>     >         issue?
>     >
>     >         Regards,
>     >
>     >
>     >
>     >
>     >         _______________________________________________
>     >         Xen-api mailing list
>     >         Xen-api@xxxxxxxxxxxxx <mailto:Xen-api@xxxxxxxxxxxxx>
>     <mailto:Xen-api@xxxxxxxxxxxxx <mailto:Xen-api@xxxxxxxxxxxxx>>
>     >         https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
>     <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api>
>     >         <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
>     <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api>>
>     >
>     >
>     >     _______________________________________________
>     >     Xen-api mailing list
>     >     Xen-api@xxxxxxxxxxxxx <mailto:Xen-api@xxxxxxxxxxxxx>
>     <mailto:Xen-api@xxxxxxxxxxxxx <mailto:Xen-api@xxxxxxxxxxxxx>>
>     >     https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
>     <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api>
>     >     <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
>     <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api>>
>     >
>     >
> 
> 

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