Hi,
I was trying to generate the package manifest(ICICLE) of an existing disk image(an oz jeos).
Ensured the guest was shutdown and tried this:
######## root@~ $ oz-generate-icicle -d 4 /export/temp/oz-test/mickey.tdl /etc/libvirt/qemu/mickey.xml ########
<snip of oz-generate-icicle stdout> ####################################################################################### . .
DEBUG:oz.Guest.FedoraGuest:Resetting sshd service DEBUG:oz.Guest.FedoraGuest:Teardown step 3 DEBUG:oz.Guest.FedoraGuest:Resetting iptables rules DEBUG:oz.Guest.FedoraGuest:Teardown step 4 DEBUG:oz.Guest.FedoraGuest:Resetting announcement to host DEBUG:oz.Guest.FedoraGuest:Removing icicle-nc binary DEBUG:oz.Guest.FedoraGuest:Resetting crond service DEBUG:oz.Guest.FedoraGuest:Teardown step 5 INFO:oz.Guest.FedoraGuest:Cleaning up guestfs handle for mickey DEBUG:oz.Guest.FedoraGuest:Syncing DEBUG:oz.Guest.FedoraGuest:Unmounting all DEBUG:oz.Guest.FedoraGuest:Killing guestfs subprocess Traceback (most recent call last): File "/usr/bin/oz-generate-icicle", line 107, in <module> print guest.generate_icicle(open(libvirt_xml_file, 'r').read()) File "/usr/lib/python2.7/site-packages/oz/RedHat.py", line 388, in generate_icicle self.shutdown_guest(guestaddr, libvirt_dom) File "/usr/lib/python2.7/site-packages/oz/RedHat.py", line 432, in shutdown_guest libvirt_dom.destroy() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 349, in destroy if ret == -1: raise libvirtError ('virDomainDestroy() failed', dom=self) libvirt.libvirtError: Requested operation is not valid: domain is not running #######################################################################################
IIUC, it succeeds till step 5 (which is un-doing the modifications done on the disk image to allow remote access).
I didn't debug further. Shutting down gracefully fails? 'virDomainDestroy' -- is this pulling the power plug or doing a graceful shut-down?
It is yet to get to step-6(final one) is where it's failing to generate the ICICLE document w/ a list of pkgs.
Am I missing anything here?
Version Info: ######################## kashyap@~$ rpm -q oz oz-0.5.0-2.fc14.noarch ######################## (NOTE:I tried this on both F14, and F15 hosts to no avail.)
PS: Also attached the complete STDOUT of running oz-generate-icicle.
On 08/09/11 - 02:56:27PM, Kashyap Chamarthy wrote:
root@~ $oz-generate-icicle -d 4 /export/temp/oz-test/mickey.tdl /etc/libvirt/qemu/mickey.xml DEBUG:oz.Guest.FedoraGuest:libvirt bridge name is virbr0, host_bridge_ip is 192.168.122.1 DEBUG:oz.Guest.FedoraGuest:Name: mickey, UUID: 2906f8cc-4532-471f-9c6a-d798f22bbe81 DEBUG:oz.Guest.FedoraGuest:MAC: 52:54:00:1a:c2:ea, distro: Fedora DEBUG:oz.Guest.FedoraGuest:update: 14, arch: x86_64, diskimage: /var/lib/libvirt/images/mickey.dsk DEBUG:oz.Guest.FedoraGuest:nicmodel: virtio, clockoffset: utc DEBUG:oz.Guest.FedoraGuest:mousetype: ps2, disk_bus: virtio, disk_dev: vda DEBUG:oz.Guest.FedoraGuest:icicletmp: /var/lib/oz/icicletmp/mickey, listen_port: 64021 DEBUG:oz.Guest.FedoraGuest:Original ISO path: /var/lib/oz/isos/Fedora14x86_64-url.iso DEBUG:oz.Guest.FedoraGuest:Modified ISO cache: /var/lib/oz/isos/Fedora14x86_64-url-oz.iso DEBUG:oz.Guest.FedoraGuest:Output ISO path: /var/lib/libvirt/images/mickey-url-oz.iso DEBUG:oz.Guest.FedoraGuest:ISO content path: /var/lib/oz/isocontent/mickey-url DEBUG:oz.Guest.FedoraGuest:Original URL http://download.eng.pnq.redhat.com/pub/fedora/linux/releases/14/Fedora/x86_6... resolved to http://download.eng.pnq.redhat.com/pub/fedora/linux/releases/14/Fedora/x86_6... INFO:oz.Guest.FedoraGuest:Generating ICICLE INFO:oz.Guest.FedoraGuest:Collection Setup INFO:oz.Guest.FedoraGuest:Setting up guestfs handle for mickey DEBUG:oz.Guest.FedoraGuest:Adding disk image /var/lib/libvirt/images/mickey.dsk DEBUG:oz.Guest.FedoraGuest:Launching guestfs DEBUG:oz.Guest.FedoraGuest:Inspecting guest OS DEBUG:oz.Guest.FedoraGuest:Getting mountpoints DEBUG:oz.Guest.FedoraGuest:Root device: /dev/VolGroup00/LogVol00 DEBUG:oz.Guest.FedoraGuest:Step 1: Uploading ssh keys INFO:oz.Guest.FedoraGuest:Generating new openssh key DEBUG:oz.Guest.FedoraGuest:Step 2: setup sshd DEBUG:oz.Guest.FedoraGuest:Step 3: Open up the firewall DEBUG:oz.Guest.FedoraGuest:Step 4: Guest announcement DEBUG:oz.Guest.FedoraGuest:Step 5: Set SELinux to permissive mode INFO:oz.Guest.FedoraGuest:Cleaning up guestfs handle for mickey DEBUG:oz.Guest.FedoraGuest:Syncing DEBUG:oz.Guest.FedoraGuest:Unmounting all DEBUG:oz.Guest.FedoraGuest:Killing guestfs subprocess INFO:oz.Guest.FedoraGuest:Waiting for guest mickey to boot DEBUG:oz.Guest.FedoraGuest:Waiting for guest mickey to boot, 300/300 DEBUG:oz.Guest.FedoraGuest:Waiting for guest mickey to boot, 290/300 DEBUG:oz.Guest.FedoraGuest:Waiting for guest mickey to boot, 280/300 DEBUG:oz.Guest.FedoraGuest:Waiting for guest mickey to boot, 270/300 DEBUG:oz.Guest.FedoraGuest:Waiting for guest mickey to boot, 260/300 DEBUG:oz.Guest.FedoraGuest:Waiting for guest mickey to boot, 250/300 DEBUG:oz.Guest.FedoraGuest:IP address of guest is 192.168.122.25
OK, so all is good up until here; everything looks as expected.
DEBUG:oz.Guest.FedoraGuest:Waiting for mickey to shutdown, 60/60 DEBUG:oz.Guest.FedoraGuest:Waiting for mickey to shutdown, 50/60 DEBUG:oz.Guest.FedoraGuest:Waiting for mickey to shutdown, 40/60 DEBUG:oz.Guest.FedoraGuest:Waiting for mickey to shutdown, 30/60 DEBUG:oz.Guest.FedoraGuest:Waiting for mickey to shutdown, 20/60 DEBUG:oz.Guest.FedoraGuest:Waiting for mickey to shutdown, 10/60 WARNING:oz.Guest.FedoraGuest:Guest did not shutdown in time, going to kill
Here, the guest did not shutdown in time, so in response oz is going to try to use the equivalent of 'virsh destroy' to forcefully shutoff the guest.
INFO:oz.Guest.FedoraGuest:Collection Teardown INFO:oz.Guest.FedoraGuest:Setting up guestfs handle for mickey DEBUG:oz.Guest.FedoraGuest:Adding disk image /var/lib/libvirt/images/mickey.dsk DEBUG:oz.Guest.FedoraGuest:Launching guestfs DEBUG:oz.Guest.FedoraGuest:Inspecting guest OS DEBUG:oz.Guest.FedoraGuest:Getting mountpoints DEBUG:oz.Guest.FedoraGuest:Root device: /dev/VolGroup00/LogVol00 DEBUG:oz.Guest.FedoraGuest:Teardown step 1 DEBUG:oz.Guest.FedoraGuest:Resetting authorized_keys DEBUG:oz.Guest.FedoraGuest:Teardown step 2 DEBUG:oz.Guest.FedoraGuest:Resetting sshd_config DEBUG:oz.Guest.FedoraGuest:Resetting sshd service DEBUG:oz.Guest.FedoraGuest:Teardown step 3 DEBUG:oz.Guest.FedoraGuest:Resetting iptables rules DEBUG:oz.Guest.FedoraGuest:Teardown step 4 DEBUG:oz.Guest.FedoraGuest:Resetting announcement to host DEBUG:oz.Guest.FedoraGuest:Removing icicle-nc binary DEBUG:oz.Guest.FedoraGuest:Resetting crond service DEBUG:oz.Guest.FedoraGuest:Teardown step 5 INFO:oz.Guest.FedoraGuest:Cleaning up guestfs handle for mickey DEBUG:oz.Guest.FedoraGuest:Syncing DEBUG:oz.Guest.FedoraGuest:Unmounting all DEBUG:oz.Guest.FedoraGuest:Killing guestfs subprocess Traceback (most recent call last): File "/usr/bin/oz-generate-icicle", line 107, in <module> print guest.generate_icicle(open(libvirt_xml_file, 'r').read()) File "/usr/lib/python2.7/site-packages/oz/RedHat.py", line 388, in generate_icicle self.shutdown_guest(guestaddr, libvirt_dom) File "/usr/lib/python2.7/site-packages/oz/RedHat.py", line 432, in shutdown_guest libvirt_dom.destroy() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 349, in destroy if ret == -1: raise libvirtError ('virDomainDestroy() failed', dom=self) libvirt.libvirtError: Requested operation is not valid: domain is not running
However, it seems like between the time that oz determined that the guest didn't shut down, and when it actually went to do the kill, the domain shut down of its own accord. This could just mean that the guest was slow in shutting down.
This is a bug in Oz. If the destroy fails, but the guest has successfully gone away, we should just ignore the error and succeed the operation. I'll take a look at fixing this today.
On 08/09/11 - 08:51:43AM, Chris Lalancette wrote:
However, it seems like between the time that oz determined that the guest didn't shut down, and when it actually went to do the kill, the domain shut down of its own accord. This could just mean that the guest was slow in shutting down.
This is a bug in Oz. If the destroy fails, but the guest has successfully gone away, we should just ignore the error and succeed the operation. I'll take a look at fixing this today.
I pushed a commit (ec18386d78940cb72552) to the Oz git repository[1] that should take care of this problem.
I've also attached the patch to this email. It should apply to version 0.5.0 of Oz with some fuzz.
If you get a chance, could you please give it a test and let me know if it works for you?
Thanks,
On 08/09/2011 08:29 PM, Chris Lalancette wrote:
On 08/09/11 - 08:51:43AM, Chris Lalancette wrote:
However, it seems like between the time that oz determined that the guest didn't shut down, and when it actually went to do the kill, the domain shut down of its own accord. This could just mean that the guest was slow in shutting down.
This is a bug in Oz. If the destroy fails, but the guest has successfully gone away, we should just ignore the error and succeed the operation. I'll take a look at fixing this today.
I pushed a commit (ec18386d78940cb72552) to the Oz git repository[1] that should take care of this problem.
I've also attached the patch to this email. It should apply to version 0.5.0 of Oz with some fuzz.
If you get a chance, could you please give it a test and let me know if it works for you?
Ack. Thanks for the quick patch. git pull ; incremente the rel. no in the oz.spec ; make rpm --> Works for me. Attached is the successful package manifest generation.
Minor nit: currently, the icicle(pkg manifest) xml config is spit out to the stdout. Do you think a print to file option helps? (Though this can be done with a bit of bash i/o redirection...)
Thanks,
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On 08/09/11 - 10:26:53PM, Kashyap Chamarthy wrote:
On 08/09/2011 08:29 PM, Chris Lalancette wrote:
On 08/09/11 - 08:51:43AM, Chris Lalancette wrote:
However, it seems like between the time that oz determined that the guest didn't shut down, and when it actually went to do the kill, the domain shut down of its own accord. This could just mean that the guest was slow in shutting down.
This is a bug in Oz. If the destroy fails, but the guest has successfully gone away, we should just ignore the error and succeed the operation. I'll take a look at fixing this today.
I pushed a commit (ec18386d78940cb72552) to the Oz git repository[1] that should take care of this problem.
I've also attached the patch to this email. It should apply to version 0.5.0 of Oz with some fuzz.
If you get a chance, could you please give it a test and let me know if it works for you?
Ack. Thanks for the quick patch. git pull ; incremente the rel. no in the oz.spec ; make rpm --> Works for me. Attached is the successful package manifest generation.
Excellent, thanks for the test.
Minor nit: currently, the icicle(pkg manifest) xml config is spit out to the stdout. Do you think a print to file option helps? (Though this can be done with a bit of bash i/o redirection...)
Right. Actually, what I think might be a good thing is to keep the default as it is (write ICICLE to stdout), but then add an option to write to a file if the user wants. I'll add an option both to oz-install and oz-generate-icicle to do that.
On 08/09/2011 10:29 PM, Chris Lalancette wrote:
On 08/09/11 - 10:26:53PM, Kashyap Chamarthy wrote:
On 08/09/2011 08:29 PM, Chris Lalancette wrote:
On 08/09/11 - 08:51:43AM, Chris Lalancette wrote:
However, it seems like between the time that oz determined that the guest didn't shut down, and when it actually went to do the kill, the domain shut down of its own accord. This could just mean that the guest was slow in shutting down.
This is a bug in Oz. If the destroy fails, but the guest has successfully gone away, we should just ignore the error and succeed the operation. I'll take a look at fixing this today.
I pushed a commit (ec18386d78940cb72552) to the Oz git repository[1] that should take care of this problem.
I've also attached the patch to this email. It should apply to version 0.5.0 of Oz with some fuzz.
If you get a chance, could you please give it a test and let me know if it works for you?
Ack. Thanks for the quick patch. git pull ; incremente the rel. no in the oz.spec ; make rpm --> Works for me. Attached is the successful package manifest generation.
Excellent, thanks for the test.
You're welcome.
Minor nit: currently, the icicle(pkg manifest) xml config is spit out to the stdout. Do you think a print to file option helps? (Though this can be done with a bit of bash i/o redirection...)
Right. Actually, what I think might be a good thing is to keep the default as it is (write ICICLE to stdout), but then add an option to write to a file if the user wants. I'll add an option both to oz-install and oz-generate-icicle to do that.
Yes, that makes sense. thanks.
Per IRC discussion(on #aeolus) , the timing with virt-install(4-5 min) / oz-install(9-10 min) is interesting. If this can be worked on , batch installs with oz can also be quickened. Thanks for your time..
On 08/09/11 - 10:53:55PM, Kashyap Chamarthy wrote:
Minor nit: currently, the icicle(pkg manifest) xml config is spit out to the stdout. Do you think a print to file option helps? (Though this can be done with a bit of bash i/o redirection...)
Right. Actually, what I think might be a good thing is to keep the default as it is (write ICICLE to stdout), but then add an option to write to a file if the user wants. I'll add an option both to oz-install and oz-generate-icicle to do that.
Yes, that makes sense. thanks.
I've now added this to the git repository, so it should make the 0.6.0 release.
Per IRC discussion(on #aeolus) , the timing with virt-install(4-5 min) / oz-install(9-10 min) is interesting. If this can be worked on , batch installs with oz can also be quickened. Thanks for your time..
Right. Part of the speed problem is all of the manipulations that Oz does to the ISO image. If we can eliminate that, we could speed up the builds. The --initrd-inject flag to virt-install looks interesting; I'll look at that when I get some free time and think about how we could use something similar in Oz.
Thanks again,
On 08/09/2011 11:32 PM, Chris Lalancette wrote:
On 08/09/11 - 10:53:55PM, Kashyap Chamarthy wrote:
Minor nit: currently, the icicle(pkg manifest) xml config is spit out to the stdout. Do you think a print to file option helps? (Though this can be done with a bit of bash i/o redirection...)
Right. Actually, what I think might be a good thing is to keep the default as it is (write ICICLE to stdout), but then add an option to write to a file if the user wants. I'll add an option both to oz-install and oz-generate-icicle to do that.
Yes, that makes sense. thanks.
I've now added this to the git repository, so it should make the 0.6.0 release.
Nice, that was quick.
Per IRC discussion(on #aeolus) , the timing with virt-install(4-5 min) / oz-install(9-10 min) is interesting. If this can be worked on , batch installs with oz can also be quickened. Thanks for your time..
Right. Part of the speed problem is all of the manipulations that Oz does to the ISO image. If we can eliminate that, we could speed up the builds. The --initrd-inject flag to virt-install looks interesting; I'll look at that when I get some free time and think about how we could use something similar in Oz.
Great. --initrd-inject has been much more convenient with virt-installs than pulling the 'ks' from the http server( as there is an element of uncertainty..)
Thanks again,
aeolus-devel@lists.fedorahosted.org
-
Chris Lalancette -
Kashyap Chamarthy