Thanks, Adrian!

In my case, it's a dev environment, so it's not really hurting anything (it 
just seems like weird behavior, so I was curious if others were seeing it).

I can create a ticket in Jira and add your info and mine to it.

Thanks again!

> On Apr 16, 2016, at 4:43 AM, Adrian Sender <asen...@testlabs.com.au> wrote:
> 
> Hi Mike,
> 
> Hi have observed this behavior on CCP 4.3.x mostly and xenserver 6.5 less so
> in 4.5.1. I use Fiber Channel LVMoHBA as the primary storage.
> 
> Seems like the same issue.
> 
> Disk Attached to Dom0 after snapshot or copy from secondary to primary:
> 
> In this example we have a disk attached to dom0, we cannot delete the disk
> until we detach it.
> 
> admin.rc.precise 0 Created by template provisioner 42 GB   Control domain on
> host cpms1-1.nsp.testlabs.com.au
> 
> [root@cpms1-1 ~]# xe vdi-list name-label="admin.rc.precise 0"
> 
> uuid ( RO)                : 3d79722b-294d-4358-bc57-af92b9e9dda7
>         name-label ( RW): admin.rc.precise 0
>   name-description ( RW): Created by template provisioner
>            sr-uuid ( RO): dce1ec02-cce0-347d-0679-f39c9ea64da1
>       virtual-size ( RO): 45097156608
>           sharable ( RO): false
>          read-only ( RO): false
> 
> You will want to list out the VBD (connector object between VM and VDI) based
> on the VDI UUID. Here is an example:
> 
> [root@cpms1-1 ~]# xe vbd-list vdi-uuid=3d79722b-294d-4358-bc57-af92b9e9dda7
> 
> uuid ( RO)             : d9e2d89e-a82f-9e6e-c97a-afe0af47468e
>         vm-uuid ( RO): 0f4cb186-0167-47d6-afb5-89b00102250b
>   vm-name-label ( RO): Control domain on host: cpms1-1.nsp.nectar.org.au
>        vdi-uuid ( RO): 3d79722b-294d-4358-bc57-af92b9e9dda7
>           empty ( RO): false
>          device ( RO):
> 
> 
> Once done, you want to first try to make VBD inactive (it may already be
> inactive), "The device is not currently attached"
> 
> xe vbd-unplug uuid=d9e2d89e-a82f-9e6e-c97a-afe0af47468e
> 
> Once done, you can then break the connection:
> 
> xe vbd-destroy uuid=<UUID of VBD>
> 
> Now you can delete the disk from xencenter
> 
> Regards,
> Adrian Sender
> 
> 
> 
> ---------- Original Message -----------
> From: Anshul Gangwar <anshul.gang...@accelerite.com>
> To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
> Sent: Fri, 15 Apr 2016 06:48:59 +0000
> Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic
> Zone on 4.9
> 
>> Mike, what type of storage are you using?
>> 
>>> On 15-Apr-2016, at 9:49 AM, Tutkowski, Mike <mike.tutkow...@netapp.com> 
>>> wrote:
>>> 
>>> I'm not sure, Daan.
>>> 
>>> I plan to keep an eye on this behavior for a while when creating new clouds.
>>> 
>>> ________________________________________
>>> From: Daan Hoogland <daan.hoogl...@gmail.com>
>>> Sent: Thursday, April 14, 2016 2:12 AM
>>> To: dev
>>> Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> Basic Zone on 4.9
>>> 
>>> Mike, did the iso copy process not complete as expected. Sound like they
>>> are a remanence of some task ending in an exception. Probably a silently
>>> ignored one ;|
>>> 
>>> On Thu, Apr 14, 2016 at 2:49 AM, Tutkowski, Mike <mike.tutkow...@netapp.com>
>>> wrote:
>>> 
>>>> Just an FYI, but when I kicked off my first VM in this cloud, the VR
>>>> happened to get deployed to XenServer-6.5-3 (which was one of my XenServer
>>>> hosts that had an un-expected shared SR pointing at secondary storage
>>>> beforehand).
>>>> 
>>>> Once the process of copying the system template down to local storage
>>>> completed, the shared SR pointing at secondary storage went away (as you
>>>> would expect).
>>>> 
>>>> This leaves me now with one un-expected shared SR pointing at secondary
>>>> storage on XenServer-6.5-1.
>>>> 
>>>> ________________________________________
>>>> From: Tutkowski, Mike <mike.tutkow...@netapp.com>
>>>> Sent: Wednesday, April 13, 2016 5:10 PM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: Strange XenServer SR behavior when deploying system VMs in Basic
>>>> Zone on 4.9
>>>> 
>>>> Hi,
>>>> 
>>>> 
>>>> Has anyone recently observed the following behavior:
>>>> 
>>>> 
>>>> http://imgur.com/8ALJmWb
>>>> 
>>>> 
>>>> As you can see in the image, I have three 6.5 XenServer hosts in a
>>>> resource pool.
>>>> 
>>>> 
>>>> I just used them when creating a basic zone and the system VMs were
>>>> deployed just fine. However, there are SRs pointing to secondary storage on
>>>> my XenServer-6.5-1 and XenServer-6.5-3 hosts still (there used to be one on
>>>> my XenServer-6.5-2 host, but it went away once the system VMs started up on
>>>> that host).
>>>> 
>>>> 
>>>> Thoughts?
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Mike
>>> 
>>> 
>>> 
>>> --
>>> Daan
>> 
>> DISCLAIMER
>> ==========
>> This e-mail may contain privileged and confidential information 
>> which is the property of Accelerite, a Persistent Systems business. 
>> It is intended only for the use of the individual or entity to which 
>> it is addressed. If you are not the intended recipient, you are not 
>> authorized to read, retain, copy, print, distribute or use this 
>> message. If you have received this communication in error, please 
>> notify the sender and delete all copies of this message. Accelerite, 
>> a Persistent Systems business does not accept any liability for 
>> virus infected mails.
> ------- End of Original Message -------
> 

Reply via email to