Looks like I already opened a ticket on this in January. :) https://issues.apache.org/jira/browse/CLOUDSTACK-9224
I added info to it. ________________________________________ From: Tutkowski, Mike <mike.tutkow...@netapp.com> Sent: Saturday, April 16, 2016 9:58 AM To: dev@cloudstack.apache.org Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9 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 ------- >