Bug#989462: Info received (About bumping Vagrant box disk image to 1TB)
Thanks for mapping it out. Do you have any contact to upstream? If so, could you request the new release? I can update the package. Emmanuel Kasper: Hi I took some time to revisit this bug in regards to vagrant libvirt developments. I see vagrant-libvirt upstream has merged in virtio-scsi support, which we needed for discard (https://github.com/vagrant-libvirt/vagrant-libvirt/pull/692/commits) So the next steps should be: - upstream to release a new version of libvirt with virtio-scsi support - Debian to package it - change the libvirt vagrant box to use virtio-scsi. It should be enough to set the disk bus to scsi then vagrant-libvirt will set the controller type to virtio-iscsi by default - add the `discard` option so that deleted disk blocks in the VM are also deleted in the file disk image - finally bump the disk image size in the build process
Bug#989462: Info received (About bumping Vagrant box disk image to 1TB)
On 2/3/22 22:58, Hans-Christoph Steiner wrote:
> - you add to your pull request a change of the virtualized disk
> controller from virtio-blk to virtio-scsi and to the default libvirt
> vagrantfile the "unmap" option so that deletion of blocks in the guest
> are propagated om host storage
I looked into this a bit more. These feature weren't added to
vagrant-libvirt until 0.4.0, so no stable Debian package of
vagrant-libvirt could support this yet. Debian/testing has 0.7.0, and a
backport to stable would be possible. I guess a lot of people just use
`vagrant plugin install ...`. It might be possible to make it work with
older vagrant-libvirt versions by using a hack like this:
https://github.com/vagrant-libvirt/vagrant-libvirt/pull/692#issuecomment-922329049
There is a little more info here:
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/999#issuecomment-487728207
```
ENV['VAGRANT_EXPERIMENTAL'] = 'typed_triggers'
require 'open3'
Vagrant.configure('2') do |config|
...
config.vm.provider :libvirt do |lv, config|
lv.storage :file, :size => '3G', :device => 'sda', :bus => 'scsi',
:discard => 'unmap', :cache => 'unsafe'
config.trigger.before
:'VagrantPlugins::ProviderLibvirt::Action::StartDomain', type: :action
do |trigger|
trigger.ruby do |env, machine|
stdout, stderr, status = Open3.capture3(
'virt-xml', machine.id,
'--edit', 'type=scsi',
'--controller', 'model=virtio-scsi')
if status.exitstatus != 0
raise "failed to run virt-xml to modify the controller model.
status=#{status.exitstatus} stdout=#{stdout} stderr=#{stderr}"
end
end
end
...
end
end
```
Hi Hans-Christoph
I had a look at this and it looks like although we can now set via the
`disk_driver` options to use `discard` when a SCSI controller is
choosed, it is still not possible to set the SCSI controller `model` to
virtio-scsci via a vagrant-libvirt option. Without a virtio-scsi SCSI
controller I/O will be 10 times slower.
We could actually force the controller model and the discard option
manually in the Vagrantfile shipped by the box using the hack/workaround
you pasted above. But the :action trigger used there is an experimental
feature, requiring VAGRANT_EXPERIMENTAL="typed_triggers" to be set.
So this is too much of an over stretch here at the momment.
When time allows, I will now try to use a box with virtio-fs and see how
it works against NFS as this seem to be way the way forward (maybe use
virtio-fs instead of NFS too by default for libvirt too)
Emmanuel
--
You know an upstream is nice when they even accept m68k patches.
- John Paul Adrian Glaubitz, Debian OpenJDK maintainer
Bug#989462: Info received (About bumping Vagrant box disk image to 1TB)
> - you add to your pull request a change of the virtualized disk
> controller from virtio-blk to virtio-scsi and to the default libvirt
> vagrantfile the "unmap" option so that deletion of blocks in the guest
> are propagated om host storage
I looked into this a bit more. These feature weren't added to vagrant-libvirt
until 0.4.0, so no stable Debian package of vagrant-libvirt could support this
yet. Debian/testing has 0.7.0, and a backport to stable would be possible. I
guess a lot of people just use `vagrant plugin install ...`. It might be
possible to make it work with older vagrant-libvirt versions by using a hack
like this:
https://github.com/vagrant-libvirt/vagrant-libvirt/pull/692#issuecomment-922329049
There is a little more info here:
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/999#issuecomment-487728207
```
ENV['VAGRANT_EXPERIMENTAL'] = 'typed_triggers'
require 'open3'
Vagrant.configure('2') do |config|
...
config.vm.provider :libvirt do |lv, config|
lv.storage :file, :size => '3G', :device => 'sda', :bus => 'scsi', :discard
=> 'unmap', :cache => 'unsafe'
config.trigger.before
:'VagrantPlugins::ProviderLibvirt::Action::StartDomain', type: :action do |trigger|
trigger.ruby do |env, machine|
stdout, stderr, status = Open3.capture3(
'virt-xml', machine.id,
'--edit', 'type=scsi',
'--controller', 'model=virtio-scsi')
if status.exitstatus != 0
raise "failed to run virt-xml to modify the controller model.
status=#{status.exitstatus} stdout=#{stdout} stderr=#{stderr}"
end
end
end
...
end
end
```
