-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Conversation
@dmlb2000 Nice! I'll assume this is is a work-in-progress until you ping us further, sound okay? |
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. |
instead of using the virtio because the autoyast install xml has that hard coded, need to try autopartitioning and see if that builds.
Conflicts: ubuntu-12.04-i386.json
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
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. Since I have access to Redhat from work I was able to test them as well. |
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. |
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. |
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. |
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? |
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. |
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 In any case, great work to date! |
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. |
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. |
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. |
So take a look at pull #374 |
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.