Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9
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= Now you can delete the disk from xencenter Regards, Adrian Sender -- Original Message --- From: Anshul Gangwar To: "dev@cloudstack.apache.org" Sent: Fri, 15 Apr 2016 06:48:59 + 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 > > 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 > > 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 > > 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 > >> 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 ---
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 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= > > Now you can delete the disk from xencenter > > Regards, > Adrian Sender > > > > -- Original Message --- > From: Anshul Gangwar > To: "dev@cloudstack.apache.org" > Sent: Fri, 15 Apr 2016 06:48:59 + > 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 >>> 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 >>> 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 >>> 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 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 c
[GitHub] cloudstack pull request: CLOUDSTACK-9322: Support for Internal LB ...
Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1452#issuecomment-210849171 started the suite now but keep in mind that no sdn specific tests are done in it, @swill --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: Test fails in Widows as the file separato...
GitHub user GabrielBrascher opened a pull request:
https://github.com/apache/cloudstack/pull/1498
Test fails in Widows as the file separator "/" is different from "\"
**Problem:**
File separator in windows ("\") is different from the expected in the test
("/"); thus, the test *com.cloud.utils.SwiftUtilTest.testSplitSwiftPath()* will
fail in Windows systems.
The problem is that the input of the test is *"container/object"* but the
tested method uses the *File.separator* (that depends on from the OS), in the
windows the tested method (*com.cloud.utils.SwiftUtil.splitSwiftPath(String)*)
looks for a "\", as the string does not contain "\" it returns an empty string
and consequently results in a test failure.
**Solution:**
- Create a string `String input = "container" + File.separator + "object";`
(before it was `String input = "container/object";`); thus, independent of the
OS, the test will validate the tested method in a manner that the file
separator does not disturb the result;
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/GabrielBrascher/cloudstack lrg-cs-hackday-038
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/1498.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1498
commit a83514041cd865b06bee33d2440ea42b1e7c1337
Author: gabrascher
Date: 2016-04-16T18:35:17Z
Test fails in Widows as the file separator "/" is different from "\"
File separator in windows is different from linux (the expected in the
test); thus, the test
*com.cloud.utils.SwiftUtilTest.testSplitSwiftPath()* will fail in
windows. The problem is that the input of the test is
*"container/object"* but the tested method uses the *File.separator*
(that depends from the OS), in the windows the tested method
(*com.cloud.utils.SwiftUtil.splitSwiftPath(String)*) looks for a "\" in
windows systems, resulting in an empty string and consequently a failure
in the test.
Some solutions:
- the simple way is to create a string `String input = "container" +
File.separator + "object";`, thus independent of the OS, the test will
succeed.
- a tricky solution is to mock the final static variable
*File.separator* and return "/".
I picked the easy way.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
