Is it possible to assign a raw disk?

[windowsrefund]

Hello,

I've read through the documentation but am still not clear on whether it will be possible to assign a raw disk. Before considering Vagrant, I was able to achieve this by editing my node's XML (where <UNIQUE_ID> represents a unique disk on my system...

<disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/disk/by-id/<UNIQUE_ID>'/>
      <target dev='vdb' bus='virtio'/>
...

Basically, the node sees and can use /dev/vdb which is the unique raw disk. Thanks in advance for any assistance.

[electrofelix]

@windowsrefund not as it currently stands. Basically vagrant-libvirt is taking the additional disks and iterating over the using the template at https://github.com/vagrant-libvirt/vagrant-libvirt/blob/master/lib/vagrant-libvirt/templates/domain.xml.erb#L128-L152.

No reason that couldn't be updated to support additional options, would need some adjustment to ensure defaults applied for the current standard approach of adding disks, or if support for a callback was added for amending the domain XML before creating the domain so anything could be added as needed by consumers it would probably make fulfilling any custom requirements such as this possible.

[blecx]

I just digged in the code to find who is filling out the template:

vagrant-libvirt/lib/vagrant-libvirt/config.rb

Line 619 in 0739104

def storage(storage_type, options = {})

It took this example

Vagrant.configure("2") do |config|
  config.vm.provider :libvirt do |libvirt|
    libvirt.storage :file, :size => '20G'
    libvirt.storage :file, :size => '40G', :bus => 'scsi', :type => 'raw', :discard => 'unmap', :detect_zeroes => 'on'
  end
end

and grepped in the code for libvirt.storage resolves to (Defined in lib/vagrant-libvirt/config.rb) def storage(storage_type, options = {})... This is an if - cascade that calles handler, for example for disks def _handle_disk_storage(options = {}) ...
So this seems to create an object that will be pasted into `@disks << disk.

If I got it right with this very little ruby knowlege, it requires a new template and a handler for that. So just adopting the existing template as I tought above is not good enough and will not work.

What do you think?

Thank you for any help, Stefan

[electrofelix]

Yes, essentially if you look at the following code, there needs to be additional options added along with sensible defaults that match the existing hardcoded values in the template.

vagrant-libvirt/lib/vagrant-libvirt/config.rb

Lines 664 to 680 in 0739104

	disk = {
	device: options[:device],
	type: options[:type],
	size: options[:size],
	path: options[:path],
	bus: options[:bus],
	cache: options[:cache] || 'default',
	allow_existing: options[:allow_existing],
	shareable: options[:shareable],
	serial: options[:serial],
	io: options[:io],
	copy_on_read: options[:copy_on_read],
	discard: options[:discard],
	detect_zeroes: options[:detect_zeroes],
	pool: options[:pool], # overrides storage_pool setting for additional disks
	wwn: options[:wwn],
	}

followed by an update to the template at:

vagrant-libvirt/lib/vagrant-libvirt/templates/domain.xml.erb

Lines 116 to 152 in 0739104

	<% @domain_volumes.each do |volume| -%>
	<disk type='file' device='disk'>
	<driver name='qemu' type='qcow2' <%=
	@disk_driver_opts.empty? ? "cache='#{volume[:cache]}'" :
	@disk_driver_opts.reject { |k,v| v.nil? }
	.map { |k,v| "#{k}='#{v}'"}
	.join(' ') -%>/>
	<source file='<%= volume[:path] %>'/>
	<%# we need to ensure a unique target dev -%>
	<target dev='<%= volume[:dev] %>' bus='<%= volume[:bus] %>'/>
	</disk>
	<% end -%>
	<%# additional disks -%>
	<% @disks.each do |d| -%>
	<disk type='file' device='disk'>
	<driver name='qemu' type='<%= d[:type] %>' <%=
	d.select { |k,_| [:cache, :io, :copy_on_read, :discard, :detect_zeroes].include? k }
	.reject { |k,v| v.nil? }
	.map { |k,v| "#{k}='#{v}'"}
	.join(' ')
	-%>/>
	<source file='<%= d[:absolute_path] %>'/>
	<target dev='<%= d[:device] %>' bus='<%= d[:bus] %>'/>
	<% if d[:shareable] %>
	<shareable/>
	<% end %>
	<% if d[:serial] %>
	<serial><%= d[:serial] %></serial>
	<% end %>
	<% if d[:wwn] %>
	<wwn><%= d[:wwn] %></wwn>
	<% end %>
	<%# this will get auto generated by Libvirt
	<address type='pci' domain='0x0000' bus='0x00' slot='???' function='0x0'/>
	-%>
	</disk>
	<% end -%>

To support setting the new options as needed

[electrofelix]

Unfortunately it seems we made a mistake in using type for the driver type rather than using driver_type and keeping type for the disk type. But otherwise, yes your suggested changes for the disk XML are along the right lines, it's just the addition of the options for the storage handler that are needed as well as possible alternative defaults for handling cdroms as well.

Bit rusty on host devices and the corresponding XML, but if you are using one directly, it might be that either there is an easy way to determine if the path is a device or not, in which case it's possible to have some options adjusted without needing the Vagrantfile to provide additional information. Potentially there may be issues around permissions with such devices.

[blecx]

First,

thank you very much for this imediate reply. So it seems that it needs some work on the code. But for doing so, I need to learn some more ruby, - as well as learning how to build and test vagrant-libvirt. So it will be a "long run".

So getting better with ruby is not that big deal. Any advice how to build and test vagrant-libvirt?

Thank you very much,

Stefan
PS. In the mean time i can help with triggers, but this really an ugly work around and only works on a single node Vagrant file, since triggers are all global. And it only works with vagrand up/vagrant destroy, - no halt etc.
If it's of interest I can paste here an example

[electrofelix]

The general development steps are at https://github.com/vagrant-libvirt/vagrant-libvirt#development, I personally use rvm to manage different ruby versions and also to be able to install gems in an isolated manner so that I can easily clean up afterwards by simply calling rvm gemset delete <name>.

Documentation for triggers appears to suggest that it covers halt on a per machine type trigger

• https://www.vagrantup.com/docs/triggers/usage