Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add qemu options for all systems #356

Closed
wants to merge 29 commits into from
Closed

Conversation

dmlb2000
Copy link
Contributor

This is going to be a slow process adding all the qemu options for the various distros/versions but this is a start anyway.

This enables one to use vagrant+libvirt on a Linux box without requiring virtualbox.

@fnichol
Copy link
Contributor

fnichol commented May 25, 2015

@dmlb2000 Nice! I'll assume this is is a work-in-progress until you ping us further, sound okay?

@dmlb2000
Copy link
Contributor Author

Yes, my goal is to get all the Linuxes and maybe the BSDs. I'm probably not going to get the OSX, and I'm not sure about Solaris.

@dmlb2000
Copy link
Contributor Author

So all the SLES OSs I can't test as the URLs produce a 404...

Conflicts:
	debian-6.0.10-amd64.json
	debian-6.0.10-i386.json
	debian-7.8-amd64.json
	debian-7.8-i386.json
	ubuntu-12.04-i386.json
@dmlb2000
Copy link
Contributor Author

I believe this is all the Linuxes... There were a few that tested oddly or not at all.

SLES did not test at all, the ISO urls I couldn't get to.
Oracle 6.6 x86_64 didn't reboot after the initial install, not sure why...

Since I have access to Redhat from work I was able to test them as well.

@dmlb2000
Copy link
Contributor Author

Oh, also not sure why the OpenSUSE or SLES have a hard coded /dev/sda in the autoyast install xml. There is a way to have the installer auto detect the device this would allow them to use virtio for a block device.

@fnichol fnichol added Waiting and removed Triaged labels May 27, 2015
@dmlb2000
Copy link
Contributor Author

dmlb2000 commented Jun 2, 2015

At this point I'm thinking this should be merged before I fix anything else and this becomes more than just putting the qemu options into the json.

@beddari
Copy link

beddari commented Jun 11, 2015

I'd like to help getting this merged and maintained, I'm already using a private fork of bento for this exact purpose. What is missing? I'd argue getting the ones we're able to test supported first is the best approach.

@beddari
Copy link

beddari commented Jun 11, 2015

Hmm, looking at your fork @dmlb2000 it might be easier/better if you create a feature branch and keep it rebased against the current master. Also squashing/cleaning up commits would help. What do you think?

@beddari
Copy link

beddari commented Jun 12, 2015

One issue with qemu is that the zerofilling in minimize.sh messes up the thin qcow2 format so that the final boxes become full-sized. Just skipping minimize.sh fixes that but then that somehow has to depend on the builder. Not sure how that could work.

@fnichol
Copy link
Contributor

fnichol commented Jun 12, 2015

I'd agree with @beddari that eventually squashing and rebasing the commits will help maintain the narrative flow of the commits.

@dmlb2000 As I've been running/updating some of these templates I've noticed some silent failures and out of date download locations as well (SLES seems to need a login now and RHEL seems to have removed their ISOs from the CDN location). I'm hoping to get these updated but it's been a slow process. I am hoping to get the scripts to run with a sh -ex (or equivalent) so that any non-zero returns kill the process at the first sign of trouble. Unfortunately, this might have to happen one distribution at a time.

In any case, great work to date!

@dmlb2000
Copy link
Contributor Author

I'll work on trying to squash my commits and rebase against the current master.

I did put an issue in talking about the minimize.sh script and how it blows up the image. One can put the same login as the vmtools.sh script into the minimize.sh script and just exit 0 when its a qemu build.

@mattiascockburn
Copy link
Contributor

For SLES 11/12 it might be necessary to accept #373 as well. Unfortunately SUSE does not provide direct download URLs for SLES, so you would need to provide your own mirror. I'd test the SLES build for you.

@dmlb2000
Copy link
Contributor Author

Okay I've "squashed" the commits and am making another pull request to manage the pull easier for you guys... so I'm closing this and making a new one.

@dmlb2000
Copy link
Contributor Author

So take a look at pull #374

@dmlb2000 dmlb2000 closed this Jun 19, 2015
@fnichol fnichol removed the Waiting label Jun 19, 2015
@dmlb2000 dmlb2000 deleted the master branch June 23, 2015 15:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants