cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: Using newer DIY SystemVMs
Date Fri, 08 Mar 2013 03:55:19 GMT
Just for confirmation, we are going to require a new system VM in 4.2 (or
5.0?), right? 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...
On Mar 1, 2013 5:04 AM, "Rohit Yadav" <> 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
> 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/ 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]
> [2]
> [3]
> Regards.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message