Thanks, Rafael! That very much looks like it could solve the problem. I've subscribed to the PR for notifications. Once I see it's in the codebase, I can re-build my dev environment and see if I still have the issue. ________________________________________ From: Rafael Weingärtner <rafaelweingart...@gmail.com> Sent: Monday, April 18, 2016 8:07 AM To: dev@cloudstack.apache.org Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9
Would the problem discussed here relate to the one here https://github.com/apache/cloudstack/pull/1499? On Mon, Apr 18, 2016 at 11:04 AM, Tutkowski, Mike <mike.tutkow...@netapp.com > wrote: > 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 ------- > > > -- Rafael Weingärtner
