Vagrant and KVM

scottalanmiller

No, but I would LOVE to see a How To on this. I've never gotten time to play with Vagrant and hear so many good things about it, I would like to see it in action.

RamblingBiped

@scottalanmiller said in Vagrant and KVM:

No, but I would LOVE to see a How To on this. I've never gotten time to play with Vagrant and hear so many good things about it, I would like to see it in action.

It looks like this is the current project in works for implementing libvirt as a Vagrant provider: https://github.com/vagrant-libvirt/vagrant-libvirt

The old Vagrant-KVM project, which was the other means of implementing KVM as a provider, seems to be no longer in development.

scottalanmiller

@RamblingBiped said in Vagrant and KVM:

@scottalanmiller said in Vagrant and KVM:

No, but I would LOVE to see a How To on this. I've never gotten time to play with Vagrant and hear so many good things about it, I would like to see it in action.

It looks like this is the current project in works for implementing libvirt as a Vagrant provider: https://github.com/vagrant-libvirt/vagrant-libvirt

That would be neat.

RamblingBiped

So, with a little intermittent hacking on my test hypervisor at work I was able to get this working. The documentation is a bit fragmented for the vagrant-libvirt project, but I was able to use it in combination with some examples they have to get a working VM up and going. For one reason or another it was not happy using my LVM storage pool, and I had to switch to the "default" storage pool.

The gist of the basic setup is this:

Install Vagrant per normal instructions (I used the debian package as my KVM-QEMU hypervisor was built on Ubuntu 16.04): https://www.vagrantup.com/docs/installation/
Install the vagrant-libvirt add-on to make libvirt an accessible provider: https://github.com/vagrant-libvirt/vagrant-libvirt#installation
Reference the box builds for the specific OS you are wanting to use as your base configuration, and initialize it. As libvirt is not currently a supported provider, you'll notice there are no Hashicorp or "official" box images available. https://atlas.hashicorp.com/boxes/search?provider=libvirt
Once you've initialized the box image as instructed (https://github.com/vagrant-libvirt/vagrant-libvirt#add-box) you'll want to go in and edit your vagrant configuration file. I suggest creating a sub-directory to initialize the box in, and subsequently store your Vagrantfile. Customizing the Vagrantfile is where I started running into problems. There is a second portion of the configuration relevant to defining specific options relative to the libvirt provider that they seem to have left out of the documentation. I found that information here, in the following example: https://github.com/vagrant-libvirt/vagrant-libvirt/blob/master/example_box/Vagrantfile
Condensed, that section should look something like this:

 #Options for libvirt provider
  config.vm.provider :libvirt do |libvirt|
    libvirt.driver = "kvm"
    libvirt.connect_via_ssh = false
    libvirt.username = "root"
    libvirt.storage_pool_name = "default"
  end

I entered the above at the bottom of my Vagrantfile just above, and indented to the right of, the last end statement.

My test VM Vagrantfile for an Ubuntu Xenial 64-bit KVM virtual machine looks like this:

Vagrant.configure("2") do |config|

  # Configure new Ubuntu Xenial64 VM
  config.vm.define :test_vm do |test_vm|
    test_vm.vm.box = "yk0/ubuntu-xenial"
    test_vm.vm.provider :libvirt do |domain|
      domain.memory = 2048
      domain.cpus = 2
    end
  end
  #Configuration options for libvirt provider
  config.vm.provider :libvirt do |libvirt|
    libvirt.driver = "kvm"
    libvirt.connect_via_ssh = false
    libvirt.username = "root"
    libvirt.storage_pool_name = "default"
  end

end

RamblingBiped

So, the idea is to use Vagrant to spin up and destroy KVM virtual machines, and use Ansible to provision and configure said VMs once they are made available. I'll work on getting vagrant to use LVM for provisioning VM storage and I'll review the exhaustive granularity on the base configuration options available and report back. If time permits I'll do a write up / how-to on my blog.

stacksofplates

What's the advantage to vagrant over just using Ansible with kickstart/preseed config?

RamblingBiped

@stacksofplates said in Vagrant and KVM:

What's the advantage to vagrant over just using Ansible with kickstart/preseed config?

From what I understand, Ansible integrates with the VM provisioning done using Vagrant. At the time of VM creation you can define a specific Ansible playbook from withing the Vagrantfile that can completely configure your VM from the base Vagrant image, and kickoff subsequent builds/configurations.

Vagrant alone is usually used directly by developers to build one-off environments that conform to the production environment's constraints. Ansible is most often used as an automation tool for Operations/DevOps to force/maintain uniformity/conformity of configuration in a production environment. Blending the two together aids in simplifying the configuration management of both production and development environments.

Hypothetically, I believe you could do everything you need to do in the absence of Vagrant just using Ansible and Ansible playbooks. I have a hunch that Vagrant allows you to abstract the base VM configuration out of your Ansible Playbooks and configurations and helps reduce the complexity of your playbooks and speeds VM deployment and administration. I'll hopefully be able to confirm that in the not so distant future...

http://docs.ansible.com/ansible/guide_vagrant.html

stacksofplates

@RamblingBiped said in Vagrant and KVM:

@stacksofplates said in Vagrant and KVM:

What's the advantage to vagrant over just using Ansible with kickstart/preseed config?

From what I understand, Ansible integrates with the VM provisioning done using Vagrant. At the time of VM creation you can define a specific Ansible playbook from withing the Vagrantfile that can completely configure your VM from the base Vagrant image, and kickoff subsequent builds/configurations.

Vagrant alone is usually used directly by developers to build one-off environments that conform to the production environment's constraints. Ansible is most often used as an automation tool for Operations/DevOps to force/maintain uniformity/conformity of configuration in a production environment. Blending the two together aids in simplifying the configuration management of both production and development environments.

Hypothetically, I believe you could do everything you need to do in the absence of Vagrant just using Ansible and Ansible playbooks. I have a hunch that Vagrant allows you to abstract the base VM configuration out of your Ansible Playbooks and configurations and helps reduce the complexity of your playbooks and speeds VM deployment and administration. I'll hopefully be able to confirm that in the not so distant future...

http://docs.ansible.com/ansible/guide_vagrant.html

So I don't know anything about preseed stuff, but Im not seeing what Vagrant does that a kickstart file doesn't do. You could just have Ansible tell KVM to build from a kickstart file and even include default config in the post install of the kickstart. Then if anything else was needed Ansible could do it after the VM is created. You could even have Ansible create the kickstart files using the jinja templates.

stacksofplates

The other cool thing about using Ansible with kickstart files is Ansible can provision the kickstart for your physical machines too.

scottalanmiller

@stacksofplates said in Vagrant and KVM:

@RamblingBiped said in Vagrant and KVM:

@stacksofplates said in Vagrant and KVM:

What's the advantage to vagrant over just using Ansible with kickstart/preseed config?

From what I understand, Ansible integrates with the VM provisioning done using Vagrant. At the time of VM creation you can define a specific Ansible playbook from withing the Vagrantfile that can completely configure your VM from the base Vagrant image, and kickoff subsequent builds/configurations.

Vagrant alone is usually used directly by developers to build one-off environments that conform to the production environment's constraints. Ansible is most often used as an automation tool for Operations/DevOps to force/maintain uniformity/conformity of configuration in a production environment. Blending the two together aids in simplifying the configuration management of both production and development environments.

Hypothetically, I believe you could do everything you need to do in the absence of Vagrant just using Ansible and Ansible playbooks. I have a hunch that Vagrant allows you to abstract the base VM configuration out of your Ansible Playbooks and configurations and helps reduce the complexity of your playbooks and speeds VM deployment and administration. I'll hopefully be able to confirm that in the not so distant future...

http://docs.ansible.com/ansible/guide_vagrant.html

So I don't know anything about preseed stuff, but Im not seeing what Vagrant does that a kickstart file doesn't do. You could just have Ansible tell KVM to build from a kickstart file and even include default config in the post install of the kickstart. Then if anything else was needed Ansible could do it after the VM is created. You could even have Ansible create the kickstart files using the jinja templates.

I think Vagrant handles more platforms

stacksofplates

@scottalanmiller said in Vagrant and KVM:

@stacksofplates said in Vagrant and KVM:

@RamblingBiped said in Vagrant and KVM:

@stacksofplates said in Vagrant and KVM:

What's the advantage to vagrant over just using Ansible with kickstart/preseed config?

From what I understand, Ansible integrates with the VM provisioning done using Vagrant. At the time of VM creation you can define a specific Ansible playbook from withing the Vagrantfile that can completely configure your VM from the base Vagrant image, and kickoff subsequent builds/configurations.

Vagrant alone is usually used directly by developers to build one-off environments that conform to the production environment's constraints. Ansible is most often used as an automation tool for Operations/DevOps to force/maintain uniformity/conformity of configuration in a production environment. Blending the two together aids in simplifying the configuration management of both production and development environments.

Hypothetically, I believe you could do everything you need to do in the absence of Vagrant just using Ansible and Ansible playbooks. I have a hunch that Vagrant allows you to abstract the base VM configuration out of your Ansible Playbooks and configurations and helps reduce the complexity of your playbooks and speeds VM deployment and administration. I'll hopefully be able to confirm that in the not so distant future...

http://docs.ansible.com/ansible/guide_vagrant.html

So I don't know anything about preseed stuff, but Im not seeing what Vagrant does that a kickstart file doesn't do. You could just have Ansible tell KVM to build from a kickstart file and even include default config in the post install of the kickstart. Then if anything else was needed Ansible could do it after the VM is created. You could even have Ansible create the kickstart files using the jinja templates.

I think Vagrant handles more platforms

That makes sense. If you have a mix of Debian based and RH based (does it do BSD?) I can see that. I've never played with preseed stuff so Vagrant may very well be much better than that.

StrongBad

@stacksofplates said in Vagrant and KVM:

@scottalanmiller said in Vagrant and KVM:

@stacksofplates said in Vagrant and KVM:

@RamblingBiped said in Vagrant and KVM:

@stacksofplates said in Vagrant and KVM:

What's the advantage to vagrant over just using Ansible with kickstart/preseed config?

From what I understand, Ansible integrates with the VM provisioning done using Vagrant. At the time of VM creation you can define a specific Ansible playbook from withing the Vagrantfile that can completely configure your VM from the base Vagrant image, and kickoff subsequent builds/configurations.

Vagrant alone is usually used directly by developers to build one-off environments that conform to the production environment's constraints. Ansible is most often used as an automation tool for Operations/DevOps to force/maintain uniformity/conformity of configuration in a production environment. Blending the two together aids in simplifying the configuration management of both production and development environments.

Hypothetically, I believe you could do everything you need to do in the absence of Vagrant just using Ansible and Ansible playbooks. I have a hunch that Vagrant allows you to abstract the base VM configuration out of your Ansible Playbooks and configurations and helps reduce the complexity of your playbooks and speeds VM deployment and administration. I'll hopefully be able to confirm that in the not so distant future...

http://docs.ansible.com/ansible/guide_vagrant.html

So I don't know anything about preseed stuff, but Im not seeing what Vagrant does that a kickstart file doesn't do. You could just have Ansible tell KVM to build from a kickstart file and even include default config in the post install of the kickstart. Then if anything else was needed Ansible could do it after the VM is created. You could even have Ansible create the kickstart files using the jinja templates.

I think Vagrant handles more platforms

That makes sense. If you have a mix of Debian based and RH based (does it do BSD?) I can see that. I've never played with preseed stuff so Vagrant may very well be much better than that.

yes it does. OpenBSD too.

http://www.vagrantbox.es/

IRJ

Gonna bring this back to the dead because vagrant is awesome. I am using now with libvirt

This is how I configure it on Ubuntu 18.04 (note you must install qemu / kvm first)

#***********************************************************
# Vagrant QEMU / KVM Dependencies
#***********************************************************

sudo apt-get build-dep vagrant ruby-libvirt
sudo apt-get install qemu libvirt-bin ebtables dnsmasq-base
sudo apt-get install libxslt-dev libxml2-dev libvirt-dev zlib1g-dev ruby-dev


#***********************************************************
# Vagrant QEMU / KVM Plugin
#***********************************************************

sudo vagrant plugin install vagrant-libvirt

#***********************************************************
# Download, copy, and install vagrant
#***********************************************************
sudo apt install unzip
sudo wget https://releases.hashicorp.com/terraform/0.12.0/terraform_0.12.0_linux_amd64.zip
sudo unzip terraform_0.12.0_linux_amd64.zip
sudo mv terraform /usr/local/bin/

#***********************************************************
# Start Vagrant VM
# In prepared project directory, run following command:
#***********************************************************

# vagrant up --provider=libvirt

stacksofplates

@stacksofplates said in Vagrant and KVM:

What's the advantage to vagrant over just using Ansible with kickstart/preseed config?

Also I'm a moron. I've been using it for a couple years and Vagrant is much better than kickstarting.

black3dynamite

@stacksofplates said in Vagrant and KVM:

Vagrant is much better than kickstarting

Why is it better?

IRJ

@black3dynamite said in Vagrant and KVM:

@stacksofplates said in Vagrant and KVM:

Vagrant is much better than kickstarting

Why is it better?

Just try it and you'll see

stacksofplates

@black3dynamite said in Vagrant and KVM:

@stacksofplates said in Vagrant and KVM:

Vagrant is much better than kickstarting

Why is it better?

It's much faster and you can use tools like Ansible to provision the Vagrant boxes. It's just really flexible and fast.