Hi Chandan, Chiradeep, Chip, Sheng and everyone,
Just wanted to share that systemvms using new appliance/image is working for me.
I'm dogfooding on DevCloud and they work for me. The only issue is
that for some reason the vhd exported from a raw disk image does not
work for now.
But one can use the VHD exported from VirtualBox, the name of the
archived artifact can be confusing:
http://jenkins.cloudstack.org/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvmtemplate-2013-02-28-master-hyperv.vhd.bz2
On docs and wiki vbox is said to export a VHD that is compatible with
HyperV, but I used the same on DevCloud and it worked for me. So,
using the above appliance works:
- Systemvms come up, get patched all agents run fine, there is a
latency issue, probably spring or some other issue
- RouterVM comes up, gets patched and I see networking rules being applied
- I was able to see console proxy via browser
- Was able to deploy a VM on 4.1 with following fix:
diff --git
a/engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrchestrator.java
b/engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrches
index 34673f2..cae25ac 100755
---
a/engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrchestrator.java
+++
b/engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrchestrator.java
@@ -170,7 +170,15 @@ public class CloudOrchestrator implements
OrchestrationService {
}
}
- VirtualMachineEntityImpl vmEntity =
ComponentContext.inject(VirtualMachineEntityImpl.class);
+ //VirtualMachineEntityImpl vmEntity =
ComponentContext.inject(VirtualMachineEntityImpl.class);
+ VirtualMachineEntityImpl vmEntity = null;
+ try {
+ vmEntity = VirtualMachineEntityImpl.class.newInstance();
+ vmEntity = ComponentContext.inject(vmEntity);
+
+ } catch (Exception e) {
+ // add error handling here
+ }
vmEntity.init(id, owner, hostName, displayName, cpu, speed,
memory, computeTags, rootDiskTags, new
ArrayList<String>(networkNicMap.keySet()));
Will start another thread, so it gets noticed.
Regards.
On Fri, Mar 1, 2013 at 2:43 AM, Chip Childers <chip.child...@sungard.com> wrote:
> On Thu, Feb 28, 2013 at 10:47:25AM -0800, Sheng Yang wrote:
>> On Wed, Feb 27, 2013 at 9:52 PM, Chiradeep Vittal
>> <chiradeep.vit...@citrix.com> wrote:
>> >
>> >
>> > On 2/27/13 10:12 AM, "Sheng Yang" <sh...@yasker.org> wrote:
>> >
>> >>Per this case, if people thinks systemvm template can be hosted alone,
>> >>I would suggest use the tested ipv6 template for the whole 4.1
>> >>release, to avoid confusion.
>> >
>> > As long as it is documented, it shouldn't cause too much confusion. People
>> > are not likely to be using ipv6 by accident, especially since it is
>> > considered experimental.
>> > I am sure your template is fine, but an abundance of caution at this stage
>> > of the game would lead me to believe that it is best to go with the
>> > 2-pronged approach. If we were making this decision 3 weeks ago, I'd say,
>> > 'yeah, probably OK'.
>>
>> I've sent out the notice when I branch out for IPv6, said it would
>> need a template. I stated so again when check in for 4.1 branch. And I
>> opened the bug for fixing this issue in 4.1. Thanks to Rohit, we
>> started discussion [3]. Everything looks fine.
>>
>> But this thing still happened. Bug changed to 4.1 fix version, the
>> issue raised by QA at last minute.
>>
>> I don't know how loud should I speak if we need a template for IPv6 in
>> 4.1. Seems nobody cares.
>> >
>> >>
>> >>Document the step to switch is fine, but two set of systemvm template
>> >>for one release would be tricky I think.
>> >
>> > Yes, but it is experimental.
>> >
>> >>
>> >>And the change to the ipv6 systemvm template, is it just contained
>> >>upgraded dnsmasq(version 6.22). That's it, nothing changed beside
>> >>that. I kind of believe it should be mostly the same as before, tested
>> >>enough for default template.
>> >
>> > These are not strong, confident statements. To make it simpler, we could
>> > use approach 'B' with the caveat that it does not run the apt-get unless
>> > some explicit action is taken by the cloud admin. For example:
>> > - a global flag (systemvm.ipv6.enable) or
>> > - whenever an ipv6 subnet is created.
>>
>> I don't think the thing would depends on if my statement is strong or
>> confident.
>>
>> I don't think we should let systemvm run apt-get things.
>>
>> According to what I observed in the community, I think probably it's
>> right that people not quite interested in ipv6.
>
> To be clear, I personally am *very* interested in getting IPv6 support.
> I think what we are talking about is the fact that this is experimental
> for 4.1 (as previously agreed).
>
>>
>> Probably we just revert the UI for 4.1 branch, and make API usable
>> with updated template.
>
> +1 to that approach.
>
> And another +1 to the implied implementation of IPv6, plus a new
> template, plus a new template build process, plus the UI, plus lots of
> testing... to make IPv6 support a full feature for 4.2.
>
>>
>> --Sheng
>>
>> [1] http://article.gmane.org/gmane.comp.apache.cloudstack.devel/10785
>> [2] http://article.gmane.org/gmane.comp.apache.cloudstack.devel/11387
>> [3]
>> http://thread.gmane.org/gmane.comp.apache.cloudstack.devel/12183/focus=15159
>> >
>> >>
>> >>VMware template may need some work, I remember last time we upgrade
>> >>the vmware template by installing some vmware tools, which didn't
>> >>affect other two templates(KVM and Xen). We would need to do it again,
>> >>Kelven should able to help with it.
>> >>
>> >>--Sheng
>> >>
>> >>On Wed, Feb 27, 2013 at 8:12 AM, Chip Childers
>> >><chip.child...@sungard.com> wrote:
>> >>> On Tue, Feb 26, 2013 at 10:23:04PM -0800, Chiradeep Vittal wrote:
>> >>>> Another work-around may be to not require new systemvms unless the ipv6
>> >>>> feature is required in which case:
>> >>>> A. We provide the bits of the systemvm of whatever Sheng's been testing
>> >>>> with (with the caveat that it is under development/beta)
>> >>>> B. Write a patch for cloud-early-config (or ssh in after VR is
>> >>>>created) to
>> >>>> apt-get update + apt-get install <ipv6 packages>
>> >>>
>> >>> I like option A. We had actually already agreed that IPv6 would be
>> >>> considered "experimental" in this release anyway. So if someone wants
>> >>> to try it out with 4.1, IMO it's OK to have them do a little more work
>> >>> to get the correct system VM.
>> >>>
>> >>> As long as we document it, I think that option A is the right one.
>> >>>
>> >>> Other thoughts?
>> >>>
>> >>>>
>> >>>> On 2/26/13 10:15 PM, "Rohit Yadav" <bhais...@apache.org> wrote:
>> >>>>
>> >>>> >On Wed, Feb 27, 2013 at 3:45 AM, Sheng Yang <sh...@yasker.org> wrote:
>> >>>> >> When I first report the bug
>> >>>> >> https://issues.apache.org/jira/browse/CLOUDSTACK-1066
>> >>>> >>
>> >>>> >> I've set the target for 4.1 because of ipv6 need.
>> >>>> >>
>> >>>> >> When Rohit fixed it, it was changed to 4.2, sorry I didn't aware of
>> >>>> >>that.
>> >>>> >
>> >>>> >Yes Sheng is correct, I was responsible for that because the
>> >>>> >feature/code to create systemvms was not even started and since I
>> >>>> >started working on it after the code freeze, I moved the version to
>> >>>> >4.2
>> >>>> >It was only recently when I found out that ipv6 is going to make it in
>> >>>> >4.1, in that case the feature is code complete [1] and we've an
>> >>>> >automated jenkins job. The only problems are:
>> >>>> >
>> >>>> >- Code syncing: I did not cherry-pick the code to 4.1
>> >>>> >- Testing: We need to test against 4.1 branch that the
>> >>>> >appliance/template really works [2]
>> >>>> >
>> >>>> >I'm sorry Sheng if ipv6 won't make in 4.1 because of this. But I would
>> >>>> >try my best to test/fix the template for Xen at least before 28/2, I
>> >>>> >really want to see your feature go in 4.1
>> >>>> >Since, 4.1 is frozen, community would have to make an exception to at
>> >>>> >least allow the new systemvms templates (if not the code) to be used
>> >>>> >in case it works fine for all three (kvm, xen and vmware) and we could
>> >>>> >still fix/test ahead of time, we still have few more weeks before the
>> >>>> >release; otherwise we can always use the same old template.
>> >>>> >
>> >>>> >Comments, suggestions, especially from Chip and ppmc?
>> >>>> >
>> >>>> >Regards.
>> >>>> >
>> >>>> >
>> >>>> >[1] https://issues.apache.org/jira/browse/CLOUDSTACK-1066
>> >>>> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-1340
>> >>>> >
>> >>>> >>
>> >>>> >> --Sheng
>> >>>> >>
>> >>>> >> On Tue, Feb 26, 2013 at 2:12 PM, Chip Childers
>> >>>> >> <chip.child...@sungard.com> wrote:
>> >>>> >>> On Tue, Feb 26, 2013 at 02:07:37PM -0800, Chandan Purushothama
>> >>>>wrote:
>> >>>> >>>> Building System VM Template is a 4.2 feature
>> >>>> >>>>https://issues.apache.org/jira/browse/CLOUDSTACK-1340. The system
>> >>>>VM
>> >>>> >>>>Templates posted by Rohit is for the Master branch
>> >>>>
>> >>>>>>>>http://jenkins.cloudstack.org/view/master/job/build-systemvm-master/
>> >>>>>>>>las
>> >>>> >>>>tSuccessfulBuild/artifact/tools/appliance/dist/ . I am referring to
>> >>>> >>>>the ASF 4.1 Release System VM Templates in my question.
>> >>>> >>>
>> >>>> >>> So in that case, I guess the only system VMs we have to use now
>> >>>>are the
>> >>>> >>> same ones we used for 4.0 (which were inherited from Citrix
>> >>>>pre-ASF).
>> >>>>
>> >>>>
>> >
>>
