From pmyers at redhat.com Wed Oct 1 01:00:20 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 30 Sep 2008 21:00:20 -0400 Subject: [Thincrust-devel] Errors w/ qcow output from appliance-tools In-Reply-To: <48E2A4FE.5090801@redhat.com> References: <48E2A4FE.5090801@redhat.com> Message-ID: <48E2CBA4.5010709@redhat.com> Perry N. Myers wrote: > David, > > Here's some info on the problem that I've been having. > > I used the attached kickstart (foo.ks) and ran: > appliance-creator --config foo.ks --name foo -f qcow -d -v > > The output includes the following: >> writing image XML to /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo.xml >> converting /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.raw image to >> /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.qcow >> qemu-img: Could not open >> '/var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.qcow' >> Unable to convert disk format to qcow, using raw disk image >> moving disks to final location >> moving /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo.xml to >> /var/tmp/imgcreate-223Oxs/out >> moving /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.raw to >> /var/tmp/imgcreate-223Oxs/out >> moving /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.qcow to >> /var/tmp/imgcreate-223Oxs/out >> done > > Full output is on: > http://ovirt.pastebin.com/d1d01f7cb > > foo.ks is very basic. Just the min stuff needed to create an appliance > really using base-pkgs. > > These are the versions I am using: > appliance-tools-002-3.fc9.noarch > appliance-os-001-3.fc9.noarch > > I've tried this on multiple Fedora 9 hosts and had the same results. > > Let me know if your investigation using this kickstart/commandline > reveals anything. Follow up. This is very odd... The kickstart has this in it: part / --ondisk=sda --fstype=ext3 --size=2000 If I toggle to size 10000 it works fine 2000, 5000, 9000, 11000, 16000, 20000 failed 10000 succeeds Why would this work with a size of 10000 but nothing else??? Perry From bkearney at redhat.com Wed Oct 1 12:10:10 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 01 Oct 2008 08:10:10 -0400 Subject: [Thincrust-devel] Errors w/ qcow output from appliance-tools In-Reply-To: <48E2CBA4.5010709@redhat.com> References: <48E2A4FE.5090801@redhat.com> <48E2CBA4.5010709@redhat.com> Message-ID: <48E368A2.1040507@redhat.com> Perry N. Myers wrote: > Perry N. Myers wrote: >> David, >> >> Here's some info on the problem that I've been having. >> >> I used the attached kickstart (foo.ks) and ran: >> appliance-creator --config foo.ks --name foo -f qcow -d -v >> >> The output includes the following: >>> writing image XML to /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo.xml >>> converting /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.raw image to >>> /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.qcow >>> qemu-img: Could not open >>> '/var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.qcow' >>> Unable to convert disk format to qcow, using raw disk image >>> moving disks to final location >>> moving /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo.xml to >>> /var/tmp/imgcreate-223Oxs/out >>> moving /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.raw to >>> /var/tmp/imgcreate-223Oxs/out >>> moving /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.qcow to >>> /var/tmp/imgcreate-223Oxs/out >>> done >> >> Full output is on: >> http://ovirt.pastebin.com/d1d01f7cb >> >> foo.ks is very basic. Just the min stuff needed to create an >> appliance really using base-pkgs. >> >> These are the versions I am using: >> appliance-tools-002-3.fc9.noarch >> appliance-os-001-3.fc9.noarch >> >> I've tried this on multiple Fedora 9 hosts and had the same results. >> >> Let me know if your investigation using this kickstart/commandline >> reveals anything. > > Follow up. This is very odd... > > The kickstart has this in it: > part / --ondisk=sda --fstype=ext3 --size=2000 > > If I toggle to size 10000 it works fine > > 2000, 5000, 9000, 11000, 16000, 20000 failed > 10000 succeeds > > Why would this work with a size of 10000 but nothing else??? This may be an x86_64 thing. I did the following: - downloaded your foo.ks - installed the latest appliance-os rpm from ovirt.org - edited the kicstart file with :%s/x84_64/i386/g - ran appliance-creator --config foo.ks --name foo -f qcow2 -d -v So the only differences are 1) arhictecture 2) qcow versus qcow2 I got an error with qcow on my machine, so I either have an older appliance-tools or that was a typo inthe original message. -- bk From pmyers at redhat.com Wed Oct 1 12:49:18 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Wed, 01 Oct 2008 08:49:18 -0400 Subject: [Thincrust-devel] Errors w/ qcow output from appliance-tools In-Reply-To: <48E368A2.1040507@redhat.com> References: <48E2A4FE.5090801@redhat.com> <48E2CBA4.5010709@redhat.com> <48E368A2.1040507@redhat.com> Message-ID: <48E371CE.6030904@redhat.com> Bryan Kearney wrote: > Perry N. Myers wrote: >> Perry N. Myers wrote: >>> David, >>> >>> Here's some info on the problem that I've been having. >>> >>> I used the attached kickstart (foo.ks) and ran: >>> appliance-creator --config foo.ks --name foo -f qcow -d -v >>> >>> The output includes the following: >>>> writing image XML to /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo.xml >>>> converting /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.raw image to >>>> /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.qcow >>>> qemu-img: Could not open >>>> '/var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.qcow' >>>> Unable to convert disk format to qcow, using raw disk image >>>> moving disks to final location >>>> moving /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo.xml to >>>> /var/tmp/imgcreate-223Oxs/out >>>> moving /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.raw to >>>> /var/tmp/imgcreate-223Oxs/out >>>> moving /var/tmp/imgcreate-223Oxs/tmp-N65fLE/foo-sda.qcow to >>>> /var/tmp/imgcreate-223Oxs/out >>>> done >>> >>> Full output is on: >>> http://ovirt.pastebin.com/d1d01f7cb >>> >>> foo.ks is very basic. Just the min stuff needed to create an >>> appliance really using base-pkgs. >>> >>> These are the versions I am using: >>> appliance-tools-002-3.fc9.noarch >>> appliance-os-001-3.fc9.noarch >>> >>> I've tried this on multiple Fedora 9 hosts and had the same results. >>> >>> Let me know if your investigation using this kickstart/commandline >>> reveals anything. >> >> Follow up. This is very odd... >> >> The kickstart has this in it: >> part / --ondisk=sda --fstype=ext3 --size=2000 >> >> If I toggle to size 10000 it works fine >> >> 2000, 5000, 9000, 11000, 16000, 20000 failed >> 10000 succeeds >> >> Why would this work with a size of 10000 but nothing else??? > > This may be an x86_64 thing. I did the following: > > - downloaded your foo.ks > - installed the latest appliance-os rpm from ovirt.org > - edited the kicstart file with :%s/x84_64/i386/g > - ran appliance-creator --config foo.ks --name foo -f qcow2 -d -v > > So the only differences are > 1) arhictecture > 2) qcow versus qcow2 > > I got an error with qcow on my machine, so I either have an older > appliance-tools or that was a typo inthe original message. Actually, once I changed from qcow to qcow2 everything worked fine. So apparently there are problems with using the qcow format. You guys might want to diagnose and/or document this. Or just say that qcow is not a supported format. Incidentally, my usage of qcow instead of qcow2 was a typo on my part... Perry From apevec at redhat.com Thu Oct 2 01:05:08 2008 From: apevec at redhat.com (Alan Pevec) Date: Thu, 02 Oct 2008 03:05:08 +0200 Subject: [Thincrust-devel] livecd-tools for EL-5 Message-ID: <48E41E44.9030306@redhat.com> Hi guys, so I was working on making livecd-tools more usable on EL-5 (RHEL5 and friends) I started with livecd-tools found in EPEL http://cvs.fedoraproject.org/viewvc//rpms/livecd-tools/EL-5/ This one starts with livecd-tools-013.tar.bz2 tarball adding few compat patches to make it run on EL-5. It turns out that tarball is _not_ 013 release but actually a tarball of complete git checkout somewhere between 013 and 014. To untangle this, I created livecd fork git repo http://repo.or.cz/w/livecd/EPEL5.git tag livecd-tools-013-8-EPEL5 marks the content of the above tarball and EPEL RPM patches are imported till tag livecd-tools-013-8-EPEL5-patches On top of that, I've backported some upstream changes, like pxeboot support. I've also added --global-config as an experimental feature, it should allow using rhnplugin (untested). But this approach isn't workable in the long run, livecd-tools were changed and refactored too much and it's already more than 10 patches in RPM. So second approach was to start with livecd tip and forward port EL-5 compat patches: http://repo.or.cz/w/livecd/EL-5.git - tag EL-5-proposed-start marks the start of EL-5 compat patches. NOTE: this git repo is experimental and might get rebased to track upstream livecd changes Main EL-5 compat patches are: - python 2.4 compat syntax - get mayflower back, since we can't upgrade mkinitrd RPM - import newer pykickstart (included as git submodule) I believe this approach is less maintenance burden, as upstream progresses we just need to keep forward-porting above 3 patches and get new fixes/features for free. It also makes appliance-tools for EL-5 easier, Fedora10 version would just work. Please review the patches and tell me what do you think. As a first step, I would push 013 based patches (EPEL5.git) to EPEL and then ask maintainers if they're willing to jump to 018. BTW, I've asked livecd upstream to open a branch for EPEL but didn't get any response yet, hence I started using repo.or.cz Alan Pevec From dhuff at redhat.com Thu Oct 2 13:33:48 2008 From: dhuff at redhat.com (David Huff) Date: Thu, 02 Oct 2008 09:33:48 -0400 Subject: [Thincrust-devel] livecd-tools for EL-5 In-Reply-To: <48E41E44.9030306@redhat.com> References: <48E41E44.9030306@redhat.com> Message-ID: <48E4CDBC.5030107@redhat.com> Alan Pevec wrote: > Hi guys, > > so I was working on making livecd-tools more usable on EL-5 (RHEL5 and > friends) good stuff..... > I started with livecd-tools found in EPEL > http://cvs.fedoraproject.org/viewvc//rpms/livecd-tools/EL-5/ > This one starts with livecd-tools-013.tar.bz2 tarball adding few compat > patches to make it run on EL-5. > It turns out that tarball is _not_ 013 release but actually a tarball of > complete git checkout somewhere between 013 and 014. To untangle this, I > created livecd fork git repo http://repo.or.cz/w/livecd/EPEL5.git > > tag livecd-tools-013-8-EPEL5 marks the content of the above tarball and > EPEL RPM patches are imported till tag livecd-tools-013-8-EPEL5-patches > On top of that, I've backported some upstream changes, like pxeboot > support. > I've also added --global-config as an experimental feature, it should > allow using rhnplugin (untested). > > But this approach isn't workable in the long run, livecd-tools were > changed and refactored too much and it's already more than 10 patches in > RPM. > > So second approach was to start with livecd tip and forward port EL-5 > compat patches: http://repo.or.cz/w/livecd/EL-5.git - tag > EL-5-proposed-start marks the start of EL-5 compat patches. > NOTE: this git repo is experimental and might get rebased to track > upstream livecd changes > Main EL-5 compat patches are: > - python 2.4 compat syntax > - get mayflower back, since we can't upgrade mkinitrd RPM > - import newer pykickstart (included as git submodule) > > I believe this approach is less maintenance burden, as upstream > progresses we just need to keep forward-porting above 3 patches and get > new fixes/features for free. It also makes appliance-tools for EL-5 > easier, Fedora10 version would just work. > > Please review the patches and tell me what do you think. > As a first step, I would push 013 based patches (EPEL5.git) to EPEL and > then ask maintainers if they're willing to jump to 018. Sounds like a reasonable approach I try to grab the code and do some testing today and tomorrow. My test boxes are down while they relocate my cube so not sure how much I can get done today. > > BTW, I've asked livecd upstream to open a branch for EPEL but didn't get > any response yet, hence I started using repo.or.cz > Let us know if there is any thing we can do to help out here. -D From jboggs at redhat.com Fri Oct 3 01:52:51 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 02 Oct 2008 21:52:51 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator Message-ID: <48E57AF3.7060507@redhat.com> Adds md5/sha256 disk signature support for appliance-creator enabled by --checksum option Still awaiting approval and commit for python-virtinst for virt-image import verification portions. -------------- next part -------------- A non-text attachment was scrubbed... Name: act-disksignature-1022149.patch Type: text/x-patch Size: 3774 bytes Desc: not available URL: From bkearney at redhat.com Fri Oct 3 12:17:50 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 03 Oct 2008 08:17:50 -0400 Subject: [Thincrust-devel] Doco bitrot Message-ID: <48E60D6E.9000303@redhat.com> Looking at the site, I think that some of the doco has bitrotted. Take some time today and send update what is there. If there are new features, new downloads lemme know. Thanks! -- bk From bkearney at redhat.com Fri Oct 3 13:03:36 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 03 Oct 2008 09:03:36 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48E57AF3.7060507@redhat.com> References: <48E57AF3.7060507@redhat.com> Message-ID: <48E61828.6060804@redhat.com> Joey Boggs wrote: > Adds md5/sha256 disk signature support for appliance-creator enabled by > --checksum option > > Still awaiting approval and commit for python-virtinst for virt-image > import verification portions. Is the chunking causing issues? I patched and ran the file, I get this in the xml: [root at localhost resources]# cat git.xml | grep checksum 061a2a9f757acb0035bc3b01ad8756ef 5b0ab929b233e7b1464c112ee265884a49ed8124711b6fdee4cd449d3f69fc71 [root at localhost resources]# Verifying from the command line, I get this: [bkearney at localhost resources]$ md5sum git-sda.raw b57f316acd9c6859bfc52bcfa2ef9ffa git-sda.raw [bkearney at localhost resources]$ sha256sum git-sda.raw 9d79dc14e0e3d2d797ed118b96948226f056c8bf0ff4ac758f40b672ad14bfee git-sda.raw [bkearney at localhost resources]$ They do not match. Also.. I am sure you covered this earlier.. why do both? -- bk From jboggs at redhat.com Fri Oct 3 13:13:24 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 03 Oct 2008 09:13:24 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48E61828.6060804@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> Message-ID: <48E61A74.9020306@redhat.com> Bryan Kearney wrote: > Joey Boggs wrote: >> Adds md5/sha256 disk signature support for appliance-creator enabled >> by --checksum option >> >> Still awaiting approval and commit for python-virtinst for virt-image >> import verification portions. > you'll have to run md5sum and sha256sum in binary mode add the -b option and they will match. Both formats were added to ensure a higher level of verifications where available (sha256) using hashlib which is only in python 2.5. More details on et-mgmt-tools list. > > Is the chunking causing issues? I patched and ran the file, I get this > in the xml: > > [root at localhost resources]# cat git.xml | grep checksum > 061a2a9f757acb0035bc3b01ad8756ef > type="sha256">5b0ab929b233e7b1464c112ee265884a49ed8124711b6fdee4cd449d3f69fc71 > > [root at localhost resources]# > > > Verifying from the command line, I get this: > > [bkearney at localhost resources]$ md5sum git-sda.raw > b57f316acd9c6859bfc52bcfa2ef9ffa git-sda.raw > [bkearney at localhost resources]$ sha256sum git-sda.raw > 9d79dc14e0e3d2d797ed118b96948226f056c8bf0ff4ac758f40b672ad14bfee > git-sda.raw > [bkearney at localhost resources]$ > > > They do not match. Also.. I am sure you covered this earlier.. why do > both? > > -- bk > > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From bkearney at redhat.com Fri Oct 3 13:11:57 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 03 Oct 2008 09:11:57 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48E61A74.9020306@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> Message-ID: <48E61A1D.7010707@redhat.com> Joey Boggs wrote: > Bryan Kearney wrote: >> Joey Boggs wrote: >>> Adds md5/sha256 disk signature support for appliance-creator enabled >>> by --checksum option >>> >>> Still awaiting approval and commit for python-virtinst for virt-image >>> import verification portions. >> > > > you'll have to run md5sum and sha256sum in binary mode add the -b option > and they will match. Seems to not matter for me: [bkearney at localhost resources]$ md5sum -b git-sda.raw b57f316acd9c6859bfc52bcfa2ef9ffa *git-sda.raw [bkearney at localhost resources]$ md5sum git-sda.raw b57f316acd9c6859bfc52bcfa2ef9ffa git-sda.raw [bkearney at localhost resources]$ > > Both formats were added to ensure a higher level of verifications where > available (sha256) using hashlib which is only in python 2.5. More > details on et-mgmt-tools list. > Ok.. sounds good. -- bk From jboggs at redhat.com Fri Oct 3 13:23:29 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 03 Oct 2008 09:23:29 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48E61A74.9020306@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> Message-ID: <48E61CD1.3050005@redhat.com> Think you found a bug :) Joey Boggs wrote: > Bryan Kearney wrote: >> Joey Boggs wrote: >>> Adds md5/sha256 disk signature support for appliance-creator enabled >>> by --checksum option >>> >>> Still awaiting approval and commit for python-virtinst for >>> virt-image import verification portions. >> > > > you'll have to run md5sum and sha256sum in binary mode add the -b > option and they will match. > > Both formats were added to ensure a higher level of verifications > where available (sha256) using hashlib which is only in python 2.5. > More details on et-mgmt-tools list. > >> >> Is the chunking causing issues? I patched and ran the file, I get >> this in the xml: >> >> [root at localhost resources]# cat git.xml | grep checksum >> 061a2a9f757acb0035bc3b01ad8756ef >> > type="sha256">5b0ab929b233e7b1464c112ee265884a49ed8124711b6fdee4cd449d3f69fc71 >> >> [root at localhost resources]# >> >> >> Verifying from the command line, I get this: >> >> [bkearney at localhost resources]$ md5sum git-sda.raw >> b57f316acd9c6859bfc52bcfa2ef9ffa git-sda.raw >> [bkearney at localhost resources]$ sha256sum git-sda.raw >> 9d79dc14e0e3d2d797ed118b96948226f056c8bf0ff4ac758f40b672ad14bfee >> git-sda.raw >> [bkearney at localhost resources]$ >> >> >> They do not match. Also.. I am sure you covered this earlier.. why do >> both? >> >> -- bk >> >> >> _______________________________________________ >> Thincrust-devel mailing list >> Thincrust-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/thincrust-devel > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From bkearney at redhat.com Fri Oct 3 13:22:30 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 03 Oct 2008 09:22:30 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48E61CD1.3050005@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> <48E61CD1.3050005@redhat.com> Message-ID: <48E61C96.90304@redhat.com> Joey Boggs wrote: > Think you found a bug :) My work here is done. --bk From jboggs at redhat.com Fri Oct 3 14:39:37 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 03 Oct 2008 10:39:37 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48E61CD1.3050005@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> <48E61CD1.3050005@redhat.com> Message-ID: <48E62EA9.2030506@redhat.com> I figured it out. The hashlib.$methods() had diskpath inbetween the () new patch attached Joey Boggs wrote: > Think you found a bug :) > > > > Joey Boggs wrote: >> Bryan Kearney wrote: >>> Joey Boggs wrote: >>>> Adds md5/sha256 disk signature support for appliance-creator >>>> enabled by --checksum option >>>> >>>> Still awaiting approval and commit for python-virtinst for >>>> virt-image import verification portions. >>> >> >> >> you'll have to run md5sum and sha256sum in binary mode add the -b >> option and they will match. >> >> Both formats were added to ensure a higher level of verifications >> where available (sha256) using hashlib which is only in python 2.5. >> More details on et-mgmt-tools list. >> >>> >>> Is the chunking causing issues? I patched and ran the file, I get >>> this in the xml: >>> >>> [root at localhost resources]# cat git.xml | grep checksum >>> 061a2a9f757acb0035bc3b01ad8756ef >>> >> type="sha256">5b0ab929b233e7b1464c112ee265884a49ed8124711b6fdee4cd449d3f69fc71 >>> >>> [root at localhost resources]# >>> >>> >>> Verifying from the command line, I get this: >>> >>> [bkearney at localhost resources]$ md5sum git-sda.raw >>> b57f316acd9c6859bfc52bcfa2ef9ffa git-sda.raw >>> [bkearney at localhost resources]$ sha256sum git-sda.raw >>> 9d79dc14e0e3d2d797ed118b96948226f056c8bf0ff4ac758f40b672ad14bfee >>> git-sda.raw >>> [bkearney at localhost resources]$ >>> >>> >>> They do not match. Also.. I am sure you covered this earlier.. why >>> do both? >>> >>> -- bk >>> >>> >>> _______________________________________________ >>> Thincrust-devel mailing list >>> Thincrust-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/thincrust-devel >> >> _______________________________________________ >> Thincrust-devel mailing list >> Thincrust-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/thincrust-devel > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: act-disksignature-10231037.patch Type: text/x-patch Size: 3818 bytes Desc: not available URL: From jboggs at redhat.com Fri Oct 3 15:13:07 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 03 Oct 2008 11:13:07 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48E62EA9.2030506@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> <48E61CD1.3050005@redhat.com> <48E62EA9.2030506@redhat.com> Message-ID: <48E63683.4080805@redhat.com> one more quick edit to remove some debug printouts Joey Boggs wrote: > I figured it out. The hashlib.$methods() had diskpath inbetween the () > > new patch attached > > > > Joey Boggs wrote: >> Think you found a bug :) >> >> >> >> Joey Boggs wrote: >>> Bryan Kearney wrote: >>>> Joey Boggs wrote: >>>>> Adds md5/sha256 disk signature support for appliance-creator >>>>> enabled by --checksum option >>>>> >>>>> Still awaiting approval and commit for python-virtinst for >>>>> virt-image import verification portions. >>>> >>> >>> >>> you'll have to run md5sum and sha256sum in binary mode add the -b >>> option and they will match. >>> >>> Both formats were added to ensure a higher level of verifications >>> where available (sha256) using hashlib which is only in python 2.5. >>> More details on et-mgmt-tools list. >>> >>>> >>>> Is the chunking causing issues? I patched and ran the file, I get >>>> this in the xml: >>>> >>>> [root at localhost resources]# cat git.xml | grep checksum >>>> 061a2a9f757acb0035bc3b01ad8756ef >>>> >>> type="sha256">5b0ab929b233e7b1464c112ee265884a49ed8124711b6fdee4cd449d3f69fc71 >>>> >>>> [root at localhost resources]# >>>> >>>> >>>> Verifying from the command line, I get this: >>>> >>>> [bkearney at localhost resources]$ md5sum git-sda.raw >>>> b57f316acd9c6859bfc52bcfa2ef9ffa git-sda.raw >>>> [bkearney at localhost resources]$ sha256sum git-sda.raw >>>> 9d79dc14e0e3d2d797ed118b96948226f056c8bf0ff4ac758f40b672ad14bfee >>>> git-sda.raw >>>> [bkearney at localhost resources]$ >>>> >>>> >>>> They do not match. Also.. I am sure you covered this earlier.. why >>>> do both? >>>> >>>> -- bk >>>> >>>> >>>> _______________________________________________ >>>> Thincrust-devel mailing list >>>> Thincrust-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/thincrust-devel >>> >>> _______________________________________________ >>> Thincrust-devel mailing list >>> Thincrust-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/thincrust-devel >> >> _______________________________________________ >> Thincrust-devel mailing list >> Thincrust-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/thincrust-devel > > ------------------------------------------------------------------------ > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: act-disksignature-10231103.patch Type: text/x-patch Size: 3721 bytes Desc: not available URL: From jboggs at redhat.com Fri Oct 3 15:42:56 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 03 Oct 2008 11:42:56 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48E63683.4080805@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> <48E61CD1.3050005@redhat.com> <48E62EA9.2030506@redhat.com> <48E63683.4080805@redhat.com> Message-ID: <48E63D80.3060603@redhat.com> Hold off on committing this, so we can match up with what goes into python-virtinst and maintain uniformity. Joey Boggs wrote: > one more quick edit to remove some debug printouts > > Joey Boggs wrote: >> I figured it out. The hashlib.$methods() had diskpath inbetween the () >> >> new patch attached >> >> >> >> Joey Boggs wrote: >>> Think you found a bug :) >>> >>> >>> >>> Joey Boggs wrote: >>>> Bryan Kearney wrote: >>>>> Joey Boggs wrote: >>>>>> Adds md5/sha256 disk signature support for appliance-creator >>>>>> enabled by --checksum option >>>>>> >>>>>> Still awaiting approval and commit for python-virtinst for >>>>>> virt-image import verification portions. >>>>> >>>> >>>> >>>> you'll have to run md5sum and sha256sum in binary mode add the -b >>>> option and they will match. >>>> >>>> Both formats were added to ensure a higher level of verifications >>>> where available (sha256) using hashlib which is only in python 2.5. >>>> More details on et-mgmt-tools list. >>>> >>>>> >>>>> Is the chunking causing issues? I patched and ran the file, I get >>>>> this in the xml: >>>>> >>>>> [root at localhost resources]# cat git.xml | grep checksum >>>>> 061a2a9f757acb0035bc3b01ad8756ef >>>>> >>>> type="sha256">5b0ab929b233e7b1464c112ee265884a49ed8124711b6fdee4cd449d3f69fc71 >>>>> >>>>> [root at localhost resources]# >>>>> >>>>> >>>>> Verifying from the command line, I get this: >>>>> >>>>> [bkearney at localhost resources]$ md5sum git-sda.raw >>>>> b57f316acd9c6859bfc52bcfa2ef9ffa git-sda.raw >>>>> [bkearney at localhost resources]$ sha256sum git-sda.raw >>>>> 9d79dc14e0e3d2d797ed118b96948226f056c8bf0ff4ac758f40b672ad14bfee >>>>> git-sda.raw >>>>> [bkearney at localhost resources]$ >>>>> >>>>> >>>>> They do not match. Also.. I am sure you covered this earlier.. why >>>>> do both? >>>>> >>>>> -- bk >>>>> >>>>> >>>>> _______________________________________________ >>>>> Thincrust-devel mailing list >>>>> Thincrust-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/thincrust-devel >>>> >>>> _______________________________________________ >>>> Thincrust-devel mailing list >>>> Thincrust-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/thincrust-devel >>> >>> _______________________________________________ >>> Thincrust-devel mailing list >>> Thincrust-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/thincrust-devel >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Thincrust-devel mailing list >> Thincrust-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/thincrust-devel > > ------------------------------------------------------------------------ > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From dhuff at redhat.com Fri Oct 3 20:27:26 2008 From: dhuff at redhat.com (David Huff) Date: Fri, 03 Oct 2008 16:27:26 -0400 Subject: [Thincrust-devel] Doco bitrot In-Reply-To: <48E60D6E.9000303@redhat.com> References: <48E60D6E.9000303@redhat.com> Message-ID: <48E6802E.9070902@redhat.com> Bryan Kearney wrote: > Looking at the site, I think that some of the doco has bitrotted. Take > some time today and send update what is there. If there are new > features, new downloads lemme know. > > Thanks! > > -- bk > I updated some of the pages to make sure they are current. There is still one page that is outdated: http://thincrust.net/docs-steps.html This can either be removed or changed to describe something useful perhaps how to build the ace form source? to build act form source its just checkout an run make. I will think about it over the weekend, currently my brain hurts, and im thirsty. -D From bkearney at redhat.com Mon Oct 6 14:36:43 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 06 Oct 2008 10:36:43 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48E62EA9.2030506@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> <48E61CD1.3050005@redhat.com> <48E62EA9.2030506@redhat.com> Message-ID: <48EA227B.5050102@redhat.com> Joey Boggs wrote: > I figured it out. The hashlib.$methods() had diskpath inbetween the () > > new patch attached Just checking.. what is the plan for this relative to virt-image and virt-convert? -- bk From jboggs at redhat.com Mon Oct 6 15:23:19 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 06 Oct 2008 11:23:19 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48EA227B.5050102@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> <48E61CD1.3050005@redhat.com> <48E62EA9.2030506@redhat.com> <48EA227B.5050102@redhat.com> Message-ID: <48EA2D67.6070502@redhat.com> It will be consistent with virt-image/virt-convert. I'm working with Cole to make sure the solution is well thought out before we just piece it together. The current patch should be ignored. Bryan Kearney wrote: > Joey Boggs wrote: >> I figured it out. The hashlib.$methods() had diskpath inbetween the () >> >> new patch attached > > Just checking.. what is the plan for this relative to virt-image and > virt-convert? > > -- bk > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From bkearney at redhat.com Mon Oct 6 19:45:43 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 06 Oct 2008 15:45:43 -0400 Subject: [Thincrust-devel] Doco bitrot In-Reply-To: <48E6802E.9070902@redhat.com> References: <48E60D6E.9000303@redhat.com> <48E6802E.9070902@redhat.com> Message-ID: <48EA6AE7.4060407@redhat.com> David Huff wrote: > Bryan Kearney wrote: >> Looking at the site, I think that some of the doco has bitrotted. Take >> some time today and send update what is there. If there are new >> features, new downloads lemme know. >> >> Thanks! >> >> -- bk >> > > > I updated some of the pages to make sure they are current. There is > still one page that is outdated: > > http://thincrust.net/docs-steps.html > > This can either be removed or changed to describe something useful > perhaps how to build the ace form source? to build act form source its > just checkout an run make. > > I will think about it over the weekend, currently my brain hurts, and im > thirsty. Take a look now. I removed the page you suggested, updated information about the management console and the ec2 conversion process. Joey, can you work through some scenarios of using the conversion tools? Some real examples (download here, run this) would be great. -- bk From jboggs at redhat.com Mon Oct 6 20:22:04 2008 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 06 Oct 2008 16:22:04 -0400 Subject: [Thincrust-devel] Doco bitrot In-Reply-To: <48EA6AE7.4060407@redhat.com> References: <48E60D6E.9000303@redhat.com> <48E6802E.9070902@redhat.com> <48EA6AE7.4060407@redhat.com> Message-ID: <48EA736C.5080503@redhat.com> Bryan Kearney wrote: > David Huff wrote: >> Bryan Kearney wrote: >>> Looking at the site, I think that some of the doco has bitrotted. >>> Take some time today and send update what is there. If there are new >>> features, new downloads lemme know. >>> >>> Thanks! >>> >>> -- bk >>> >> >> >> I updated some of the pages to make sure they are current. There is >> still one page that is outdated: >> >> http://thincrust.net/docs-steps.html >> >> This can either be removed or changed to describe something useful >> perhaps how to build the ace form source? to build act form source >> its just checkout an run make. >> >> I will think about it over the weekend, currently my brain hurts, and >> im thirsty. > > > Take a look now. I removed the page you suggested, updated information > about the management console and the ec2 conversion process. > > > Joey, can you work through some scenarios of using the conversion > tools? Some real examples (download here, run this) would be great. > > -- bk > Yeah no problem. I've tried using the jumpbox ones as an example but the disk images are split into 2GB sections so we will need to add in something to rejoin them. I'm still researching this part. > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From bkearney at redhat.com Mon Oct 6 20:20:43 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 06 Oct 2008 16:20:43 -0400 Subject: [Thincrust-devel] Doco bitrot In-Reply-To: <48EA736C.5080503@redhat.com> References: <48E60D6E.9000303@redhat.com> <48E6802E.9070902@redhat.com> <48EA6AE7.4060407@redhat.com> <48EA736C.5080503@redhat.com> Message-ID: <48EA731B.4010000@redhat.com> Joey Boggs wrote: > Bryan Kearney wrote: >> David Huff wrote: >>> Bryan Kearney wrote: >>>> Looking at the site, I think that some of the doco has bitrotted. >>>> Take some time today and send update what is there. If there are new >>>> features, new downloads lemme know. >>>> >>>> Thanks! >>>> >>>> -- bk >>>> >>> >>> >>> I updated some of the pages to make sure they are current. There is >>> still one page that is outdated: >>> >>> http://thincrust.net/docs-steps.html >>> >>> This can either be removed or changed to describe something useful >>> perhaps how to build the ace form source? to build act form source >>> its just checkout an run make. >>> >>> I will think about it over the weekend, currently my brain hurts, and >>> im thirsty. >> >> >> Take a look now. I removed the page you suggested, updated information >> about the management console and the ec2 conversion process. >> >> >> Joey, can you work through some scenarios of using the conversion >> tools? Some real examples (download here, run this) would be great. >> >> -- bk >> > Yeah no problem. I've tried using the jumpbox ones as an example but the > disk images are split into 2GB sections so we will need to add in > something to rejoin them. I'm still researching this part. Great... I think this is a valuable next step. Look at the appliance bundles available today, and how we would launch them using virt-image. Any gap is a requirement we need to fill. -- bk From bkearney at redhat.com Tue Oct 7 19:59:50 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 07 Oct 2008 15:59:50 -0400 Subject: [Thincrust-devel] Testing out the virt-convert stuff Message-ID: <48EBBFB6.7090502@redhat.com> Joey: Can you do me a favor.. can you check out this link: http://www.rpath.org/rbuilder/project/lamp/release?id=5922 And dlownload the VMWare Player image. I ran it through virt-convert with the following commands: virt-convert -i vmx -o virt-image lamp-1.3.2-x86.vmx lamp3.xml and it ran fine (minor space issues in the virt-image xml). When I launch it the image is not seeing eth0. Any ideas why? BTW.. what is the difference between the ESX and regular image? -- bk From jboggs at redhat.com Tue Oct 7 20:53:05 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 07 Oct 2008 16:53:05 -0400 Subject: [Thincrust-devel] Testing out the virt-convert stuff In-Reply-To: <48EBBFB6.7090502@redhat.com> References: <48EBBFB6.7090502@redhat.com> Message-ID: <48EBCC31.1060507@redhat.com> The kernel modules for the default realtek nic are not included in the rbuilder image. Is there a way to specify in virt-image to specify a nic model that will pass though to qemu/kvm? Bryan Kearney wrote: > Joey: > > Can you do me a favor.. can you check out this link: > > http://www.rpath.org/rbuilder/project/lamp/release?id=5922 > > > And dlownload the VMWare Player image. I ran it through virt-convert > with the following commands: > > virt-convert -i vmx -o virt-image lamp-1.3.2-x86.vmx lamp3.xml > > > and it ran fine (minor space issues in the virt-image xml). When I > launch it the image is not seeing eth0. Any ideas why? > > BTW.. what is the difference between the ESX and regular image? > > -- bk > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From bkearney at redhat.com Wed Oct 8 12:55:25 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 08 Oct 2008 08:55:25 -0400 Subject: [Thincrust-devel] Testing out the virt-convert stuff In-Reply-To: <48EBCC31.1060507@redhat.com> References: <48EBBFB6.7090502@redhat.com> <48EBCC31.1060507@redhat.com> Message-ID: <48ECADBD.9040308@redhat.com> Joey Boggs wrote: > The kernel modules for the default realtek nic are not included in the > rbuilder image. Is there a way to specify in virt-image to specify a nic > model that will pass though to qemu/kvm? In the current virt-image.xml rng file, there is no way to do that. In the standard libvirt model: http://libvirt.org/formatnetwork.html You can pass in alot more information. What modules are present in the build? I was able to run the raw (qemu) based image with not issues. -- bk From jboggs at redhat.com Wed Oct 8 13:40:33 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 08 Oct 2008 09:40:33 -0400 Subject: [Thincrust-devel] Testing out the virt-convert stuff In-Reply-To: <48ECADBD.9040308@redhat.com> References: <48EBBFB6.7090502@redhat.com> <48EBCC31.1060507@redhat.com> <48ECADBD.9040308@redhat.com> Message-ID: <48ECB851.3090507@redhat.com> The only module even there is the pcnet32 one which is an available module within qemu/kvm and is the one VMware emulates. Forgot the answer your other question, the difference in the ESX format is in the disk format Bryan Kearney wrote: > Joey Boggs wrote: >> The kernel modules for the default realtek nic are not included in >> the rbuilder image. Is there a way to specify in virt-image to >> specify a nic model that will pass though to qemu/kvm? > > In the current virt-image.xml rng file, there is no way to do that. In > the standard libvirt model: > > http://libvirt.org/formatnetwork.html > > You can pass in alot more information. What modules are present in the > build? I was able to run the raw (qemu) based image with not issues. > > -- bk > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From apevec at redhat.com Wed Oct 8 15:50:20 2008 From: apevec at redhat.com (Alan Pevec) Date: Wed, 8 Oct 2008 17:50:20 +0200 Subject: [Thincrust-devel] [PATCH] support patterns in directory names Message-ID: <1223481020-12188-1-git-send-email-apevec@redhat.com> e.g. drop /lib/modules/*/kernel/fs/nls Signed-off-by: Alan Pevec --- tools/image-minimizer | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/image-minimizer b/tools/image-minimizer index 276f252..61e1c32 100755 --- a/tools/image-minimizer +++ b/tools/image-minimizer @@ -47,10 +47,12 @@ class ImageMinimizer: files.add(os.path.join(root, name)) def add_pattern(self, files, pattern): - if os.path.isdir(pattern): - self.add_directory(files, pattern) - else: - files.update(glob.glob(pattern)) + globs = glob.glob(pattern) + for g in globs: + if os.path.isdir(g): + self.add_directory(files, g) + else: + files.add(g) # Parses each line in the ifle def parse_line(self, line): -- 1.5.5.1 From bkearney at redhat.com Wed Oct 8 18:30:45 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 08 Oct 2008 14:30:45 -0400 Subject: [Thincrust-devel] Controlling the output name of ec2-converter Message-ID: <48ECFC55.3060409@redhat.com> Joey: I am looking at scripting the ks -> ec2 process. Can you look to adding the ability to control the output name of the ec2 process? Some command line tool which allows me to override the timestamp would be great. Thanks! -- bk From dhuff at redhat.com Wed Oct 8 18:50:28 2008 From: dhuff at redhat.com (David Huff) Date: Wed, 08 Oct 2008 14:50:28 -0400 Subject: [Thincrust-devel] [PATCH] support patterns in directory names In-Reply-To: <1223481020-12188-1-git-send-email-apevec@redhat.com> References: <1223481020-12188-1-git-send-email-apevec@redhat.com> Message-ID: <48ED00F4.2000308@redhat.com> Alan Pevec wrote: > e.g. drop /lib/modules/*/kernel/fs/nls > > Signed-off-by: Alan Pevec > --- > tools/image-minimizer | 10 ++++++---- > 1 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/tools/image-minimizer b/tools/image-minimizer > index 276f252..61e1c32 100755 > --- a/tools/image-minimizer > +++ b/tools/image-minimizer > @@ -47,10 +47,12 @@ class ImageMinimizer: > files.add(os.path.join(root, name)) > > def add_pattern(self, files, pattern): > - if os.path.isdir(pattern): > - self.add_directory(files, pattern) > - else: > - files.update(glob.glob(pattern)) > + globs = glob.glob(pattern) > + for g in globs: > + if os.path.isdir(g): > + self.add_directory(files, g) > + else: > + files.add(g) > > # Parses each line in the ifle > def parse_line(self, line): committed From jboggs at redhat.com Wed Oct 8 22:27:25 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 08 Oct 2008 18:27:25 -0400 Subject: [Thincrust-devel] Controlling the output name of ec2-converter In-Reply-To: <48ECFC55.3060409@redhat.com> References: <48ECFC55.3060409@redhat.com> Message-ID: <48ED33CD.8000600@redhat.com> ec2-converter --imagename? -n IMAGENAME, --imagename=IMAGENAME Name of EC2 AMI image to be created (default based on config name) Setting the imagename overrides the timestamp default name Bryan Kearney wrote: > Joey: > > I am looking at scripting the ks -> ec2 process. Can you look to > adding the ability to control the output name of the ec2 process? Some > command line tool which allows me to override the timestamp would be > great. > > Thanks! > > -- bk > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From bkearney at redhat.com Wed Oct 8 23:00:02 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 08 Oct 2008 19:00:02 -0400 Subject: [Thincrust-devel] Controlling the output name of ec2-converter In-Reply-To: <48ED33CD.8000600@redhat.com> References: <48ECFC55.3060409@redhat.com> <48ED33CD.8000600@redhat.com> Message-ID: <48ED3B72.2020902@redhat.com> Joey Boggs wrote: > ec2-converter --imagename? > > -n IMAGENAME, --imagename=IMAGENAME > Name of EC2 AMI image to be created (default based on config > name) > > > Setting the imagename overrides the timestamp default name Missed it.. sorry. Could you please update the docs for the dumb folks like me. -- bk From jboggs at redhat.com Thu Oct 9 01:33:02 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 08 Oct 2008 21:33:02 -0400 Subject: [Thincrust-devel] Controlling the output name of ec2-converter In-Reply-To: <48ED3B72.2020902@redhat.com> References: <48ECFC55.3060409@redhat.com> <48ED33CD.8000600@redhat.com> <48ED3B72.2020902@redhat.com> Message-ID: <48ED5F4E.7080904@redhat.com> lol yeah no problem, I'm doing too many things at once, I'll get the docs updated asap Bryan Kearney wrote: > Joey Boggs wrote: >> ec2-converter --imagename? >> >> -n IMAGENAME, --imagename=IMAGENAME >> Name of EC2 AMI image to be created (default based on >> config name) >> >> >> Setting the imagename overrides the timestamp default name > > Missed it.. sorry. Could you please update the docs for the dumb folks > like me. > > -- bk > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From bkearney at redhat.com Thu Oct 9 13:05:41 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 09 Oct 2008 09:05:41 -0400 Subject: [Thincrust-devel] New Doco: Debugging and IRC Message-ID: <48EE01A5.2050101@redhat.com> The ovirt guys ran into some issues with creating recipes. I added a page on using the ace parse command to debug the recipes before building the appliance. You can see it here: http://www.thincrust.net/docs-acedebugging.html Also.. we registered a freenode irc channel. Come join #thincrust if you would prefer to talk real time. -- bk From bkearney at redhat.com Thu Oct 9 14:16:23 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 09 Oct 2008 10:16:23 -0400 Subject: [Thincrust-devel] Testing out the virt-convert stuff In-Reply-To: <48ECB851.3090507@redhat.com> References: <48EBBFB6.7090502@redhat.com> <48EBCC31.1060507@redhat.com> <48ECADBD.9040308@redhat.com> <48ECB851.3090507@redhat.com> Message-ID: <48EE1237.30401@redhat.com> Joey Boggs wrote: > The only module even there is the pcnet32 one which is an available > module within qemu/kvm and is the one VMware emulates. Please reach out to the virt guys. Chat with them to understand the best way to solve this. Ideally.. minimizing where we crack the images is he best. -- bk From jboggs at redhat.com Thu Oct 9 14:33:04 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 09 Oct 2008 10:33:04 -0400 Subject: [Thincrust-devel] Testing out the virt-convert stuff In-Reply-To: <48EE1237.30401@redhat.com> References: <48EBBFB6.7090502@redhat.com> <48EBCC31.1060507@redhat.com> <48ECADBD.9040308@redhat.com> <48ECB851.3090507@redhat.com> <48EE1237.30401@redhat.com> Message-ID: <48EE1620.8050003@redhat.com> The fact that there was only one network module was a build decision of that appliance, without knowing ahead what modules are expected to be there we can pick the wrong nic model for any scenario. Having way to specify a model for the virt-image output will definitely be something desirable, or do you see another potential solution? I'll run this by the virt team as well. Bryan Kearney wrote: > Joey Boggs wrote: >> The only module even there is the pcnet32 one which is an available >> module within qemu/kvm and is the one VMware emulates. > > Please reach out to the virt guys. Chat with them to understand the > best way to solve this. Ideally.. minimizing where we crack the images > is he best. > > -- bk > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From bkearney at redhat.com Thu Oct 9 14:58:55 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 09 Oct 2008 10:58:55 -0400 Subject: [Thincrust-devel] RFC On importing raw images Message-ID: <48EE1C2F.7050401@redhat.com> We are starting to look at more interesting use cases around bringing in existing appliances into virt-manager. Joey has some interesting questions about driver, but I wanted to bring up an easier one. Some of public appliances which exist are raw disk images which can easily be booted, but have no virt-image xml file. The user can of course manually create the file, but I think it would be nice to have the tooling help this. I could see one of the following solutions. Can folks pipe in with comments on these or another approach? (1) Create an "interactive" mode for virt-image which prompts the user. (2) Modify virt-image to allow for all data normally the xml to be passed at command line (example, add a --imagefile parameter) (3)Create a simple pre-processor to achieve 1 or 2 above. -- bk From dhuff at redhat.com Thu Oct 9 15:21:49 2008 From: dhuff at redhat.com (David Huff) Date: Thu, 09 Oct 2008 11:21:49 -0400 Subject: [Thincrust-devel] RFC On importing raw images In-Reply-To: <48EE1C2F.7050401@redhat.com> References: <48EE1C2F.7050401@redhat.com> Message-ID: <48EE218D.9070106@redhat.com> Bryan Kearney wrote: > We are starting to look at more interesting use cases around bringing in > existing appliances into virt-manager. Joey has some interesting > questions about driver, but I wanted to bring up an easier one. > > Some of public appliances which exist are raw disk images which can > easily be booted, but have no virt-image xml file. The user can of > course manually create the file, but I think it would be nice to have > the tooling help this. I could see one of the following solutions. Can > folks pipe in with comments on these or another approach? > > > (1) Create an "interactive" mode for virt-image which prompts the user. Doesn't virt install already have a kindaof an interactive mode for creating a new image? > (2) Modify virt-image to allow for all data normally the xml to be > passed at command line (example, add a --imagefile parameter) > (3)Create a simple pre-processor to achieve 1 or 2 above. > > > -- bk > > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From jboggs at redhat.com Thu Oct 9 15:51:39 2008 From: jboggs at redhat.com (Joey Boggs) Date: Thu, 09 Oct 2008 11:51:39 -0400 Subject: [Thincrust-devel] RFC On importing raw images In-Reply-To: <48EE218D.9070106@redhat.com> References: <48EE1C2F.7050401@redhat.com> <48EE218D.9070106@redhat.com> Message-ID: <48EE288B.8030608@redhat.com> David Huff wrote: > Bryan Kearney wrote: >> We are starting to look at more interesting use cases around bringing >> in existing appliances into virt-manager. Joey has some interesting >> questions about driver, but I wanted to bring up an easier one. >> >> Some of public appliances which exist are raw disk images which can >> easily be booted, but have no virt-image xml file. The user can of >> course manually create the file, but I think it would be nice to have >> the tooling help this. I could see one of the following solutions. >> Can folks pipe in with comments on these or another approach? >> >> >> (1) Create an "interactive" mode for virt-image which prompts the user. > Doesn't virt install already have a kindaof an interactive mode for > creating a new image? I think Bryan's hinting at a way to import just an imagefile and the interactive portion fills in the blanks about the memory/etc >> (2) Modify virt-image to allow for all data normally the xml to be >> passed at command line (example, add a --imagefile parameter) >> (3)Create a simple pre-processor to achieve 1 or 2 above. >> >> >> -- bk >> >> >> _______________________________________________ >> Thincrust-devel mailing list >> Thincrust-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/thincrust-devel > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From bkearney at redhat.com Fri Oct 10 11:53:27 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 10 Oct 2008 07:53:27 -0400 Subject: [Thincrust-devel] Testing out the virt-convert stuff In-Reply-To: <48EE1620.8050003@redhat.com> References: <48EBBFB6.7090502@redhat.com> <48EBCC31.1060507@redhat.com> <48ECADBD.9040308@redhat.com> <48ECB851.3090507@redhat.com> <48EE1237.30401@redhat.com> <48EE1620.8050003@redhat.com> Message-ID: <48EF4237.4020607@redhat.com> Joey Boggs wrote: > The fact that there was only one network module was a build decision of > that appliance, without knowing ahead what modules are expected to be > there we can pick the wrong nic model for any scenario. Having way to > specify a model for the virt-image output will definitely be something > desirable, or do you see another potential solution? I'll run this by > the virt team as well. Ideally.. the appliance itself would do this. Do me a favor.. post this out ot the virt list and get some input. -- bk From jboggs at redhat.com Fri Oct 10 14:01:21 2008 From: jboggs at redhat.com (Joey Boggs) Date: Fri, 10 Oct 2008 10:01:21 -0400 Subject: [Thincrust-devel] Testing out the virt-convert stuff In-Reply-To: <48EF4237.4020607@redhat.com> References: <48EBBFB6.7090502@redhat.com> <48EBCC31.1060507@redhat.com> <48ECADBD.9040308@redhat.com> <48ECB851.3090507@redhat.com> <48EE1237.30401@redhat.com> <48EE1620.8050003@redhat.com> <48EF4237.4020607@redhat.com> Message-ID: <48EF6031.3030802@redhat.com> Bryan Kearney wrote: > Joey Boggs wrote: >> The fact that there was only one network module was a build decision >> of that appliance, without knowing ahead what modules are expected to >> be there we can pick the wrong nic model for any scenario. Having way >> to specify a model for the virt-image output will definitely be >> something desirable, or do you see another potential solution? I'll >> run this by the virt team as well. > What exactly should the appliance do? I'm not following > Ideally.. the appliance itself would do this. Do me a favor.. post > this out ot the virt list and get some input. > > -- bk > > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From dhuff at redhat.com Fri Oct 10 21:40:02 2008 From: dhuff at redhat.com (David Huff) Date: Fri, 10 Oct 2008 17:40:02 -0400 Subject: [Thincrust-devel] [PATCH] fixed problem with long move operations (#466278) Message-ID: <1223674802-21751-1-git-send-email-dhuff@redhat.com> --- appcreate/appliance.py | 56 ++++++++++++++++++++++++++++------------------ tools/appliance-creator | 9 ++++++- 2 files changed, 41 insertions(+), 24 deletions(-) diff --git a/appcreate/appliance.py b/appcreate/appliance.py index 054c69a..c3af120 100644 --- a/appcreate/appliance.py +++ b/appcreate/appliance.py @@ -332,22 +332,10 @@ class ApplianceImageCreator(ImageCreator): if rc != 0: raise CreatorError("Unable to convert disk to %s" % self.__format) - def _package_image(self): - #package image and metadata - if self.__package == "zip": - #dst = "%s/%s.zip" % (self.__imgdir, self.name) tmp dir - dst = "%s/%s.zip" % (self._outdir, self.name) - files = glob.glob('%s/*' % self.__imgdir) - logging.debug("creating %s" % (dst)) - z = zipfile.ZipFile(dst, "w", compression=8, allowZip64="True") - for file in files: - if file != dst: - logging.debug("adding %s to %s" % (file,dst)) - z.write(file, arcname=os.path.basename(file), compress_type=None) - z.close() - def _stage_final_image(self): + """Stage the final system image in _outdir. + """ self._resparse() self._write_image_xml() @@ -358,16 +346,40 @@ class ApplianceImageCreator(ImageCreator): #else if self.__format != "raw": self._convert_image() + + if self.__package == "zip": + dst = "%s/%s.zip" % (self._outdir, self.name) + files = glob.glob('%s/*' % self.__imgdir) + logging.debug("creating %s" % (dst)) + z = zipfile.ZipFile(dst, "w", compression=8, allowZip64="True") + for file in files: + if file != dst: + logging.debug("adding %s to %s" % (file,dst)) + z.write(file, arcname=os.path.basename(file), compress_type=None) + z.close() + if self.__package == "none": logging.debug("moving disks to final location") for files in glob.glob('%s/*' % self.__imgdir): - logging.debug("moving %s to %s" % (files, self._outdir)) - shutil.move(files, self._outdir) - else: - self._package_image() - - print("done") - - + logging.debug("moving %s to %s/%s" % (files, self._outdir, os.path.basename(files))) + try: + os.rename(files, '%s/%s' % (self._outdir, os.path.basename(files))) + except Exception, e: + shutil.move(files, '%s/%s' % (self._outdir, os.path.basename(files))) + + def package(self, destdir): + """Prepares the created image for final delivery. + """ + self._stage_final_image() + + for f in os.listdir(self._outdir): + try: + os.rename(os.path.join(self._outdir, f), + os.path.join(destdir, f)) + except Exception, e: + shutil.move(os.path.join(self._outdir, f), + os.path.join(destdir, f)) + + print "Finished" diff --git a/tools/appliance-creator b/tools/appliance-creator index 6d990de..805771f 100755 --- a/tools/appliance-creator +++ b/tools/appliance-creator @@ -99,7 +99,12 @@ def main(): name = imgcreate.build_name(options.kscfg) if options.name: - name = options.name + if os.path.dirname(options.name): + destdir=os.path.dirname(options.name) + name=os.path.basename(options.name) + else: + name = options.name + destdir = "." creator = appcreate.ApplianceImageCreator(ks, name, options.format, options.package, options.vmem, options.vcpu) creator.tmpdir = options.tmpdir @@ -109,7 +114,7 @@ def main(): creator.install() creator.configure() creator.unmount() - creator.package() + creator.package(destdir) except imgcreate.CreatorError, e: logging.error("Unable to create appliance : %s" % e) return 1 -- 1.5.5.1 From dhuff at redhat.com Fri Oct 10 21:42:50 2008 From: dhuff at redhat.com (David Huff) Date: Fri, 10 Oct 2008 17:42:50 -0400 Subject: [Thincrust-devel] Re: [PATCH] fixed problem with long move operations (#466278) In-Reply-To: <1223674802-21751-1-git-send-email-dhuff@redhat.com> References: <1223674802-21751-1-git-send-email-dhuff@redhat.com> Message-ID: <48EFCC5A.2070507@redhat.com> committed... this also addes the ability of using a full path of in the appliance name as final destination, which helps w/ scripting. ie --name /home/david/appliances/aos-f9-test2 will name the appliance aos-f9-test2 however all output will be in /home/david/appliances/ -D David Huff wrote: > --- > appcreate/appliance.py | 56 ++++++++++++++++++++++++++++------------------ > tools/appliance-creator | 9 ++++++- > 2 files changed, 41 insertions(+), 24 deletions(-) > > diff --git a/appcreate/appliance.py b/appcreate/appliance.py > index 054c69a..c3af120 100644 > --- a/appcreate/appliance.py > +++ b/appcreate/appliance.py > @@ -332,22 +332,10 @@ class ApplianceImageCreator(ImageCreator): > if rc != 0: > raise CreatorError("Unable to convert disk to %s" % self.__format) > > - def _package_image(self): > - #package image and metadata > - if self.__package == "zip": > - #dst = "%s/%s.zip" % (self.__imgdir, self.name) tmp dir > - dst = "%s/%s.zip" % (self._outdir, self.name) > - files = glob.glob('%s/*' % self.__imgdir) > - logging.debug("creating %s" % (dst)) > - z = zipfile.ZipFile(dst, "w", compression=8, allowZip64="True") > - for file in files: > - if file != dst: > - logging.debug("adding %s to %s" % (file,dst)) > - z.write(file, arcname=os.path.basename(file), compress_type=None) > - z.close() > - > > def _stage_final_image(self): > + """Stage the final system image in _outdir. > + """ > self._resparse() > self._write_image_xml() > > @@ -358,16 +346,40 @@ class ApplianceImageCreator(ImageCreator): > #else > if self.__format != "raw": > self._convert_image() > + > + if self.__package == "zip": > + dst = "%s/%s.zip" % (self._outdir, self.name) > + files = glob.glob('%s/*' % self.__imgdir) > + logging.debug("creating %s" % (dst)) > + z = zipfile.ZipFile(dst, "w", compression=8, allowZip64="True") > + for file in files: > + if file != dst: > + logging.debug("adding %s to %s" % (file,dst)) > + z.write(file, arcname=os.path.basename(file), compress_type=None) > + z.close() > + > if self.__package == "none": > logging.debug("moving disks to final location") > for files in glob.glob('%s/*' % self.__imgdir): > - logging.debug("moving %s to %s" % (files, self._outdir)) > - shutil.move(files, self._outdir) > - else: > - self._package_image() > - > - print("done") > - > - > + logging.debug("moving %s to %s/%s" % (files, self._outdir, os.path.basename(files))) > + try: > + os.rename(files, '%s/%s' % (self._outdir, os.path.basename(files))) > + except Exception, e: > + shutil.move(files, '%s/%s' % (self._outdir, os.path.basename(files))) > + > > > + def package(self, destdir): > + """Prepares the created image for final delivery. > + """ > + self._stage_final_image() > + > + for f in os.listdir(self._outdir): > + try: > + os.rename(os.path.join(self._outdir, f), > + os.path.join(destdir, f)) > + except Exception, e: > + shutil.move(os.path.join(self._outdir, f), > + os.path.join(destdir, f)) > + > + print "Finished" > diff --git a/tools/appliance-creator b/tools/appliance-creator > index 6d990de..805771f 100755 > --- a/tools/appliance-creator > +++ b/tools/appliance-creator > @@ -99,7 +99,12 @@ def main(): > > name = imgcreate.build_name(options.kscfg) > if options.name: > - name = options.name > + if os.path.dirname(options.name): > + destdir=os.path.dirname(options.name) > + name=os.path.basename(options.name) > + else: > + name = options.name > + destdir = "." > > creator = appcreate.ApplianceImageCreator(ks, name, options.format, options.package, options.vmem, options.vcpu) > creator.tmpdir = options.tmpdir > @@ -109,7 +114,7 @@ def main(): > creator.install() > creator.configure() > creator.unmount() > - creator.package() > + creator.package(destdir) > except imgcreate.CreatorError, e: > logging.error("Unable to create appliance : %s" % e) > return 1 From bkearney at redhat.com Mon Oct 13 15:37:09 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 13 Oct 2008 11:37:09 -0400 Subject: [Thincrust-devel] Testing out the virt-convert stuff In-Reply-To: <48EF6031.3030802@redhat.com> References: <48EBBFB6.7090502@redhat.com> <48EBCC31.1060507@redhat.com> <48ECADBD.9040308@redhat.com> <48ECB851.3090507@redhat.com> <48EE1237.30401@redhat.com> <48EE1620.8050003@redhat.com> <48EF4237.4020607@redhat.com> <48EF6031.3030802@redhat.com> Message-ID: <48F36B25.4000800@redhat.com> Joey Boggs wrote: > Bryan Kearney wrote: >> Joey Boggs wrote: >>> The fact that there was only one network module was a build decision >>> of that appliance, without knowing ahead what modules are expected to >>> be there we can pick the wrong nic model for any scenario. Having way >>> to specify a model for the virt-image output will definitely be >>> something desirable, or do you see another potential solution? I'll >>> run this by the virt team as well. >> > What exactly should the appliance do? I'm not following The dump answer is "just work". I downloaded the raw/qemu image and was able to import it. I was not able to with the VMWare. I believe a very compelling story is to take an existing VMWare image and import/convert it into a libvirt environment. -- bk From dhuff at redhat.com Mon Oct 13 19:03:53 2008 From: dhuff at redhat.com (David Huff) Date: Mon, 13 Oct 2008 15:03:53 -0400 Subject: [Thincrust-devel] [Fwd: [Fedora Update] [new] appliance-tools-002-4.fc9] Message-ID: <48F39B99.4000706@redhat.com> huff has submitted a new update for Fedora 9 ================================================================================ appliance-tools-002-4.fc9 ================================================================================ Release: Fedora 9 Status: pending Type: bugfix Karma: 0 Notes: * Mon Oct 13 2008 David Huff 002-4 - fix for : problem with long move operations (#466278) - support : patterns in directory names (apevec) - fix exit upon : error when converting disk formats (#464798) Submitter: huff Submitted: 2008-10-13 19:01:03 http://admin.fedoraproject.org/updates/appliance-tools-002-4.fc9 From pmyers at redhat.com Tue Oct 14 02:13:50 2008 From: pmyers at redhat.com (Perry Myers) Date: Mon, 13 Oct 2008 22:13:50 -0400 Subject: [Thincrust-devel] ovirt appliance ace Message-ID: <48F4005E.1060200@redhat.com> The ovirt appliance uses an ace recipe (Bryan helped is get this set up) It is working ok, but I've one question... /etc/init.d/ace runs on firstboot of the appliance and configures the appliance correctly. At this point shouldn't the ace init.d be chkconfig'd off? What I'm seeing is that on -every- boot of the appliance the ace init.d script runs and 'updates the appliance' which takes some time. I would think that an appliance update should on occur if the recipe has been updated. Thoughts? Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From bkearney at redhat.com Tue Oct 14 12:32:01 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Oct 2008 08:32:01 -0400 Subject: [Thincrust-devel] ovirt appliance ace In-Reply-To: <48F4005E.1060200@redhat.com> References: <48F4005E.1060200@redhat.com> Message-ID: <48F49141.90700@redhat.com> Perry Myers wrote: > The ovirt appliance uses an ace recipe (Bryan helped is get this set up) > It is working ok, but I've one question... > > /etc/init.d/ace runs on firstboot of the appliance and configures the > appliance correctly. At this point shouldn't the ace init.d be > chkconfig'd off? It does re-run each time to look for changes in the deployement (i.e. new IP address, etc). If one of the steps is a long-running task then there is a single_exec function which we have in the tool to ensure it only runs one time. Do you happen to know which step is taking a while to boot up? -- bk From dhuff at redhat.com Tue Oct 14 14:08:37 2008 From: dhuff at redhat.com (David Huff) Date: Tue, 14 Oct 2008 10:08:37 -0400 Subject: [Thincrust-devel] [Fwd: [Fedora Update] [new] appliance-tools-002-4.fc9] In-Reply-To: <48F39B99.4000706@redhat.com> References: <48F39B99.4000706@redhat.com> Message-ID: <48F4A7E5.4040007@redhat.com> Package: appliance-tools NVR: appliance-tools-002-4.fc9 User: bodhi Status: complete Tag Operation: moved From Tag: dist-f9-updates-candidate Into Tag: dist-f9-updates appliance-tools-002-4.fc9 successfully moved from dist-f9-updates-candidate into dist-f9-updates by bodhi However it looks like it still needs to sync to the mirrors before it is available via yum. David Huff wrote: > huff has submitted a new update for Fedora 9 > > ================================================================================ > > appliance-tools-002-4.fc9 > ================================================================================ > > Release: Fedora 9 > Status: pending > Type: bugfix > Karma: 0 > Notes: * Mon Oct 13 2008 David Huff 002-4 - > fix for > : problem with long move operations (#466278) - support > : patterns in directory names (apevec) - fix exit upon > : error when converting disk formats (#464798) > Submitter: huff > Submitted: 2008-10-13 19:01:03 > > http://admin.fedoraproject.org/updates/appliance-tools-002-4.fc9 > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel From pmyers at redhat.com Tue Oct 14 14:30:29 2008 From: pmyers at redhat.com (Perry Myers) Date: Tue, 14 Oct 2008 10:30:29 -0400 Subject: [Thincrust-devel] ovirt appliance ace In-Reply-To: <48F49141.90700@redhat.com> References: <48F4005E.1060200@redhat.com> <48F49141.90700@redhat.com> Message-ID: <48F4AD05.6010704@redhat.com> Bryan Kearney wrote: > Perry Myers wrote: >> The ovirt appliance uses an ace recipe (Bryan helped is get this set >> up) It is working ok, but I've one question... >> >> /etc/init.d/ace runs on firstboot of the appliance and configures the >> appliance correctly. At this point shouldn't the ace init.d be >> chkconfig'd off? > > It does re-run each time to look for changes in the deployement (i.e. > new IP address, etc). > > If one of the steps is a long-running task then there is a single_exec > function which we have in the tool to ensure it only runs one time. Do > you happen to know which step is taking a while to boot up? I'll check on this.... The problem with running the refresh on each boot is that the ovirt-server-install script is only meant to be run once I think... If it's running that several times that is going to be problematic. Perry From jboggs at redhat.com Wed Oct 15 15:16:18 2008 From: jboggs at redhat.com (Joey Boggs) Date: Wed, 15 Oct 2008 11:16:18 -0400 Subject: [Thincrust-devel] [patch] f9 branch ec2-converter code Message-ID: <48F60942.6090108@redhat.com> Me and git aren't getting along today, Huff have at it :) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-backported-ec2-converter-to-f9-branch.patch Type: text/x-patch Size: 27288 bytes Desc: not available URL: From dhuff at redhat.com Wed Oct 15 15:20:52 2008 From: dhuff at redhat.com (David Huff) Date: Wed, 15 Oct 2008 11:20:52 -0400 Subject: [Thincrust-devel] [patch] f9 branch ec2-converter code In-Reply-To: <48F60942.6090108@redhat.com> References: <48F60942.6090108@redhat.com> Message-ID: <48F60A54.8050404@redhat.com> Joey Boggs wrote: > Me and git aren't getting along today, Huff have at it :) > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel committed -D From bkearney at redhat.com Thu Oct 16 17:03:47 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 16 Oct 2008 13:03:47 -0400 Subject: [Thincrust-devel] Blog post Message-ID: <48F773F3.9070409@redhat.com> Bob: Thanks for the blog post [1]. Just to let you know, I think the fedora remix mark may be close to approval. Once that is done, we should re-spin your stuff to make it a remix. When you get a chance, can you post your most recent recipe? [1] http://www.fnokd.com/2008/10/16/boot-up-jboss/ From lutter at redhat.com Thu Oct 16 17:10:17 2008 From: lutter at redhat.com (David Lutterkort) Date: Thu, 16 Oct 2008 10:10:17 -0700 Subject: [Thincrust-devel] Re: [et-mgmt-tools] RFC On importing raw images In-Reply-To: <20081009195559.GC2941@redhat.com> References: <48EE1C2F.7050401@redhat.com> <48EE2FF1.3020102@redhat.com> <20081009195559.GC2941@redhat.com> Message-ID: <1224177017.13790.7.camel@localhost.localdomain> On Thu, 2008-10-09 at 20:55 +0100, Daniel P. Berrange wrote: > > - virt-image: no go for libvirt xml, but could be expanded > > to build image xml, and probably the most consistent place > > to do it. > > Yeah, I don't think its applicable for virt-image. virt-image > is really focused on having all the domain metadata upfront > and not prompting the user for it. Wouldn't that be a job for virt-convert ? If the images are so raw that they have _no_ metadata whatsoever, I am not sure that a tool would be any better than a doc describing how to craft image.xml. BTW, virt-image has a --print option which will print the libvirt.xml, so there's at least a way to do image.xml -> libvirt.xml David From bmcwhirt at redhat.com Thu Oct 16 17:24:54 2008 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Thu, 16 Oct 2008 13:24:54 -0400 Subject: [Thincrust-devel] Blog post In-Reply-To: <48F773F3.9070409@redhat.com> References: <48F773F3.9070409@redhat.com> Message-ID: <81EDFB94-39A5-423C-B4FF-BCEB1967FD4C@redhat.com> > Thanks for the blog post [1]. Just to let you know, I think the > fedora remix mark may be close to approval. Once that is done, we > should re-spin your stuff to make it a remix. Sounds good. That's just an extra Fedora mark useful for custom Fedora-based spins? > When you get a chance, can you post your most recent recipe? Sure thing. The interesting bits are scattered about, but here's the .spec and .ks http://github.com/bobmcwhirter/thincrust-ace/tree/master/specs/jboxx5_appliance.spec http://github.com/bobmcwhirter/thincrust-ace/tree/master/resources/jboxx5Appliance-f9.ks And my offensive jbossas.rpm: http://github.com/bobmcwhirter/jboss-rpm/tree/master/specs/jbossas.spec Ultimately, I forsee multiple spins of jboxx appliances (and some non- jboxx appliances) when used in production. A simple spin for AS-as-it- ships, but others for running cluster nodes, or web front-ends, or DB, etc. I've obviously just git-forked the 'ace' repository, which seems like the suboptimal way to work with it all. But I wasn't sure how much of ACE expected my stuff to be under/relative to ACEHOME. ie, appliance-creator seems to insist on being run within resources/ if it wants to find the splash xpm, etc. Plus, I've noticed both you and myself have .ks with paths on our localhost to repositories. Does kickstart support macros or variables, or is anyone interested in throwing erb or m4 into the mix? -Bob From bkearney at redhat.com Thu Oct 16 18:25:02 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 16 Oct 2008 14:25:02 -0400 Subject: [Thincrust-devel] Blog post In-Reply-To: <81EDFB94-39A5-423C-B4FF-BCEB1967FD4C@redhat.com> References: <48F773F3.9070409@redhat.com> <81EDFB94-39A5-423C-B4FF-BCEB1967FD4C@redhat.com> Message-ID: <48F786FE.7020806@redhat.com> Bob McWhirter wrote: >> Thanks for the blog post [1]. Just to let you know, I think the >> fedora remix mark may be close to approval. Once that is done, we >> should re-spin your stuff to make it a remix. > > Sounds good. That's just an extra Fedora mark useful for custom > Fedora-based spins? > >> When you get a chance, can you post your most recent recipe? > > Sure thing. The interesting bits are scattered about, but here's the > .spec and .ks > > http://github.com/bobmcwhirter/thincrust-ace/tree/master/specs/jboxx5_appliance.spec > > http://github.com/bobmcwhirter/thincrust-ace/tree/master/resources/jboxx5Appliance-f9.ks > > > And my offensive jbossas.rpm: > > http://github.com/bobmcwhirter/jboss-rpm/tree/master/specs/jbossas.spec > > Ultimately, I forsee multiple spins of jboxx appliances (and some > non-jboxx appliances) when used in production. A simple spin for > AS-as-it-ships, but others for running cluster nodes, or web front-ends, > or DB, etc. > > I've obviously just git-forked the 'ace' repository, which seems like > the suboptimal way to work with it all. But I wasn't sure how much of > ACE expected my stuff to be under/relative to ACEHOME. It expects all of it to be there, but we should be able to have you deliver just the jboxxappliance as an RPM and get the rest from fedora. We are working through the packaging of it now. > > ie, appliance-creator seems to insist on being run within resources/ if > it wants to find the splash xpm, etc. Perhaps the better answer is to have an rpm deliver the spash screen and then edit the grub.conf at build time. > > Plus, I've noticed both you and myself have .ks with paths on our > localhost to repositories. Does kickstart support macros or variables, > or is anyone interested in throwing erb or m4 into the mix? Not too many out of the box. We are looking to integrate with cobbler for repo management, and that will bring along cheetah as a template tool. Cobbler may be a bit too heavyweight though. We will need to see. -- bk From jboggs at redhat.com Tue Oct 21 13:47:14 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 21 Oct 2008 09:47:14 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48EA2D67.6070502@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> <48E61CD1.3050005@redhat.com> <48E62EA9.2030506@redhat.com> <48EA227B.5050102@redhat.com> <48EA2D67.6070502@redhat.com> Message-ID: <48FDDD62.1000104@redhat.com> Updated patch, mostly everything is the same, added in the progress bar just like virt-image uses during verification. Generates sha1/sha256 if available and is off by default. appliance-creator --generate-checksum Joey Boggs wrote: > It will be consistent with virt-image/virt-convert. I'm working with > Cole to make sure the solution is well thought out before we just > piece it together. The current patch should be ignored. > > > > > Bryan Kearney wrote: >> Joey Boggs wrote: >>> I figured it out. The hashlib.$methods() had diskpath inbetween >>> the () >>> >>> new patch attached >> >> Just checking.. what is the plan for this relative to virt-image and >> virt-convert? >> >> -- bk >> >> _______________________________________________ >> Thincrust-devel mailing list >> Thincrust-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/thincrust-devel > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: act-disksignature-10210943.patch Type: text/x-patch Size: 4272 bytes Desc: not available URL: From bkearney at redhat.com Tue Oct 21 14:43:33 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 21 Oct 2008 10:43:33 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48FDDD62.1000104@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> <48E61CD1.3050005@redhat.com> <48E62EA9.2030506@redhat.com> <48EA227B.5050102@redhat.com> <48EA2D67.6070502@redhat.com> <48FDDD62.1000104@redhat.com> Message-ID: <48FDEA95.9070404@redhat.com> Couple of nits below. Other then that, ACK. Joey Boggs wrote: > Updated patch, mostly everything is the same, added in the progress bar > just like virt-image uses during verification. Generates sha1/sha256 if > available and is off by default. > > appliance-creator --generate-checksum > diff --git a/appcreate/appliance.py b/appcreate/appliance.py > index 054c69a..4345a9c 100644 > --- a/appcreate/appliance.py > +++ b/appcreate/appliance.py > @@ -29,6 +29,7 @@ from imgcreate.errors import * > from imgcreate.fs import * > from imgcreate.creator import * > from appcreate.partitionedfs import * > +import urlgrabber.progress as progress > > class ApplianceImageCreator(ImageCreator): > """Installs a system into a file containing a partitioned disk image. > @@ -40,7 +41,7 @@ class ApplianceImageCreator(ImageCreator): > > """ > > - def __init__(self, ks, name, format, package, vmem, vcpu): > + def __init__(self, ks, name, format, package, vmem, vcpu, checksum): > """Initialize a ApplianceImageCreator instance. > > This method takes the same arguments as ImageCreator.__init__() > @@ -55,6 +56,7 @@ class ApplianceImageCreator(ImageCreator): > self.__vmem = vmem > self.__vcpu = vcpu > self.__package = package > + self.__checksum = checksum > > > def _get_fstab(self): > @@ -305,8 +307,46 @@ class ApplianceImageCreator(ImageCreator): > xml += " \n" > xml += " \n" > xml += " \n" > - for name in self.__disks.keys(): > - xml += " \n" % (self.name,name, self.__format, self.__format) > + > + if self.__checksum is True: > + for name in self.__disks.keys(): > + diskpath = "%s/%s-%s.%s" % (self.__imgdir,self.name,name, self.__format) > + disk_size = os.path.getsize(diskpath) > + meter_ct = 0 > + meter = progress.TextMeter() > + meter.start(size=disk_size, text="Generating disk signature for %s-%s.%s" % (self.name,name,self.__format)) > + xml += "\n" % (self.name,name, self.__format, self.__format) In this case, the indentation is off. I think the disk and checksums should each go in one more indenteation level. > + > + try: > + import hashlib > + m1 = hashlib.sha1() > + m2 = hashlib.sha256() > + except: > + import sha > + m1 = sha.new() > + m2 = None > + f = open(diskpath,"r") > + while 1: > + chunk = f.read(65536) > + if not chunk: > + break > + m1.update(chunk) > + if m2: > + m2.update(chunk) > + meter.update(meter_ct) > + meter_ct = meter_ct + 65536 > + > + sha1checksum = m1.hexdigest() > + xml += """ %s\n""" % sha1checksum The other tags use a single '. Can you stay consistent. As with above, need to indent one more level. > + > + if m2: > + sha256checksum = m2.hexdigest() > + xml += """ %s\n""" % sha256checksum > + xml += " \n" Same > + else: > + for name in self.__disks.keys(): > + xml += " \n" % (self.name,name, self.__format, self.__format) Indent is good here. > + > xml += " \n" > xml += "\n" > > diff --git a/tools/appliance-creator b/tools/appliance-creator > index 6d990de..1442f89 100755 > --- a/tools/appliance-creator > +++ b/tools/appliance-creator > @@ -47,6 +47,8 @@ def parse_options(args): > help="amount of virtual memory for appliance in MB (default: 512)") > appopt.add_option("", "--vcpu", type="int", dest="vcpu", default=1, > help="number of virtual cpus for appliance (default: 1)") > + appopt.add_option("", "--generate-checksum", action="store_true", dest="checksum", > + help=("Generate a checksum for the created appliance")) > parser.add_option_group(appopt) > > # options related to the config of your system > @@ -101,7 +103,7 @@ def main(): > if options.name: > name = options.name > > - creator = appcreate.ApplianceImageCreator(ks, name, options.format, options.package, options.vmem, options.vcpu) > + creator = appcreate.ApplianceImageCreator(ks, name, options.format, options.package, options.vmem, options.vcpu, options.checksum) > creator.tmpdir = options.tmpdir > > try: > > From jboggs at redhat.com Tue Oct 21 16:44:01 2008 From: jboggs at redhat.com (Joey Boggs) Date: Tue, 21 Oct 2008 12:44:01 -0400 Subject: [Thincrust-devel] [patch] act md5/sha256 disk signature support for appliance-creator In-Reply-To: <48FDEA95.9070404@redhat.com> References: <48E57AF3.7060507@redhat.com> <48E61828.6060804@redhat.com> <48E61A74.9020306@redhat.com> <48E61CD1.3050005@redhat.com> <48E62EA9.2030506@redhat.com> <48EA227B.5050102@redhat.com> <48EA2D67.6070502@redhat.com> <48FDDD62.1000104@redhat.com> <48FDEA95.9070404@redhat.com> Message-ID: <48FE06D1.6000407@redhat.com> Fixed the indents and appliance creator was out of sync causing the patch to fail when applied. Bryan Kearney wrote: > Couple of nits below. Other then that, ACK. > > Joey Boggs wrote: >> Updated patch, mostly everything is the same, added in the progress >> bar just like virt-image uses during verification. Generates >> sha1/sha256 if available and is off by default. >> >> appliance-creator --generate-checksum >> diff --git a/appcreate/appliance.py b/appcreate/appliance.py >> index 054c69a..4345a9c 100644 >> --- a/appcreate/appliance.py >> +++ b/appcreate/appliance.py >> @@ -29,6 +29,7 @@ from imgcreate.errors import * >> from imgcreate.fs import * >> from imgcreate.creator import * >> from appcreate.partitionedfs import * >> +import urlgrabber.progress as progress >> >> class ApplianceImageCreator(ImageCreator): >> """Installs a system into a file containing a partitioned disk >> image. >> @@ -40,7 +41,7 @@ class ApplianceImageCreator(ImageCreator): >> >> """ >> >> - def __init__(self, ks, name, format, package, vmem, vcpu): >> + def __init__(self, ks, name, format, package, vmem, vcpu, >> checksum): >> """Initialize a ApplianceImageCreator instance. >> >> This method takes the same arguments as ImageCreator.__init__() >> @@ -55,6 +56,7 @@ class ApplianceImageCreator(ImageCreator): >> self.__vmem = vmem >> self.__vcpu = vcpu >> self.__package = package >> + self.__checksum = checksum >> >> def _get_fstab(self): >> @@ -305,8 +307,46 @@ class ApplianceImageCreator(ImageCreator): >> xml += " \n" >> xml += " \n" >> xml += " \n" >> - for name in self.__disks.keys(): >> - xml += " > format='%s'/>\n" % (self.name,name, self.__format, self.__format) >> + >> + if self.__checksum is True: >> + for name in self.__disks.keys(): >> + diskpath = "%s/%s-%s.%s" % >> (self.__imgdir,self.name,name, self.__format) >> + disk_size = os.path.getsize(diskpath) >> + meter_ct = 0 + meter = >> progress.TextMeter() >> + meter.start(size=disk_size, text="Generating disk >> signature for %s-%s.%s" % (self.name,name,self.__format)) >> + xml += "> format='%s'>\n" % (self.name,name, self.__format, self.__format) > In this case, the indentation is off. I think the disk and checksums > should each go in one more indenteation level. >> + + try: >> + import hashlib >> + m1 = hashlib.sha1() >> + m2 = hashlib.sha256() >> + except: >> + import sha >> + m1 = sha.new() >> + m2 = None >> + f = open(diskpath,"r") >> + while 1: >> + chunk = f.read(65536) >> + if not chunk: >> + break >> + m1.update(chunk) >> + if m2: >> + m2.update(chunk) >> + meter.update(meter_ct) >> + meter_ct = meter_ct + 65536 >> + >> + sha1checksum = m1.hexdigest() >> + xml += """ > type="sha1">%s\n""" % sha1checksum > The other tags use a single '. Can you stay consistent. As with above, > need to indent one more level. >> + >> + if m2: >> + sha256checksum = m2.hexdigest() >> + xml += """ > type="sha256">%s\n""" % sha256checksum >> + xml += " \n" > Same >> + else: >> + for name in self.__disks.keys(): >> + xml += " > format='%s'/>\n" % (self.name,name, self.__format, self.__format) > Indent is good here. >> + >> xml += " \n" >> xml += "\n" >> >> diff --git a/tools/appliance-creator b/tools/appliance-creator >> index 6d990de..1442f89 100755 >> --- a/tools/appliance-creator >> +++ b/tools/appliance-creator >> @@ -47,6 +47,8 @@ def parse_options(args): >> help="amount of virtual memory for appliance >> in MB (default: 512)") >> appopt.add_option("", "--vcpu", type="int", dest="vcpu", default=1, >> help="number of virtual cpus for appliance >> (default: 1)") >> + appopt.add_option("", "--generate-checksum", >> action="store_true", dest="checksum", >> + help=("Generate a checksum for the created >> appliance")) >> parser.add_option_group(appopt) >> # options related to the config of your system >> @@ -101,7 +103,7 @@ def main(): >> if options.name: >> name = options.name >> - creator = appcreate.ApplianceImageCreator(ks, name, >> options.format, options.package, options.vmem, options.vcpu) >> + creator = appcreate.ApplianceImageCreator(ks, name, >> options.format, options.package, options.vmem, options.vcpu, >> options.checksum) >> creator.tmpdir = options.tmpdir >> try: >> >> > > > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: act-disksignature-102101242.patch Type: text/x-patch Size: 4641 bytes Desc: not available URL: From dhuff at redhat.com Thu Oct 23 19:56:34 2008 From: dhuff at redhat.com (David Huff) Date: Thu, 23 Oct 2008 15:56:34 -0400 Subject: [Thincrust-devel] 4 commits Message-ID: <4900D6F2.70407@redhat.com> commit 9821e979f061eedb7bb458cb76bf6221860c7519 Author: David Huff Date: Thu Oct 23 15:28:32 2008 -0400 added error for Incomplete partition info throws an ugly error (465988) commit f9df34db9bc202ae810e3e0c9d534663b38c4ad4 Author: David Huff Date: Thu Oct 23 14:38:53 2008 -0400 fixed issue with Not supplying the --name option gives an error (468048) also moved write xml file to after conver to get size correct commit f854c08cd5ea904650d3f8059c043b68f2eafa91 Author: David Huff Date: Thu Oct 23 13:27:43 2008 -0400 fixed long move operations try rename is not necessary problem was due to another i commit 67329b2239d2542d4b992c7c8ba4aaff7879f3ca Author: Joey Boggs Date: Tue Oct 21 12:44:01 2008 -0400 act md5/sha256 disk signature support for appliance-creator Adds md5/sha256 disk signature support for appliance-creator enabled by --generate- Updated patch, mostly everything is the same, added in the progress bar just like v -D From apevec at redhat.com Fri Oct 24 09:08:24 2008 From: apevec at redhat.com (Alan Pevec) Date: Fri, 24 Oct 2008 11:08:24 +0200 Subject: [Thincrust-devel] 4 commits In-Reply-To: <4900D6F2.70407@redhat.com> References: <4900D6F2.70407@redhat.com> Message-ID: <49019088.7070806@redhat.com> David Huff wrote: > fixed long move operations try rename is not necessary problem was > due to another issue so what was the issue? From pmyers at redhat.com Fri Oct 24 14:21:56 2008 From: pmyers at redhat.com (Perry Myers) Date: Fri, 24 Oct 2008 10:21:56 -0400 Subject: [Thincrust-devel] Re: [Ovirt-devel] unable to add hosts in web admin tool In-Reply-To: <48FEF4CE.2090002@redfish-group.com> References: <48F2EED5.6030908@redfish-group.com> <48F2F6C7.4020300@redfish-group.com> <48F2FEEB.10705@redhat.com> <48F3128A.7090800@redfish-group.com> <48F35A21.6070101@redhat.com> <48FEF4CE.2090002@redfish-group.com> Message-ID: <4901DA04.40808@redhat.com> Justin Clacherty wrote: > Alan Pevec wrote: >> Justin Clacherty wrote: >>> Alan Pevec wrote: >>>> Please check the logs /var/log/ovirt* to find out what's going on >>> >>> Can't see anything much in the logs on the management server. I had >>> a look at ovirt.log on the managed host and it looks as though it is >>> having problems talking to the management node, not sure what to do >>> about it though. Here's the relevant part of the log: >>> >>> Resolving management.priv.ovirt.org.... 192.168.50.2 >>> Connecting to management.priv.ovirt.org.|192.168.50.2|:80... connected. >>> HTTP request sent, awaiting response... 500 Internal Server Error >>> 2008-10-13 16:52:33 ERROR 500: Internal Server Error. >> >> Seems that ovirt-appliance firstboot failed and left appliance in bad >> state, check the mongrel log. >> You can also reinstall ovirt-appliance image and try >> http://ovirt.org/page/TroubleShooting#Debugging_oVirt_Appliance_firstboot > > I waited for 0.94. Just tried it and the same thing is occuring. Is > there a trick to reinstalling the ovirt-appliance? Do I just run > "create-ovirt-appliance -e eth0" again? I don't see any console output > on the terminal when I run "virsh start ovirt-appliance; virsh console > ovirt-appliance", just the output of the start command "Domain > ovirt-appliance started". I don't think the appliance is set up to use a serial console by default... This is something the Thincrust folks might want to change to their default appliance creation scripts. (cc'd thincrust-devel for this) Reinstalling the appliance should be the following: 1. First make sure your appliance is dead: virsh destroy ovirt-appliance 2. Reinstall the ovirt-appliance RPM (if it's already installed you may need to rpm -Uvh --force it to overwrite the old RPM files) 3. Run create-ovirt-appliance 4. virsh start ovirt-appliance 5. virt-viewer ovirt-appliance Do this, and if there are still failures, please send (or post on ovirt.pastebin.com) the log output for files on the appliance in: /var/log/ace /var/log/ovirt-server /var/log/ovirt-* Thanks, Perry From dhuff at redhat.com Fri Oct 24 14:41:08 2008 From: dhuff at redhat.com (David Huff) Date: Fri, 24 Oct 2008 10:41:08 -0400 Subject: [Thincrust-devel] 4 commits In-Reply-To: <49019088.7070806@redhat.com> References: <4900D6F2.70407@redhat.com> <49019088.7070806@redhat.com> Message-ID: <4901DE84.2080902@redhat.com> Alan Pevec wrote: > David Huff wrote: >> fixed long move operations try rename is not necessary problem was >> due to another issue > > so what was the issue? > > _______________________________________________ > Thincrust-devel mailing list > Thincrust-devel at redhat.com > https://www.redhat.com/mailman/listinfo/thincrust-devel I was doing "shutil.move(files, self._outdir)" instead of "shutil.move(files, '%s/%s' % (self._outdir, os.path.basename(files)))" so the rename would always fail b/c the second arg was a dir not a file. shutil does try a rename first the do a bitwise move if it fails b/c of different file systems. -D From apevec at redhat.com Fri Oct 24 14:53:04 2008 From: apevec at redhat.com (Alan Pevec) Date: Fri, 24 Oct 2008 16:53:04 +0200 Subject: [Thincrust-devel] Re: [Ovirt-devel] unable to add hosts in web admin tool In-Reply-To: <4901DA04.40808@redhat.com> References: <48F2EED5.6030908@redfish-group.com> <48F2F6C7.4020300@redfish-group.com> <48F2FEEB.10705@redhat.com> <48F3128A.7090800@redfish-group.com> <48F35A21.6070101@redhat.com> <48FEF4CE.2090002@redfish-group.com> <4901DA04.40808@redhat.com> Message-ID: <4901E150.2020700@redhat.com> >>> You can also reinstall ovirt-appliance image and try >>> http://ovirt.org/page/TroubleShooting#Debugging_oVirt_Appliance_firstboot > I don't think the appliance is set up to use a serial console by > default... This is something the Thincrust folks might want to change > to their default appliance creation scripts. (cc'd thincrust-devel for > this) Right, default console is tty, not serial, but at the above URL I gave instructions how to change that in the image _before_ running it for the first time. After that virsh console ovirt-appliance should show boot messages - have you done that procedure and still don't see anything on serial console? From bkearney at redhat.com Fri Oct 24 18:42:20 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 24 Oct 2008 14:42:20 -0400 Subject: [Thincrust-devel] Some adk thinking Message-ID: <4902170C.3030901@redhat.com> Take a look at this: http://github.com/bkearney/adk/tree/master It is some early thinking around an adk. It is command line now, but it is starting to tie together the various tools. Basically.. we start with the kickstart and use that to get to the virt image. From there, we can push to EC2, VMWare, Cobbler. It is not great code, but it is food for thought (plus it helps me alot wit the various applianes I am building). -- bk From bkearney at redhat.com Mon Oct 27 13:19:15 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 27 Oct 2008 09:19:15 -0400 Subject: [Thincrust-devel] Re: [Ovirt-devel] unable to add hosts in web admin tool In-Reply-To: <4901E150.2020700@redhat.com> References: <48F2EED5.6030908@redfish-group.com> <48F2F6C7.4020300@redfish-group.com> <48F2FEEB.10705@redhat.com> <48F3128A.7090800@redfish-group.com> <48F35A21.6070101@redhat.com> <48FEF4CE.2090002@redfish-group.com> <4901DA04.40808@redhat.com> <4901E150.2020700@redhat.com> Message-ID: <4905BFD3.5090906@redhat.com> Alan Pevec wrote: >>>> You can also reinstall ovirt-appliance image and try >>>> http://ovirt.org/page/TroubleShooting#Debugging_oVirt_Appliance_firstboot > > >> I don't think the appliance is set up to use a serial console by >> default... This is something the Thincrust folks might want to change >> to their default appliance creation scripts. (cc'd thincrust-devel >> for this) > > Right, default console is tty, not serial, but at the above URL I gave > instructions how to change that in the image _before_ running it for the > first time. After that virsh console ovirt-appliance should show boot > messages - have you done that procedure and still don't see anything on > serial console Alan: This is the url.. yes? http://ovirt.org/page/TroubleShooting#Debugging_oVirt_Appliance_firstboot You appear to be modifying the host, not the guest is that correct? -- bk From apevec at redhat.com Mon Oct 27 14:00:14 2008 From: apevec at redhat.com (Alan Pevec) Date: Mon, 27 Oct 2008 15:00:14 +0100 Subject: [Thincrust-devel] Re: [Ovirt-devel] unable to add hosts in web admin tool In-Reply-To: <4905BFD3.5090906@redhat.com> References: <48F2EED5.6030908@redfish-group.com> <48F2F6C7.4020300@redfish-group.com> <48F2FEEB.10705@redhat.com> <48F3128A.7090800@redfish-group.com> <48F35A21.6070101@redhat.com> <48FEF4CE.2090002@redfish-group.com> <4901DA04.40808@redhat.com> <4901E150.2020700@redhat.com> <4905BFD3.5090906@redhat.com> Message-ID: <4905C96E.5080407@redhat.com> Bryan Kearney wrote: > http://ovirt.org/page/TroubleShooting#Debugging_oVirt_Appliance_firstboot > > You appear to be modifying the host, not the guest is that correct? guest image modified, it is mounted at /mnt using qemu-nbd (network block device) From kwilliams at renditionsoftware.com Tue Oct 28 22:30:58 2008 From: kwilliams at renditionsoftware.com (Kay Williams) Date: Tue, 28 Oct 2008 15:30:58 -0700 Subject: [Thincrust-devel] selinux security context Message-ID: <490792A2.3050505@renditionsoftware.com> I am experimenting with appliance-creator following instructions at http://www.thincrust.org/tooling.html. Very cool! One issue I ran into has to do with the selinux contexts. I created an image in my user home folder. When I tried to run launch it using virt-image, selinux complained. After manually changing the context to virt_image_t, all was well. Would it make sense for appliance-creator to automatically set the selinux context to created images? Kay From bkearney at redhat.com Wed Oct 29 17:52:44 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 29 Oct 2008 13:52:44 -0400 Subject: [Thincrust-devel] selinux security context In-Reply-To: <490792A2.3050505@renditionsoftware.com> References: <490792A2.3050505@renditionsoftware.com> Message-ID: <4908A2EC.5040106@redhat.com> Kay Williams wrote: > I am experimenting with appliance-creator following instructions at > http://www.thincrust.org/tooling.html. Very cool! > > One issue I ran into has to do with the selinux contexts. I created an > image in my user home folder. When I tried to run launch it using > virt-image, selinux complained. After manually changing the context to > virt_image_t, all was well. > > Would it make sense for appliance-creator to automatically set the > selinux context to created images? This is a good question. I would like to research this a bit to see if we should force typing the files, or if we should make it an on/off option. I need to research SELinux a bit to ask intelligently on the et-mgmt-tools list. I will do so, and get back to this list in a day or so. -- bk From apevec at redhat.com Wed Oct 29 21:23:06 2008 From: apevec at redhat.com (Alan Pevec) Date: Wed, 29 Oct 2008 22:23:06 +0100 Subject: [Thincrust-devel] selinux security context In-Reply-To: <490792A2.3050505@renditionsoftware.com> References: <490792A2.3050505@renditionsoftware.com> Message-ID: <4908D43A.6000608@redhat.com> Kay Williams wrote: > Would it make sense for appliance-creator to automatically set the > selinux context to created images? I think it would make sense that virt-image sets the SELinux context when installing the appliance image. From bkearney at redhat.com Wed Oct 29 21:40:00 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 29 Oct 2008 17:40:00 -0400 Subject: [Thincrust-devel] selinux security context In-Reply-To: <4908D43A.6000608@redhat.com> References: <490792A2.3050505@renditionsoftware.com> <4908D43A.6000608@redhat.com> Message-ID: <4908D830.4040909@redhat.com> Alan Pevec wrote: > Kay Williams wrote: >> Would it make sense for appliance-creator to automatically set the >> selinux context to created images? > > I think it would make sense that virt-image sets the SELinux context > when installing the appliance image. Would you suggest it to set a generic type like virt_image_t or a specific one such as qemu_t? Both tags can remove the issue. I am still trying to read through the SELinux docs to understand the types and how they relate to the interfaces in the policy. -- bk From kwilliams at renditionsoftware.com Thu Oct 30 22:28:45 2008 From: kwilliams at renditionsoftware.com (Kay Williams) Date: Thu, 30 Oct 2008 15:28:45 -0700 Subject: [Thincrust-devel] selinux security context In-Reply-To: <4908D830.4040909@redhat.com> References: <490792A2.3050505@renditionsoftware.com> <4908D43A.6000608@redhat.com> <4908D830.4040909@redhat.com> Message-ID: <490A351D.1070700@renditionsoftware.com> Bryan Kearney wrote: > Alan Pevec wrote: >> Kay Williams wrote: >>> Would it make sense for appliance-creator to automatically set the >>> selinux context to created images? >> >> I think it would make sense that virt-image sets the SELinux context >> when installing the appliance image. > > Would you suggest it to set a generic type like virt_image_t or a > specific one such as qemu_t? Both tags can remove the issue. > > I am still trying to read through the SELinux docs to understand the > types and how they relate to the interfaces in the policy. > > -- bk > Found this recent journal entry from Dan Walsh (Red Hat SELinux engineer) - http://danwalsh.livejournal.com/2008/10/22/. In it he says: "virt_manager will setup the labeling correctly when virtual images are installed..." So I guess it follows that virt-image would a) handle image labeling and b) have the same behavior as virt-manager (whatever that is).