vagrant to raw disk
48 views
Skip to first unread message
tom.ro...@motec.com.au
Nov 27, 2016, 8:42:08 PM11/27/16
to Vagrant
Hi,
I'm new to Vagrant. Liking it a lot!
We have KVM/Qemu/libvirt environment. Our storage is on SAN and we normally provision guests manually as RAW disks. We are just discovering Vagrant so lots of questions are coming up. The documentation is great so far but I just can't find and answer to the following.
Is there a way to vagrant up a vm.box and have it install directly to RAW storage already provisioned on our SAN?
I managed to do something with packer to 'build' a box directly on RAW storage by using qemuargs ( [ "-drive", "file=/dev/mapper/3600144f0000000000000583674610002" ] but it's not really what we want. We want to be able to provision with vagrant directly and have that deploy to our multipath devices.
Finding no answer through web searching. Any help would be greatly appreciated.
Kind regards,
Tom
I'm new to Vagrant. Liking it a lot!
We have KVM/Qemu/libvirt environment. Our storage is on SAN and we normally provision guests manually as RAW disks. We are just discovering Vagrant so lots of questions are coming up. The documentation is great so far but I just can't find and answer to the following.
Is there a way to vagrant up a vm.box and have it install directly to RAW storage already provisioned on our SAN?
I managed to do something with packer to 'build' a box directly on RAW storage by using qemuargs ( [ "-drive", "file=/dev/mapper/3600144f0000000000000583674610002" ] but it's not really what we want. We want to be able to provision with vagrant directly and have that deploy to our multipath devices.
Finding no answer through web searching. Any help would be greatly appreciated.
Kind regards,
Tom
Alvaro Miranda Aguilera
Nov 28, 2016, 9:56:41 AM11/28/16
to vagra...@googlegroups.com
hello.
Can you explain more? please note that I am asking more information to understand the use case, so please spare few minutes.
Vagrant is a tool for development.
and development focus on speed (as in velocity to develop faster) so you usually take the simple that works.
Is this for PROD workloads? or just dev workloads ?
Using luns from san + vagrant sounds a bit overcomplex.
So, can you explain more of what do you want to do ? leave vagrant/packer out on the first iteration, and then will be easier to see if packer/vagrant are the best fit.
Thanks!
Alvaro.
--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/607870e5-e2bf-4f1b-b13d-349b939235c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Alvaro
Tom Robinson
Nov 28, 2016, 5:11:36 PM11/28/16
to vagra...@googlegroups.com
Hi Alvaro,
Thanks for responding.
Our main goal is better configuration management of both Develpment and Production environments. We
will also soon be moving to AWS for some Production components only; Devs will remain internal. I
want to use tooling like Vagrant, Packer and Ansible to gain better control over configuration
management for machine provisioning.
Currently we have several environments:
* Devs working on Windows using VMware Workstation.
* Devs on linux using KVM/qemu/libvirt locally on their Workstations.
* Build boxes (compiling code) hosted on KVM/SAN Servers; each instance has it's own RAW disk
connected through to SAN storage. These Build Boxes are used by Devs but are considered 'Production'
as they produce our final releases of our software products. Some of these run all the time; some
only as needed.
* Dev/Test instances of applications that run on the KVM/SAN Servers. These come and go but we
always provision using SAN storage RAW disks (currently semi-automated using kickstart and answer
files).
* Production instances of applications on KVM/SAN Servers.
* Production Infrastructure (to be replace by AWS) runing KVM and qcow2 images.
It's also important that we are able to rebuild consistently a given configuration to compile a
specific code base within a specific environment (for long term support of specific products).
Currently Devs are not using anything to control configuration. Everyone just runs up there own
instances so we get a lot of duplicated effort and some inconstancies.
Hopefully you can see a little of what we have and are trying to achieve. Maybe some of it fits the
Vagrant/Packer/Ansible mould. Any feedback is welcome. Thanks again for looking at this.
Kind regards,
Tom Robinson
IT Manager/System Administrator
MoTeC Pty Ltd
121 Merrindale Drive
Croydon South
3136 Victoria
Australia
T: +61 3 9761 5050
F: +61 3 9761 5051
E: tom.ro...@motec.com.au
On 29/11/16 01:56, Alvaro Miranda Aguilera wrote:
> hello.
>
> Can you explain more? please note that I am asking more information to understand the use case, so
> please spare few minutes.
>
> Vagrant is a tool for development.
> and development focus on speed (as in velocity to develop faster) so you usually take the simple
> that works.
>
> Is this for PROD workloads? or just dev workloads ?
>
> Using luns from san + vagrant sounds a bit overcomplex.
>
> So, can you explain more of what do you want to do ? leave vagrant/packer out on the first
> iteration, and then will be easier to see if packer/vagrant are the best fit.
>
> Thanks!
> Alvaro.
>
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
>
>
>
> --
> Alvaro
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/vagrant-up/ddqV3R-M79g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> vagrant-up+...@googlegroups.com <mailto:vagrant-up+...@googlegroups.com>.
> <https://groups.google.com/d/msgid/vagrant-up/CAHqq0ew--LqfWy6d5zWzJQgbmVivUCTuDawD8UVShHr5NEcA%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Thanks for responding.
Our main goal is better configuration management of both Develpment and Production environments. We
will also soon be moving to AWS for some Production components only; Devs will remain internal. I
want to use tooling like Vagrant, Packer and Ansible to gain better control over configuration
management for machine provisioning.
Currently we have several environments:
* Devs working on Windows using VMware Workstation.
* Devs on linux using KVM/qemu/libvirt locally on their Workstations.
* Build boxes (compiling code) hosted on KVM/SAN Servers; each instance has it's own RAW disk
connected through to SAN storage. These Build Boxes are used by Devs but are considered 'Production'
as they produce our final releases of our software products. Some of these run all the time; some
only as needed.
* Dev/Test instances of applications that run on the KVM/SAN Servers. These come and go but we
always provision using SAN storage RAW disks (currently semi-automated using kickstart and answer
files).
* Production instances of applications on KVM/SAN Servers.
* Production Infrastructure (to be replace by AWS) runing KVM and qcow2 images.
It's also important that we are able to rebuild consistently a given configuration to compile a
specific code base within a specific environment (for long term support of specific products).
Currently Devs are not using anything to control configuration. Everyone just runs up there own
instances so we get a lot of duplicated effort and some inconstancies.
Hopefully you can see a little of what we have and are trying to achieve. Maybe some of it fits the
Vagrant/Packer/Ansible mould. Any feedback is welcome. Thanks again for looking at this.
Kind regards,
Tom Robinson
IT Manager/System Administrator
MoTeC Pty Ltd
121 Merrindale Drive
Croydon South
3136 Victoria
Australia
T: +61 3 9761 5050
F: +61 3 9761 5051
E: tom.ro...@motec.com.au
On 29/11/16 01:56, Alvaro Miranda Aguilera wrote:
> hello.
>
> Can you explain more? please note that I am asking more information to understand the use case, so
> please spare few minutes.
>
> Vagrant is a tool for development.
> and development focus on speed (as in velocity to develop faster) so you usually take the simple
> that works.
>
> Is this for PROD workloads? or just dev workloads ?
>
> Using luns from san + vagrant sounds a bit overcomplex.
>
> So, can you explain more of what do you want to do ? leave vagrant/packer out on the first
> iteration, and then will be easier to see if packer/vagrant are the best fit.
>
> Thanks!
> Alvaro.
>
> On Mon, Nov 28, 2016 at 2:42 AM, <tom.ro...@motec.com.au <mailto:tom.ro...@motec.com.au>> wrote:
>
> Hi,
>
> I'm new to Vagrant. Liking it a lot!
>
> We have KVM/Qemu/libvirt environment. Our storage is on SAN and we normally provision guests
> manually as RAW disks. We are just discovering Vagrant so lots of questions are coming up. The
> documentation is great so far but I just can't find and answer to the following.
>
> Is there a way to vagrant up a vm.box and have it install directly to RAW storage already
> provisioned on our SAN?
>
> I managed to do something with packer to 'build' a box directly on RAW storage by using qemuargs
> ( [ "-drive", "file=/dev/mapper/3600144f0000000000000583674610002" ] but it's not really what we
> want. We want to be able to provision with vagrant directly and have that deploy to our
> multipath devices.
>
> Finding no answer through web searching. Any help would be greatly appreciated.
>
> Kind regards,
> Tom
>
> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html
> <https://www.hashicorp.com/community-guidelines.html>. Behavior in violation of those guidelines
>
> Hi,
>
> I'm new to Vagrant. Liking it a lot!
>
> We have KVM/Qemu/libvirt environment. Our storage is on SAN and we normally provision guests
> manually as RAW disks. We are just discovering Vagrant so lots of questions are coming up. The
> documentation is great so far but I just can't find and answer to the following.
>
> Is there a way to vagrant up a vm.box and have it install directly to RAW storage already
> provisioned on our SAN?
>
> I managed to do something with packer to 'build' a box directly on RAW storage by using qemuargs
> ( [ "-drive", "file=/dev/mapper/3600144f0000000000000583674610002" ] but it's not really what we
> want. We want to be able to provision with vagrant directly and have that deploy to our
> multipath devices.
>
> Finding no answer through web searching. Any help would be greatly appreciated.
>
> Kind regards,
> Tom
>
> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html
> may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/vagrant/issues
> <https://github.com/mitchellh/vagrant/issues>
> IRC: #vagrant on Freenode
> ---
> You received this message because you are subscribed to the Google Groups "Vagrant" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> vagrant-up+...@googlegroups.com <mailto:vagrant-up+...@googlegroups.com>.
>
> GitHub Issues: https://github.com/mitchellh/vagrant/issues
> <https://github.com/mitchellh/vagrant/issues>
> IRC: #vagrant on Freenode
> ---
> You received this message because you are subscribed to the Google Groups "Vagrant" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vagrant-up/607870e5-e2bf-4f1b-b13d-349b939235c4%40googlegroups.com
> <https://groups.google.com/d/msgid/vagrant-up/607870e5-e2bf-4f1b-b13d-349b939235c4%40googlegroups.com?utm_medium=email&utm_source=footer>.
> https://groups.google.com/d/msgid/vagrant-up/607870e5-e2bf-4f1b-b13d-349b939235c4%40googlegroups.com
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
>
>
>
> --
> Alvaro
>
> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may
> result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/vagrant/issues
> IRC: #vagrant on Freenode
> ---
> You received this message because you are subscribed to a topic in the Google Groups "Vagrant" group.
> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may
> result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/vagrant/issues
> IRC: #vagrant on Freenode
> ---
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/vagrant-up/ddqV3R-M79g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> vagrant-up+...@googlegroups.com <mailto:vagrant-up+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vagrant-up/CAHqq0ew--LqfWy6d5zWzJQgbmVivUCTuDawD8UVShHr5NEcA%3DA%40mail.gmail.com
> <https://groups.google.com/d/msgid/vagrant-up/CAHqq0ew--LqfWy6d5zWzJQgbmVivUCTuDawD8UVShHr5NEcA%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages