Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 198C410748 for ; Mon, 1 Dec 2014 22:17:22 +0000 (UTC) Received: (qmail 35438 invoked by uid 500); 1 Dec 2014 22:17:16 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 35389 invoked by uid 500); 1 Dec 2014 22:17:16 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 35371 invoked by uid 99); 1 Dec 2014 22:17:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2014 22:17:16 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of williamstevens@gmail.com designates 209.85.192.174 as permitted sender) Received: from [209.85.192.174] (HELO mail-pd0-f174.google.com) (209.85.192.174) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2014 22:17:12 +0000 Received: by mail-pd0-f174.google.com with SMTP id w10so11686742pde.19 for ; Mon, 01 Dec 2014 14:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=l2Sgf/Q4BzCXc1+HavsRz4IPr9G0/lOjRM09RKQ5On8=; b=mRAv8zIIl4yH4WSk6WiuIvNx+ZZ3zM/NHoSJ52HqwK/w+bW2YfZ+OFlMOF7wTGolup 1pU4zpdKCVz8RiLNp9Yvq/ucFvJUmCsDWG0zgLCkebRfc2U69PZul+BZFsoqvA0Pgwhh BpU+CQ31MRa25r5qPK8hdqLmNrchyiwYAT2XGXI4TDY1aRdvZLKR71ybKD2vyidNzQDh tWrQZsV1pxI2IB+TIBXR47Vd0fjnsPrNuJk0GmqTa4kgmWq4fHPqvQK4yJzZkqSy9IJc TlEbTV2A+VSecqa9cTkjwzOJ3lAN956QnVMIL7dzIDmpV1F2buz6TFJcSM6+h9sVfcxA IlVg== MIME-Version: 1.0 X-Received: by 10.68.165.100 with SMTP id yx4mr104969816pbb.79.1417472212023; Mon, 01 Dec 2014 14:16:52 -0800 (PST) Sender: williamstevens@gmail.com Received: by 10.70.116.73 with HTTP; Mon, 1 Dec 2014 14:16:51 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Dec 2014 17:16:51 -0500 X-Google-Sender-Auth: opEYnK0Rljxs3xJyx1YY1RDO0q0 Message-ID: Subject: Re: 05bec59c - kvm, qcow, systemvm qemu-img -o compat From: Will Stevens To: "dev@cloudstack.apache.org" Cc: Leo Simons , Wilder Rodrigues , Rohit Yadav , Edison Su Content-Type: multipart/alternative; boundary=047d7b44febead422e05092ef731 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b44febead422e05092ef731 Content-Type: text/plain; charset=UTF-8 Alright, so far I have found the following: https://github.com/qemu/qemu/commit/9117b47717ad208b12786ce88eacb013f9b3dd1c Basically, if the qemu-img version is less than 1.7, we should run the non 'compat' option version and if the version is 1.7 or greater, we should run the new command with the 'compat' version. Unfortunately I am not able to find a way to get the qemu-img version from the command line. I am looking to basically add a conditional to try running with the compat option and if that fails, then run it without the compat option. Basically, I would be replacing this: qemu-img convert -o compat=0.10 -f raw -c -O qcow2 raw.img "${appliance_build_name}-kvm.qcow2" With this: set +e qemu-img convert -o compat=0.10 -f raw -c -O qcow2 raw.img "${appliance_build_name}-kvm.qcow2" local qemuresult=$? set -e if [ ${qemuresult} != 0 ]; then log INFO "qemu-img convert failed, trying without compat option" qemu-img convert -f raw -c -O qcow2 raw.img "${appliance_build_name}-kvm.qcow2" fi What do you guys think? Is this a good enough solution? If you guys agree I will implement it in master and make sure it works, then we can merge the change back to 4.5 to fix that branch as well. Let me know if you have issues with this approach... Cheers, Will *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Mon, Dec 1, 2014 at 4:06 PM, Will Stevens wrote: > Edison, > According to this page the default compat option is 0.10: > http://manpages.ubuntu.com/manpages/trusty/man1/qemu-img.1.html > > Did you find that to not be the case and is that why you had to add the > compat option? > > BTW, in an attempt to get the master system vms building again, I > committed a change to master to remove the compat option. We now have > master system vms building correctly, but Rohit rightly pointed out that I > had basically reverted your change. > > I created a Jira ticket for this issue: > https://issues.apache.org/jira/browse/CLOUDSTACK-7959 > > I have not reverted my change in master at this point, so it is building > right now, but I also did not make the change to 4.5, so that branch is > currently failing to build system vms. > > I will see if I can track down in which version of qemu the compat option > was added so we can add some intelligent logic around this command. > > Will > > > > > *Will STEVENS* > Lead Developer > > *CloudOps* *| *Cloud Solutions Experts > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 > w cloudops.com *|* tw @CloudOps_ > > On Thu, Nov 20, 2014 at 1:07 PM, edison su wrote: > >> Hi Leo, >> Our new internal build system are using ubuntu 14.04 or something like >> that, which has qemu 1.x installed by default, that's why I added the >> "compat" option in the build script, otherwise, the image build by >> qemu 1.x, won't work on RHEL 6.x. >> The fix would be, in the build script, check the version of qemu-img, >> if it's 0.x, then don't add "compat" option. There are a lot of people >> still using RHEL 6.x as KVM hypervisor, we have to make sure the image >> we build can still work on these machines. >> >> On Thu, Nov 20, 2014 at 6:49 AM, Leo Simons >> wrote: >> > Hey Edison, all, >> > >> > >> https://github.com/apache/cloudstack/commit/05bec59c1498dbcfb8a1089c86855fd3b433ea58 >> > >> > breaks our internal build with >> > >> > + qemu-img convert -o compat=0.10 -f raw -c -O qcow2 raw.img \ >> > systemvmtemplate-systemvm-persistent-config-4.5.0.124-kvm.qcow2 >> > Unknown option 'compat' >> > qemu-img: Invalid options for file format 'qcow2'. >> > >> > This is on CentOS release 6.6, which has >> qemu-img-0.15.0-1.el6.rfx.x86_64. >> > >> > Based on >> > http://wiki.qemu.org/OlderNews >> > that seems like it is a really old qemu (august 2011). >> > >> > I'm guessing you have a newer OS / newer qemu? Can you please let me >> know what OS, OS version and qemu(-img) version you are using? >> > >> > Also, does anyone know if there some minimum version of qemu-img that >> should be used / cloudstack assumes? Is 0.15 still ok to do an acceptable >> image conversion with? (we currently don't have any kvm use ourselves, but, >> I'd like for our build infra to produce useful kvm images nonetheless). >> > >> > According to >> > http://wiki.qemu.org/ChangeLog/1.1 >> > the -o compat switch was introduced in 1.1. >> > >> > According to >> > >> https://github.com/qemu/qemu/commit/9117b47717ad208b12786ce88eacb013f9b3dd1c >> > the default format was changed from 0.10 to 1.1 in qemu 1.7 and onwards. >> > >> > The libvirt people >> > https://bugzilla.redhat.com/show_bug.cgi?id=997977 >> > say they pass -o compat when qemu supports it (so when v >= 1.1 I >> imagine). >> > >> > I think we should do the same in the build script and I'll make a patch. >> > >> > But, should we publish newer-format images too? According to >> > http://wiki.qemu.org/Features/Qcow3 >> > the new format is much better so I imagine qcow/kvm users will really >> appreciate the newer formats. >> > >> > Thoughts? >> > >> > >> > cheers, >> > >> > >> > Leo >> > >> >> >> >> -- >> Best Regards, >> Edison >> > > --047d7b44febead422e05092ef731--