Re: Using newer DIY SystemVMs
On 07.03.2013 23:09, Chip Childers wrote: On Thu, Mar 07, 2013 at 01:07:26PM -0700, Marcus Sorensen wrote: Ok, didn't realize we were going to point people to this particular system vm for production installs, I thought this was just a proof-of-concept for building custom ones. The intent was to be able to actually reproduce our system VMs programatically, which also happens to open up other opportunities! Hi, There is a need to create a customized system VM at our data-center for using CloudStack to provide HPC. Thanks for this link. If there are any other links helpful for such task I appreciate very much. #Serge
Re: Using newer DIY SystemVMs
Hi Serge,
We've a wiki (Pl. feel free to edit the wiki in case you think
anything is missing or let us know if you have any questions):
https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+on+master+branch
Blog on build automation of appliance using veewee+vbox using jenkins:
http://rohityadav.in/logs/building-systemvms/
Note that they are tested and full proof but we're working on them for
4.2.0 release, so if you end up changing the default distro (Debian)
for the systemvm template, you will have to rework all the patch
scripts in patches/systemvm/debian; but we would love to see people
fork them out to create systemvms based on fedora, arch linux etc. so
we can someday have patches/systemvm/{fedora,arch,gentoo} etc :)
Hope this helps.
On Thu, Mar 14, 2013 at 1:50 PM, Serge A. Salamanka salsa-...@tut.by wrote:
On 07.03.2013 23:09, Chip Childers wrote:
On Thu, Mar 07, 2013 at 01:07:26PM -0700, Marcus Sorensen wrote:
Ok, didn't realize we were going to point people to this particular
system vm for production installs, I thought this was just a
proof-of-concept for building custom ones.
The intent was to be able to actually reproduce our system VMs
programatically, which also happens to open up other opportunities!
Hi,
There is a need to create a customized system VM at our data-center for
using CloudStack to provide HPC.
Thanks for this link. If there are any other links helpful for such task
I appreciate very much.
#Serge
Re: Using newer DIY SystemVMs
Serge, oops wrong wiki, this one:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Build+Your+Own+SystemVM+Templates
On Thu, Mar 14, 2013 at 2:24 PM, Rohit Yadav bhais...@apache.org wrote:
Hi Serge,
We've a wiki (Pl. feel free to edit the wiki in case you think
anything is missing or let us know if you have any questions):
https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+on+master+branch
Blog on build automation of appliance using veewee+vbox using jenkins:
http://rohityadav.in/logs/building-systemvms/
Note that they are tested and full proof but we're working on them for
4.2.0 release, so if you end up changing the default distro (Debian)
for the systemvm template, you will have to rework all the patch
scripts in patches/systemvm/debian; but we would love to see people
fork them out to create systemvms based on fedora, arch linux etc. so
we can someday have patches/systemvm/{fedora,arch,gentoo} etc :)
Hope this helps.
On Thu, Mar 14, 2013 at 1:50 PM, Serge A. Salamanka salsa-...@tut.by wrote:
On 07.03.2013 23:09, Chip Childers wrote:
On Thu, Mar 07, 2013 at 01:07:26PM -0700, Marcus Sorensen wrote:
Ok, didn't realize we were going to point people to this particular
system vm for production installs, I thought this was just a
proof-of-concept for building custom ones.
The intent was to be able to actually reproduce our system VMs
programatically, which also happens to open up other opportunities!
Hi,
There is a need to create a customized system VM at our data-center for
using CloudStack to provide HPC.
Thanks for this link. If there are any other links helpful for such task
I appreciate very much.
#Serge
Re: Using newer DIY SystemVMs
Thank you, Rohit
That is enough to start with.
I'll write back on the progress.
#Serge
On 14.03.2013 11:55, Rohit Yadav wrote:
Serge, oops wrong wiki, this one:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Build+Your+Own+SystemVM+Templates
On Thu, Mar 14, 2013 at 2:24 PM, Rohit Yadav bhais...@apache.org wrote:
Hi Serge,
We've a wiki (Pl. feel free to edit the wiki in case you think
anything is missing or let us know if you have any questions):
https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+on+master+branch
Blog on build automation of appliance using veewee+vbox using jenkins:
http://rohityadav.in/logs/building-systemvms/
Note that they are tested and full proof but we're working on them for
4.2.0 release, so if you end up changing the default distro (Debian)
for the systemvm template, you will have to rework all the patch
scripts in patches/systemvm/debian; but we would love to see people
fork them out to create systemvms based on fedora, arch linux etc. so
we can someday have patches/systemvm/{fedora,arch,gentoo} etc :)
Hope this helps.
On Thu, Mar 14, 2013 at 1:50 PM, Serge A. Salamanka salsa-...@tut.by wrote:
On 07.03.2013 23:09, Chip Childers wrote:
On Thu, Mar 07, 2013 at 01:07:26PM -0700, Marcus Sorensen wrote:
Ok, didn't realize we were going to point people to this particular
system vm for production installs, I thought this was just a
proof-of-concept for building custom ones.
The intent was to be able to actually reproduce our system VMs
programatically, which also happens to open up other opportunities!
Hi,
There is a need to create a customized system VM at our data-center for
using CloudStack to provide HPC.
Thanks for this link. If there are any other links helpful for such task
I appreciate very much.
#Serge
Re: Using newer DIY SystemVMs
Console doesn't seem to work. I'm seeing this in the console proxy logs: java.lang.IllegalArgumentException at com.cloud.consoleproxy.ConsoleProxyAjaxHandler.doHandle(ConsoleProxyAjaxHandler.java:90) at com.cloud.consoleproxy.ConsoleProxyAjaxHandler.handle(ConsoleProxyAjaxHandler.java:47) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83) at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:86) at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:589) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83) at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:559) at java.lang.Thread.run(Thread.java:679) It seems to indicate that some variables aren't passed, host, port, or something. I look at what the web browser has, which is just a token: src=https://192-168-100-102.realhostip.com/ajax?token=QK77ahi6j153CNKzT9rI126RkY7YUNUu2wx2Ef1W0n5v1R1oZ_J5ViFVIjDqW1UJP261VJ76dS0pMX0P80kRcZFhJ5mNqG7CNK2UvXt_D68a9eIzNlwhkZRcEDWQEVliunIQliMJlCZkp1ka7kGOC807K-xFVPKCf-ZKPFxLL45sTPLJr6bXBpDKiajYVbQA6v8Xf5lx3Wr0bWMcqy5i3Cxjg_zp4f6Y_7D-BVLFE4nKiWH3_gADsJ8BVGfvlBI27rrXt0JFf_U; I'm not sure how these fit together, I'm assuming that something is supposed to be triggered on the console proxy VM to register that token and associate it with some settings, but I see nothing on the KVM Agent setting this up. I only see a 'GetVncPortCommand' command. On Mon, Mar 11, 2013 at 11:21 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: This procedure already exists somewhere. System VM upgrades aren't new to CS. Let me see if I can dig it up. http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.1-i ncubating/html/Release_Notes/upgrade-instructions.html
Re: Using newer DIY SystemVMs
On Tue, Mar 12, 2013 at 01:15:45PM -0600, Marcus Sorensen wrote: Console doesn't seem to work. I'm seeing this in the console proxy logs: java.lang.IllegalArgumentException at com.cloud.consoleproxy.ConsoleProxyAjaxHandler.doHandle(ConsoleProxyAjaxHandler.java:90) at com.cloud.consoleproxy.ConsoleProxyAjaxHandler.handle(ConsoleProxyAjaxHandler.java:47) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83) at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:86) at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:589) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83) at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:559) at java.lang.Thread.run(Thread.java:679) It seems to indicate that some variables aren't passed, host, port, or something. I look at what the web browser has, which is just a token: src=https://192-168-100-102.realhostip.com/ajax?token=QK77ahi6j153CNKzT9rI126RkY7YUNUu2wx2Ef1W0n5v1R1oZ_J5ViFVIjDqW1UJP261VJ76dS0pMX0P80kRcZFhJ5mNqG7CNK2UvXt_D68a9eIzNlwhkZRcEDWQEVliunIQliMJlCZkp1ka7kGOC807K-xFVPKCf-ZKPFxLL45sTPLJr6bXBpDKiajYVbQA6v8Xf5lx3Wr0bWMcqy5i3Cxjg_zp4f6Y_7D-BVLFE4nKiWH3_gADsJ8BVGfvlBI27rrXt0JFf_U; I'm not sure how these fit together, I'm assuming that something is supposed to be triggered on the console proxy VM to register that token and associate it with some settings, but I see nothing on the KVM Agent setting this up. I only see a 'GetVncPortCommand' command. Just to confirm - you are testing the new system VM images from the master branch? On Mon, Mar 11, 2013 at 11:21 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: This procedure already exists somewhere. System VM upgrades aren't new to CS. Let me see if I can dig it up. http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.1-i ncubating/html/Release_Notes/upgrade-instructions.html
Re: Using newer DIY SystemVMs
I'm testing the ones Rohit links to in this email thread, the ones Jenkins builds. On Tue, Mar 12, 2013 at 1:18 PM, Chip Childers chip.child...@sungard.com wrote: On Tue, Mar 12, 2013 at 01:15:45PM -0600, Marcus Sorensen wrote: Console doesn't seem to work. I'm seeing this in the console proxy logs: java.lang.IllegalArgumentException at com.cloud.consoleproxy.ConsoleProxyAjaxHandler.doHandle(ConsoleProxyAjaxHandler.java:90) at com.cloud.consoleproxy.ConsoleProxyAjaxHandler.handle(ConsoleProxyAjaxHandler.java:47) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83) at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:86) at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:589) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83) at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:559) at java.lang.Thread.run(Thread.java:679) It seems to indicate that some variables aren't passed, host, port, or something. I look at what the web browser has, which is just a token: src=https://192-168-100-102.realhostip.com/ajax?token=QK77ahi6j153CNKzT9rI126RkY7YUNUu2wx2Ef1W0n5v1R1oZ_J5ViFVIjDqW1UJP261VJ76dS0pMX0P80kRcZFhJ5mNqG7CNK2UvXt_D68a9eIzNlwhkZRcEDWQEVliunIQliMJlCZkp1ka7kGOC807K-xFVPKCf-ZKPFxLL45sTPLJr6bXBpDKiajYVbQA6v8Xf5lx3Wr0bWMcqy5i3Cxjg_zp4f6Y_7D-BVLFE4nKiWH3_gADsJ8BVGfvlBI27rrXt0JFf_U; I'm not sure how these fit together, I'm assuming that something is supposed to be triggered on the console proxy VM to register that token and associate it with some settings, but I see nothing on the KVM Agent setting this up. I only see a 'GetVncPortCommand' command. Just to confirm - you are testing the new system VM images from the master branch? I'm testing the ones Rohit links to in this email thread, the ones Jenkins builds. On Mon, Mar 11, 2013 at 11:21 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: This procedure already exists somewhere. System VM upgrades aren't new to CS. Let me see if I can dig it up. http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.1-i ncubating/html/Release_Notes/upgrade-instructions.html
Re: Using newer DIY SystemVMs
On Tue, Mar 12, 2013 at 01:19:24PM -0600, Marcus Sorensen wrote: I'm testing the ones Rohit links to in this email thread, the ones Jenkins builds. Ack - thanks.
Re: Using newer DIY SystemVMs
Was AFK this weekend, thanks Chip for replying :) On Fri, Mar 8, 2013 at 10:50 PM, Chip Childers chip.child...@sungard.com wrote: On Thu, Mar 07, 2013 at 08:55:19PM -0700, Marcus Sorensen wrote: Just for confirmation, we are going to require a new system VM in 4.2 (or 5.0?), right? I believe that's the best thing to do, yes. +1 Yes, the systemvm templates should be completely backward compatible with the old one, this was the first aim. Next, it allows people to customize their own, like add a package that we want for some featureX. What about upgrading, is there a facility for updating the system VM template? I know there's the global setting that rebuilds the system VMS on every reboot... I think that we need to document that process. It will at least involve a DB change (which we should probably put into the upgrade scripts). +1, I'll try to finish this by today: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Build+Your+Own+SystemVM+Templates And we will come up with upgrading/updating discussions. I'm trying to make the new template backward compatible so we don't need to change any scripts, systemvms are stateless so the upgrade process would be easier just to kill/remove ol' systemvms. Then I assume that the user would need to destroy any existing system VMs, perhaps including the VRs. Also - we need a place to host the new system VMs. One can build their own systemvms or get from jenkins: 32bit: http://jenkins.cloudstack.org/job/build-systemvm-master 64bit: http://jenkins.cloudstack.org/job/build-systemvm64-master (yes, we've 64 bit systemvms now as well, needs testing though :) Regards. Does Citrix (someone that can represent Citrix) want to continue to donate that download location? Or do we want to circle back to infra@ (referencing the old agreement from legal-discuss@) to ask for a place? No idea.
Re: Using newer DIY SystemVMs
On 3/8/13 9:20 AM, Chip Childers chip.child...@sungard.com wrote: On Thu, Mar 07, 2013 at 08:55:19PM -0700, Marcus Sorensen wrote: Just for confirmation, we are going to require a new system VM in 4.2 (or 5.0?), right? I believe that's the best thing to do, yes. What about upgrading, is there a facility for updating the system VM template? I know there's the global setting that rebuilds the system VMS on every reboot... I think that we need to document that process. It will at least involve a DB change (which we should probably put into the upgrade scripts). Then I assume that the user would need to destroy any existing system VMs, perhaps including the VRs. This procedure already exists somewhere. System VM upgrades aren't new to CS. Let me see if I can dig it up. Also - we need a place to host the new system VMs. Does Citrix (someone that can represent Citrix) want to continue to donate that download location? Or do we want to circle back to infra@ (referencing the old agreement from legal-discuss@) to ask for a place? Right now they are on jenkins..
Re: Using newer DIY SystemVMs
This procedure already exists somewhere. System VM upgrades aren't new to CS. Let me see if I can dig it up. http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.1-i ncubating/html/Release_Notes/upgrade-instructions.html
Re: Using newer DIY SystemVMs
On Thu, Mar 07, 2013 at 08:55:19PM -0700, Marcus Sorensen wrote: Just for confirmation, we are going to require a new system VM in 4.2 (or 5.0?), right? I believe that's the best thing to do, yes. What about upgrading, is there a facility for updating the system VM template? I know there's the global setting that rebuilds the system VMS on every reboot... I think that we need to document that process. It will at least involve a DB change (which we should probably put into the upgrade scripts). Then I assume that the user would need to destroy any existing system VMs, perhaps including the VRs. Also - we need a place to host the new system VMs. Does Citrix (someone that can represent Citrix) want to continue to donate that download location? Or do we want to circle back to infra@ (referencing the old agreement from legal-discuss@) to ask for a place?
Re: Using newer DIY SystemVMs
Hmm. I think I was deceived by the /etc/init directory existing. I'm
not sure why it's there, but I don't think the template is using
upstart. I'm having a hard time reliably recreating the issue, but I
think it's related to other reports where the default gateway is
missing (I've seen this myself on a secondary storage VM, but it went
away when I rebooted it, and couldn't get the problem to come back).
This happens unrelated to any changes I'm making.
On Wed, Mar 6, 2013 at 3:54 PM, Marcus Sorensen shadow...@gmail.com wrote:
After reading a little more about upstart, I don't think this script
does anything. I'm not entirely sure at the moment however how best to
ensure that networking starts after cloud-early-config, short of
converting cloud-early-config to an upstart script. It looks like this
debian build is using upstart just for networking, and everything else
uses the standard sysvinit ordering.
On Wed, Mar 6, 2013 at 2:49 PM, Marcus Sorensen shadow...@gmail.com wrote:
Just to be clear, that script may have no effect whatsoever, and I'm
not sure how to verify other than rebooting a bunch of times. I don't
have the time to do that at the moment.
On Wed, Mar 6, 2013 at 2:48 PM, Marcus Sorensen shadow...@gmail.com wrote:
There may be one other minor thing that needs to be addressed. In
getting rid of the patchdisk, my networking on the router is a bit
inconsistent. It looks like maybe networking is starting before
cloud-early-config completes, as /etc/network/interfaces looks right,
but I don't always get an ip on eth0.
I know next to nothing about upstart, and haven't had a chance to test
much, so if someone else can help that would be great. I've tried this
though and it worked the two times I rebooted, after 70% failures on
reboot. It goes it /etc/init/cloud-early-config-wait.conf
- script start here
#cloud-early-config-wait
start on (starting networking or starting network-interface)
instance $JOB
script
start cloud-early-config || true
# Waiting forever is ok.. upstart will kill this job when
# the service we tried to start above either starts or stops
while sleep 3600 ; do :; done
end script
script end here---
On Wed, Mar 6, 2013 at 9:10 AM, Marcus Sorensen shadow...@gmail.com wrote:
On Wed, Mar 6, 2013 at 2:09 AM, Rohit Yadav bhais...@apache.org wrote:
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
I think the systemvm.iso is a completely fine way of getting new code
onto the system vms. My main goal at this point was to just get rid of
the patch disk portion. Also, since it sounds like we're wanting to
move to a link-local API to control the system vms I think we'll
forego qemu-guest-agent or putting our own daemon on the virtio serial
device and simply use it to copy the cmdline/authorized keys.
If this updated system vm checks out, I'll update the devcloud-kvm
packages with it preinstalled, replacing the older one. Or in the
meantime what I've been doing is simply downloading yours and moving
it into place over the existing one, giving it the same name, before
deploying anything.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com
wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com
wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com
Re: Using newer DIY SystemVMs
I see the qcow2 is now compressed, thanks. You can probably skip
putting it in a bz2 now, it's about the same size.
On Thu, Mar 7, 2013 at 10:58 AM, Marcus Sorensen shadow...@gmail.com wrote:
Hmm. I think I was deceived by the /etc/init directory existing. I'm
not sure why it's there, but I don't think the template is using
upstart. I'm having a hard time reliably recreating the issue, but I
think it's related to other reports where the default gateway is
missing (I've seen this myself on a secondary storage VM, but it went
away when I rebooted it, and couldn't get the problem to come back).
This happens unrelated to any changes I'm making.
On Wed, Mar 6, 2013 at 3:54 PM, Marcus Sorensen shadow...@gmail.com wrote:
After reading a little more about upstart, I don't think this script
does anything. I'm not entirely sure at the moment however how best to
ensure that networking starts after cloud-early-config, short of
converting cloud-early-config to an upstart script. It looks like this
debian build is using upstart just for networking, and everything else
uses the standard sysvinit ordering.
On Wed, Mar 6, 2013 at 2:49 PM, Marcus Sorensen shadow...@gmail.com wrote:
Just to be clear, that script may have no effect whatsoever, and I'm
not sure how to verify other than rebooting a bunch of times. I don't
have the time to do that at the moment.
On Wed, Mar 6, 2013 at 2:48 PM, Marcus Sorensen shadow...@gmail.com wrote:
There may be one other minor thing that needs to be addressed. In
getting rid of the patchdisk, my networking on the router is a bit
inconsistent. It looks like maybe networking is starting before
cloud-early-config completes, as /etc/network/interfaces looks right,
but I don't always get an ip on eth0.
I know next to nothing about upstart, and haven't had a chance to test
much, so if someone else can help that would be great. I've tried this
though and it worked the two times I rebooted, after 70% failures on
reboot. It goes it /etc/init/cloud-early-config-wait.conf
- script start here
#cloud-early-config-wait
start on (starting networking or starting network-interface)
instance $JOB
script
start cloud-early-config || true
# Waiting forever is ok.. upstart will kill this job when
# the service we tried to start above either starts or stops
while sleep 3600 ; do :; done
end script
script end here---
On Wed, Mar 6, 2013 at 9:10 AM, Marcus Sorensen shadow...@gmail.com
wrote:
On Wed, Mar 6, 2013 at 2:09 AM, Rohit Yadav bhais...@apache.org wrote:
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
I think the systemvm.iso is a completely fine way of getting new code
onto the system vms. My main goal at this point was to just get rid of
the patch disk portion. Also, since it sounds like we're wanting to
move to a link-local API to control the system vms I think we'll
forego qemu-guest-agent or putting our own daemon on the virtio serial
device and simply use it to copy the cmdline/authorized keys.
If this updated system vm checks out, I'll update the devcloud-kvm
packages with it preinstalled, replacing the older one. Or in the
meantime what I've been doing is simply downloading yours and moving
it into place over the existing one, giving it the same name, before
deploying anything.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com
wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com
wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
Re: Using newer DIY SystemVMs
On Fri, Mar 8, 2013 at 12:08 AM, Marcus Sorensen shadow...@gmail.com wrote: I see the qcow2 is now compressed, thanks. You can probably skip putting it in a bz2 now, it's about the same size. Had this thought but since we use the cloud-install-sys-tmplt script, it assumes a qcow2.bz2, see: http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.1-incubating/html/Installation_Guide/management-server-install-flow.html#prepare-system-vm-template We can fix the script, will do that as soon as I get to my keyboard. Regards. On Thu, Mar 7, 2013 at 10:58 AM, Marcus Sorensen shadow...@gmail.com wrote: Hmm. I think I was deceived by the /etc/init directory existing. I'm not sure why it's there, but I don't think the template is using upstart. I'm having a hard time reliably recreating the issue, but I think it's related to other reports where the default gateway is missing (I've seen this myself on a secondary storage VM, but it went away when I rebooted it, and couldn't get the problem to come back). This happens unrelated to any changes I'm making. On Wed, Mar 6, 2013 at 3:54 PM, Marcus Sorensen shadow...@gmail.com wrote: After reading a little more about upstart, I don't think this script does anything. I'm not entirely sure at the moment however how best to ensure that networking starts after cloud-early-config, short of converting cloud-early-config to an upstart script. It looks like this debian build is using upstart just for networking, and everything else uses the standard sysvinit ordering. On Wed, Mar 6, 2013 at 2:49 PM, Marcus Sorensen shadow...@gmail.com wrote: Just to be clear, that script may have no effect whatsoever, and I'm not sure how to verify other than rebooting a bunch of times. I don't have the time to do that at the moment. On Wed, Mar 6, 2013 at 2:48 PM, Marcus Sorensen shadow...@gmail.com wrote: There may be one other minor thing that needs to be addressed. In getting rid of the patchdisk, my networking on the router is a bit inconsistent. It looks like maybe networking is starting before cloud-early-config completes, as /etc/network/interfaces looks right, but I don't always get an ip on eth0. I know next to nothing about upstart, and haven't had a chance to test much, so if someone else can help that would be great. I've tried this though and it worked the two times I rebooted, after 70% failures on reboot. It goes it /etc/init/cloud-early-config-wait.conf - script start here #cloud-early-config-wait start on (starting networking or starting network-interface) instance $JOB script start cloud-early-config || true # Waiting forever is ok.. upstart will kill this job when # the service we tried to start above either starts or stops while sleep 3600 ; do :; done end script script end here--- On Wed, Mar 6, 2013 at 9:10 AM, Marcus Sorensen shadow...@gmail.com wrote: On Wed, Mar 6, 2013 at 2:09 AM, Rohit Yadav bhais...@apache.org wrote: Thanks a lot Marcus, your findings have been useful. I've applied the locale fix and a grub2 boot timeout fix (systemvms should boot 5 seconds faster now). Alright so far we're good, tested and systemvm seems to work on KVM (Marcus) and Xen, anyone to help us with VMWare? Marcus, about the qemu-ga, we need to patch all our templates as per systemvm type (ssvm, cpvm or rvm), for that we're using the systemvm.iso to patch the template appliance and we reboot once patching is done successfully in cloud-early-config. So, with using qemu-ga or our own daemon (assumming through socket we already got authorized key), do we want to make mgmt server or host copy the scripts inside the systemvm or just continue using current patching mechanism that uses the iso to mount and patch? Marcus can you share how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion). Regards. I think the systemvm.iso is a completely fine way of getting new code onto the system vms. My main goal at this point was to just get rid of the patch disk portion. Also, since it sounds like we're wanting to move to a link-local API to control the system vms I think we'll forego qemu-guest-agent or putting our own daemon on the virtio serial device and simply use it to copy the cmdline/authorized keys. If this updated system vm checks out, I'll update the devcloud-kvm packages with it preinstalled, replacing the older one. Or in the meantime what I've been doing is simply downloading yours and moving it into place over the existing one, giving it the same name, before deploying anything. On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com wrote: Oh, and I have yet to test all of the vpc functions, but so far so good. I was able to bring up the VPC, it got it's gateways all configured, and my public ip with portforwarding rule/ acl to allow 22 in worked. On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com wrote:
Re: Using newer DIY SystemVMs
On Thu, Mar 07, 2013 at 01:07:26PM -0700, Marcus Sorensen wrote: Ok, didn't realize we were going to point people to this particular system vm for production installs, I thought this was just a proof-of-concept for building custom ones. The intent was to be able to actually reproduce our system VMs programatically, which also happens to open up other opportunities!
Re: Using newer DIY SystemVMs
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
OK, one more niggle about the previous system vm. We tried to enable aesni
[1] to boost encryption performance (ipsec vpn, anything ssl), but the
system vm would crash on Vmware if we did that (hence the module
blacklisted). Could someone try the new systemvm on VMWare with aesni
enabled? I believe it is as simple as
modprobe aesni_intel and
openssl 1.0.1
[1] http://en.wikipedia.org/wiki/AES_instruction_set
On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote:
Hi all,
Thanks to Mate
(blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/)
I'm able to ship appliances that work for Xen. Chiradeep, there is no
need to use the powershell hack now, if people still want vhdx, they
can use that hack. The current appliance for Xen (vbox-raw-vhd)
works.
At least appliance for HyperV and Xen works:
http://jenkins.cloudstack.org/job/build-systemvm-master/
I've tested and found that:
- patching happens
- password server works
- apache was running, user data works
- template creation works
- snapshot to template works
I won't be able to test VPC/advance zone of DevCloud, ipv6 etc.
someone from QA would have to help.
Thanks Marcus for your suggestion, will compress qcow2 and test on KVM
today.
I need help on testing/fixing VMWare systemvm template appliance.
Ahmad :) all natural:
http://highlatencylife.files.wordpress.com/2010/12/awesomesauce.png
Regards.
PS. Was AFK yesterday, down with flu, much better now.
On Fri, Mar 1, 2013 at 11:29 PM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote:
- Saw systemvms started from the template, saw patching happening,
logged in with creds (root/password) to verify that it was indeed the
new one (Linux 3.2 :)
- The agents were running fine, there was a latency issue (agents were
lagging behind)
- (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM
work) VR came up, did it's SDN magic and tinyLinux was deployed
- Console proxy worked for me as well
I would also test
- password server
- user data management (is apache web server running?)
In addition
- zone-to-zone template copy
- template creation
- convert snapshot to template
- vpc
- ipv6
Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear
that they both differ in some magic bits?
Actually since we intend to support Windows 2012, we should be using
VHDX.
There's a way to do it with Powershell (from vhd(hyper-v) - vhdx)
http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershel
l-
to-convert-a-vhd-to-a-vhdx.aspx
Re: Using newer DIY SystemVMs
There may be one other minor thing that needs to be addressed. In
getting rid of the patchdisk, my networking on the router is a bit
inconsistent. It looks like maybe networking is starting before
cloud-early-config completes, as /etc/network/interfaces looks right,
but I don't always get an ip on eth0.
I know next to nothing about upstart, and haven't had a chance to test
much, so if someone else can help that would be great. I've tried this
though and it worked the two times I rebooted, after 70% failures on
reboot. It goes it /etc/init/cloud-early-config-wait.conf
- script start here
#cloud-early-config-wait
start on (starting networking or starting network-interface)
instance $JOB
script
start cloud-early-config || true
# Waiting forever is ok.. upstart will kill this job when
# the service we tried to start above either starts or stops
while sleep 3600 ; do :; done
end script
script end here---
On Wed, Mar 6, 2013 at 9:10 AM, Marcus Sorensen shadow...@gmail.com wrote:
On Wed, Mar 6, 2013 at 2:09 AM, Rohit Yadav bhais...@apache.org wrote:
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
I think the systemvm.iso is a completely fine way of getting new code
onto the system vms. My main goal at this point was to just get rid of
the patch disk portion. Also, since it sounds like we're wanting to
move to a link-local API to control the system vms I think we'll
forego qemu-guest-agent or putting our own daemon on the virtio serial
device and simply use it to copy the cmdline/authorized keys.
If this updated system vm checks out, I'll update the devcloud-kvm
packages with it preinstalled, replacing the older one. Or in the
meantime what I've been doing is simply downloading yours and moving
it into place over the existing one, giving it the same name, before
deploying anything.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
OK, one more niggle about the previous system vm. We tried to enable aesni
[1] to boost encryption performance (ipsec vpn, anything ssl), but the
system vm would crash on Vmware if we did that (hence the module
blacklisted). Could someone try the new systemvm on VMWare with aesni
enabled? I believe it is as simple as
modprobe aesni_intel and
openssl 1.0.1
[1] http://en.wikipedia.org/wiki/AES_instruction_set
On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote:
Hi all,
Thanks to Mate
(blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/)
I'm able to ship appliances that work for Xen. Chiradeep, there is no
need to use the powershell hack now, if people still want vhdx, they
can use that hack. The current appliance for Xen (vbox-raw-vhd)
works.
At least appliance for HyperV and Xen works:
http://jenkins.cloudstack.org/job/build-systemvm-master/
I've tested and found that:
- patching happens
- password server works
- apache was running, user data works
- template creation works
- snapshot to template works
I won't be able to test VPC/advance zone of DevCloud, ipv6 etc.
someone from QA would have to help.
Thanks Marcus for your suggestion, will compress qcow2 and test on KVM
today.
I need help on testing/fixing VMWare systemvm
Re: Using newer DIY SystemVMs
Just to be clear, that script may have no effect whatsoever, and I'm
not sure how to verify other than rebooting a bunch of times. I don't
have the time to do that at the moment.
On Wed, Mar 6, 2013 at 2:48 PM, Marcus Sorensen shadow...@gmail.com wrote:
There may be one other minor thing that needs to be addressed. In
getting rid of the patchdisk, my networking on the router is a bit
inconsistent. It looks like maybe networking is starting before
cloud-early-config completes, as /etc/network/interfaces looks right,
but I don't always get an ip on eth0.
I know next to nothing about upstart, and haven't had a chance to test
much, so if someone else can help that would be great. I've tried this
though and it worked the two times I rebooted, after 70% failures on
reboot. It goes it /etc/init/cloud-early-config-wait.conf
- script start here
#cloud-early-config-wait
start on (starting networking or starting network-interface)
instance $JOB
script
start cloud-early-config || true
# Waiting forever is ok.. upstart will kill this job when
# the service we tried to start above either starts or stops
while sleep 3600 ; do :; done
end script
script end here---
On Wed, Mar 6, 2013 at 9:10 AM, Marcus Sorensen shadow...@gmail.com wrote:
On Wed, Mar 6, 2013 at 2:09 AM, Rohit Yadav bhais...@apache.org wrote:
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
I think the systemvm.iso is a completely fine way of getting new code
onto the system vms. My main goal at this point was to just get rid of
the patch disk portion. Also, since it sounds like we're wanting to
move to a link-local API to control the system vms I think we'll
forego qemu-guest-agent or putting our own daemon on the virtio serial
device and simply use it to copy the cmdline/authorized keys.
If this updated system vm checks out, I'll update the devcloud-kvm
packages with it preinstalled, replacing the older one. Or in the
meantime what I've been doing is simply downloading yours and moving
it into place over the existing one, giving it the same name, before
deploying anything.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com
wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
OK, one more niggle about the previous system vm. We tried to enable
aesni
[1] to boost encryption performance (ipsec vpn, anything ssl), but the
system vm would crash on Vmware if we did that (hence the module
blacklisted). Could someone try the new systemvm on VMWare with aesni
enabled? I believe it is as simple as
modprobe aesni_intel and
openssl 1.0.1
[1] http://en.wikipedia.org/wiki/AES_instruction_set
On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote:
Hi all,
Thanks to Mate
(blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/)
I'm able to ship appliances that work for Xen. Chiradeep, there is no
need to use the powershell hack now, if people still want vhdx, they
can use that hack. The current appliance for Xen (vbox-raw-vhd)
works.
At least appliance for HyperV and Xen works:
http://jenkins.cloudstack.org/job/build-systemvm-master/
I've tested and found that:
- patching happens
- password server works
- apache was running, user data works
-
Re: Using newer DIY SystemVMs
After reading a little more about upstart, I don't think this script
does anything. I'm not entirely sure at the moment however how best to
ensure that networking starts after cloud-early-config, short of
converting cloud-early-config to an upstart script. It looks like this
debian build is using upstart just for networking, and everything else
uses the standard sysvinit ordering.
On Wed, Mar 6, 2013 at 2:49 PM, Marcus Sorensen shadow...@gmail.com wrote:
Just to be clear, that script may have no effect whatsoever, and I'm
not sure how to verify other than rebooting a bunch of times. I don't
have the time to do that at the moment.
On Wed, Mar 6, 2013 at 2:48 PM, Marcus Sorensen shadow...@gmail.com wrote:
There may be one other minor thing that needs to be addressed. In
getting rid of the patchdisk, my networking on the router is a bit
inconsistent. It looks like maybe networking is starting before
cloud-early-config completes, as /etc/network/interfaces looks right,
but I don't always get an ip on eth0.
I know next to nothing about upstart, and haven't had a chance to test
much, so if someone else can help that would be great. I've tried this
though and it worked the two times I rebooted, after 70% failures on
reboot. It goes it /etc/init/cloud-early-config-wait.conf
- script start here
#cloud-early-config-wait
start on (starting networking or starting network-interface)
instance $JOB
script
start cloud-early-config || true
# Waiting forever is ok.. upstart will kill this job when
# the service we tried to start above either starts or stops
while sleep 3600 ; do :; done
end script
script end here---
On Wed, Mar 6, 2013 at 9:10 AM, Marcus Sorensen shadow...@gmail.com wrote:
On Wed, Mar 6, 2013 at 2:09 AM, Rohit Yadav bhais...@apache.org wrote:
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
I think the systemvm.iso is a completely fine way of getting new code
onto the system vms. My main goal at this point was to just get rid of
the patch disk portion. Also, since it sounds like we're wanting to
move to a link-local API to control the system vms I think we'll
forego qemu-guest-agent or putting our own daemon on the virtio serial
device and simply use it to copy the cmdline/authorized keys.
If this updated system vm checks out, I'll update the devcloud-kvm
packages with it preinstalled, replacing the older one. Or in the
meantime what I've been doing is simply downloading yours and moving
it into place over the existing one, giving it the same name, before
deploying anything.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com
wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com
wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
OK, one more niggle about the previous system vm. We tried to enable
aesni
[1] to boost encryption performance (ipsec vpn, anything ssl), but the
system vm would crash on Vmware if we did that (hence the module
blacklisted). Could someone try the new systemvm on VMWare with aesni
enabled? I believe it is as simple as
modprobe aesni_intel and
openssl 1.0.1
[1] http://en.wikipedia.org/wiki/AES_instruction_set
On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote:
Hi all,
Thanks to Mate
Re: Using newer DIY SystemVMs
OK, one more niggle about the previous system vm. We tried to enable aesni [1] to boost encryption performance (ipsec vpn, anything ssl), but the system vm would crash on Vmware if we did that (hence the module blacklisted). Could someone try the new systemvm on VMWare with aesni enabled? I believe it is as simple as modprobe aesni_intel and openssl 1.0.1 [1] http://en.wikipedia.org/wiki/AES_instruction_set On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote: Hi all, Thanks to Mate (blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/) I'm able to ship appliances that work for Xen. Chiradeep, there is no need to use the powershell hack now, if people still want vhdx, they can use that hack. The current appliance for Xen (vbox-raw-vhd) works. At least appliance for HyperV and Xen works: http://jenkins.cloudstack.org/job/build-systemvm-master/ I've tested and found that: - patching happens - password server works - apache was running, user data works - template creation works - snapshot to template works I won't be able to test VPC/advance zone of DevCloud, ipv6 etc. someone from QA would have to help. Thanks Marcus for your suggestion, will compress qcow2 and test on KVM today. I need help on testing/fixing VMWare systemvm template appliance. Ahmad :) all natural: http://highlatencylife.files.wordpress.com/2010/12/awesomesauce.png Regards. PS. Was AFK yesterday, down with flu, much better now. On Fri, Mar 1, 2013 at 11:29 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote: - Saw systemvms started from the template, saw patching happening, logged in with creds (root/password) to verify that it was indeed the new one (Linux 3.2 :) - The agents were running fine, there was a latency issue (agents were lagging behind) - (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM work) VR came up, did it's SDN magic and tinyLinux was deployed - Console proxy worked for me as well I would also test - password server - user data management (is apache web server running?) In addition - zone-to-zone template copy - template creation - convert snapshot to template - vpc - ipv6 Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear that they both differ in some magic bits? Actually since we intend to support Windows 2012, we should be using VHDX. There's a way to do it with Powershell (from vhd(hyper-v) - vhdx) http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershel l- to-convert-a-vhd-to-a-vhdx.aspx
Re: Using newer DIY SystemVMs
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
OK, one more niggle about the previous system vm. We tried to enable aesni
[1] to boost encryption performance (ipsec vpn, anything ssl), but the
system vm would crash on Vmware if we did that (hence the module
blacklisted). Could someone try the new systemvm on VMWare with aesni
enabled? I believe it is as simple as
modprobe aesni_intel and
openssl 1.0.1
[1] http://en.wikipedia.org/wiki/AES_instruction_set
On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote:
Hi all,
Thanks to Mate
(blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/)
I'm able to ship appliances that work for Xen. Chiradeep, there is no
need to use the powershell hack now, if people still want vhdx, they
can use that hack. The current appliance for Xen (vbox-raw-vhd)
works.
At least appliance for HyperV and Xen works:
http://jenkins.cloudstack.org/job/build-systemvm-master/
I've tested and found that:
- patching happens
- password server works
- apache was running, user data works
- template creation works
- snapshot to template works
I won't be able to test VPC/advance zone of DevCloud, ipv6 etc.
someone from QA would have to help.
Thanks Marcus for your suggestion, will compress qcow2 and test on KVM
today.
I need help on testing/fixing VMWare systemvm template appliance.
Ahmad :) all natural:
http://highlatencylife.files.wordpress.com/2010/12/awesomesauce.png
Regards.
PS. Was AFK yesterday, down with flu, much better now.
On Fri, Mar 1, 2013 at 11:29 PM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote:
- Saw systemvms started from the template, saw patching happening,
logged in with creds (root/password) to verify that it was indeed the
new one (Linux 3.2 :)
- The agents were running fine, there was a latency issue (agents were
lagging behind)
- (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM
work) VR came up, did it's SDN magic and tinyLinux was deployed
- Console proxy worked for me as well
I would also test
- password server
- user data management (is apache web server running?)
In addition
- zone-to-zone template copy
- template creation
- convert snapshot to template
- vpc
- ipv6
Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear
that they both differ in some magic bits?
Actually since we intend to support Windows 2012, we should be using
VHDX.
There's a way to do it with Powershell (from vhd(hyper-v) - vhdx)
http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershel
l-
to-convert-a-vhd-to-a-vhdx.aspx
Re: Using newer DIY SystemVMs
Rohit, thanks for this. I'm going to play with your system vm template to see if we can support KVM virtio communication rather than ssh to KVM system vms. One thing I thought I'd mention was that it might be better to compress the qcow2 image natively (via qemu-img convert -c flag) rather than bz2, because it is usable as compressed, which will speed deployment of the base system vm image, and people won't have to unzip. On Fri, Mar 1, 2013 at 5:48 PM, Sheng Yang sh...@yasker.org wrote: Thank Rohit! I would try this template for ipv6 later... --Sheng On Fri, Mar 1, 2013 at 10:23 AM, Ahmad Emneina aemne...@gmail.com wrote: wow, roll your own template sounds awesome. Rohit == awesomesauce On Fri, Mar 1, 2013 at 9:59 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote: - Saw systemvms started from the template, saw patching happening, logged in with creds (root/password) to verify that it was indeed the new one (Linux 3.2 :) - The agents were running fine, there was a latency issue (agents were lagging behind) - (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM work) VR came up, did it's SDN magic and tinyLinux was deployed - Console proxy worked for me as well I would also test - password server - user data management (is apache web server running?) In addition - zone-to-zone template copy - template creation - convert snapshot to template - vpc - ipv6 Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear that they both differ in some magic bits? Actually since we intend to support Windows 2012, we should be using VHDX. There's a way to do it with Powershell (from vhd(hyper-v) - vhdx) http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershell- to-convert-a-vhd-to-a-vhdx.aspx
Re: Using newer DIY SystemVMs
Hi all, Thanks to Mate (blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/) I'm able to ship appliances that work for Xen. Chiradeep, there is no need to use the powershell hack now, if people still want vhdx, they can use that hack. The current appliance for Xen (vbox-raw-vhd) works. At least appliance for HyperV and Xen works: http://jenkins.cloudstack.org/job/build-systemvm-master/ I've tested and found that: - patching happens - password server works - apache was running, user data works - template creation works - snapshot to template works I won't be able to test VPC/advance zone of DevCloud, ipv6 etc. someone from QA would have to help. Thanks Marcus for your suggestion, will compress qcow2 and test on KVM today. I need help on testing/fixing VMWare systemvm template appliance. Ahmad :) all natural: http://highlatencylife.files.wordpress.com/2010/12/awesomesauce.png Regards. PS. Was AFK yesterday, down with flu, much better now. On Fri, Mar 1, 2013 at 11:29 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote: - Saw systemvms started from the template, saw patching happening, logged in with creds (root/password) to verify that it was indeed the new one (Linux 3.2 :) - The agents were running fine, there was a latency issue (agents were lagging behind) - (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM work) VR came up, did it's SDN magic and tinyLinux was deployed - Console proxy worked for me as well I would also test - password server - user data management (is apache web server running?) In addition - zone-to-zone template copy - template creation - convert snapshot to template - vpc - ipv6 Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear that they both differ in some magic bits? Actually since we intend to support Windows 2012, we should be using VHDX. There's a way to do it with Powershell (from vhd(hyper-v) - vhdx) http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershell- to-convert-a-vhd-to-a-vhdx.aspx
Re: Using newer DIY SystemVMs
I can run it through some basic VPC testing. On my system VM/console proxy, I don't seem to get a default route. I noticed this when trying to register a new template, then checked the console proxy VM as well. After running 'ip route add default via 192.168.100.1' I was able to register the template successfully. I just tried to launch a router, and it keeps rebooting right after it comes up. I'll troubleshoot it a bit tomorrow. On Mon, Mar 4, 2013 at 11:46 PM, Rohit Yadav bhais...@apache.org wrote: Hi all, Thanks to Mate (blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/) I'm able to ship appliances that work for Xen. Chiradeep, there is no need to use the powershell hack now, if people still want vhdx, they can use that hack. The current appliance for Xen (vbox-raw-vhd) works. At least appliance for HyperV and Xen works: http://jenkins.cloudstack.org/job/build-systemvm-master/ I've tested and found that: - patching happens - password server works - apache was running, user data works - template creation works - snapshot to template works I won't be able to test VPC/advance zone of DevCloud, ipv6 etc. someone from QA would have to help. Thanks Marcus for your suggestion, will compress qcow2 and test on KVM today. I need help on testing/fixing VMWare systemvm template appliance. Ahmad :) all natural: http://highlatencylife.files.wordpress.com/2010/12/awesomesauce.png Regards. PS. Was AFK yesterday, down with flu, much better now. On Fri, Mar 1, 2013 at 11:29 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote: - Saw systemvms started from the template, saw patching happening, logged in with creds (root/password) to verify that it was indeed the new one (Linux 3.2 :) - The agents were running fine, there was a latency issue (agents were lagging behind) - (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM work) VR came up, did it's SDN magic and tinyLinux was deployed - Console proxy worked for me as well I would also test - password server - user data management (is apache web server running?) In addition - zone-to-zone template copy - template creation - convert snapshot to template - vpc - ipv6 Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear that they both differ in some magic bits? Actually since we intend to support Windows 2012, we should be using VHDX. There's a way to do it with Powershell (from vhd(hyper-v) - vhdx) http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershell- to-convert-a-vhd-to-a-vhdx.aspx
Re: Using newer DIY SystemVMs
-- Prasanna., On 01-Mar-2013, at 17:33, Rohit Yadav bhais...@apache.org wrote: Hi all, Just want to share that the do-it-yourself systemvm appliance feature works for me, for Xen. There is one catch though, VirtualBox exports VHD appliance which is said to be compliant with HyperV. I thought we may need to do something for Xen separately, so I followed and found a way [1]. The way is to export a raw disk image and convert it to a VHD [1] but the problem is the VHD created from that way fails when vhd-util tries to scan for any dependent VHDs (parents etc.), I don't know what's the reason. So, I use the VHD appliance from VBox named as http://jenkins.cloudstack.org/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvmtemplate-2013-02-28-master-hyperv.vhd.bz2 and it worked for me on DevCloud. Maybe the VHD (HyperV) format is compatible with Xen now. So, I'm late about a day, but we've a new systemvm template that is tested for Xen and works with basic zone deployment, some observations on 4.1: - Saw systemvms started from the template, saw patching happening, logged in with creds (root/password) to verify that it was indeed the new one (Linux 3.2 :) - The agents were running fine, there was a latency issue (agents were lagging behind) - (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM work) VR came up, did it's SDN magic and tinyLinux was deployed - Console proxy worked for me as well Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear that they both differ in some magic bits? Chandan, now that I've tested and confirmed them for Xen, can you start to help us test the appliances? Just make sure you use the hyperv-vhd appliance for now and if they fail for you, let me know. To preseed, just download and bzip2 -d them to you secondary/template/tmpl/1/1/ --- History (in case you want to know more): So, as a experiment I tried a lot of tool vhd2xen, XenConvert, XenServerConversion tool, qemu (vpc) etc. None of them worked for me. The problem I saw was that on jenkins server where we are actually building [1][2] the appliance, I had to compile my own vhd-util from a patch [1]. The script that does this job is in tools/appliance/build.sh. The way was to export a raw appliance: vboxmanage internalcommands converttoraw $hdd_path raw.img This is then converted to a fixed vhd disk: vhd-util convert -s 0 -t 1 -i raw.img -o $appliance-$build_date-$branch-xen.vhd On the jenkins server, when I run scan: vhd-util scan -f -c -a -v appliance-for-xen.vhd it succeeds and results that it is fixed disk with no parent and it's capacity and size in bytes. On DevCloud when I preseed the appliance in /opt/storage/secondary/template.../1/1/, and when CloudStack tries to start systemvms for the first time when host is added, it would run the same vhd-util scan command and fail. Output of the command when I run it: root@devcloud:/tmp# vhd-util scan -f -c -m systemvmtemplate-2013-02-28-master-xen.vhd vhd=systemvmtemplate-2013-02-28-master-xen.vhd scan-error=-22 error-message='opening file' The vhd-util on the jenkins server is a patched one [3] and it succeeds on the above command. I've asked few Xen folks to help us out. [1] http://rohityadav.in/logs/building-systemvms/ [2] http://jenkins.cloudstack.org/job/build-systemvm-master/ [3] blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd Regards. Just want to say. Great work Rohit. This was needed and you've done a super job!
Re: Using newer DIY SystemVMs
On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote: - Saw systemvms started from the template, saw patching happening, logged in with creds (root/password) to verify that it was indeed the new one (Linux 3.2 :) - The agents were running fine, there was a latency issue (agents were lagging behind) - (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM work) VR came up, did it's SDN magic and tinyLinux was deployed - Console proxy worked for me as well I would also test - password server - user data management (is apache web server running?) In addition - zone-to-zone template copy - template creation - convert snapshot to template - vpc - ipv6 Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear that they both differ in some magic bits? Actually since we intend to support Windows 2012, we should be using VHDX. There's a way to do it with Powershell (from vhd(hyper-v) - vhdx) http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershell- to-convert-a-vhd-to-a-vhdx.aspx
Re: Using newer DIY SystemVMs
wow, roll your own template sounds awesome. Rohit == awesomesauce On Fri, Mar 1, 2013 at 9:59 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote: - Saw systemvms started from the template, saw patching happening, logged in with creds (root/password) to verify that it was indeed the new one (Linux 3.2 :) - The agents were running fine, there was a latency issue (agents were lagging behind) - (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM work) VR came up, did it's SDN magic and tinyLinux was deployed - Console proxy worked for me as well I would also test - password server - user data management (is apache web server running?) In addition - zone-to-zone template copy - template creation - convert snapshot to template - vpc - ipv6 Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear that they both differ in some magic bits? Actually since we intend to support Windows 2012, we should be using VHDX. There's a way to do it with Powershell (from vhd(hyper-v) - vhdx) http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershell- to-convert-a-vhd-to-a-vhdx.aspx
Re: Using newer DIY SystemVMs
Thank Rohit! I would try this template for ipv6 later... --Sheng On Fri, Mar 1, 2013 at 10:23 AM, Ahmad Emneina aemne...@gmail.com wrote: wow, roll your own template sounds awesome. Rohit == awesomesauce On Fri, Mar 1, 2013 at 9:59 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote: - Saw systemvms started from the template, saw patching happening, logged in with creds (root/password) to verify that it was indeed the new one (Linux 3.2 :) - The agents were running fine, there was a latency issue (agents were lagging behind) - (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM work) VR came up, did it's SDN magic and tinyLinux was deployed - Console proxy worked for me as well I would also test - password server - user data management (is apache web server running?) In addition - zone-to-zone template copy - template creation - convert snapshot to template - vpc - ipv6 Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear that they both differ in some magic bits? Actually since we intend to support Windows 2012, we should be using VHDX. There's a way to do it with Powershell (from vhd(hyper-v) - vhdx) http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershell- to-convert-a-vhd-to-a-vhdx.aspx
