Thanks! It's no rush from my point of view. Just happy to know it looks like the problem's been fixed. :)
________________________________________ From: Rafael Weingärtner <rafaelweingart...@gmail.com> Sent: Monday, April 18, 2016 11:41 AM To: dev@cloudstack.apache.org Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9 We found it last Saturday during the factoring of a test case! That was pure lucky. The code of the PR is not that good yet. But, we will work to get it ready to be reviewed and merged. On Mon, Apr 18, 2016 at 2:37 PM, Tutkowski, Mike <mike.tutkow...@netapp.com> wrote: > 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 > -- Rafael Weingärtner
