Hi,
does anyone get the above error for the attached Vagrantfile, with: OS X 10.11.6 Vagrant 1.9.0 VirtualBox 5.1.10 r112026 (Qt5.6.2)
Reported here: https://github.com/marcindulak/vagrant-mariadb-galera-tutorial-centos7/pull/...
$ BOX='puppetlabs/centos-7.2-64-puppet' VERSION='1.0.1' vagrant up # works $ BOX='centos/7' VERSION='1610.01' vagrant up # fails $ BOX='centos/7' VERSION='1505.01' vagrant up # fails
["storageattach", :id, "--storagectl", "IDE Controller", "--port", 0, "--device", 1, "--type", "hdd", "--medium", "sdb.vdi"]
The following error was experienced: #<Vagrant::Errors::VBoxManageError: There was an error while executing `VBoxManage`, a CLI used by Vagrantfor controlling VirtualBox. The command and stderr is shown below.
Command: ["storageattach", "51e7f61f-2d6f-43dc-916b-1d8dad0ea505", "--storagectl", "IDE Controller", "--port", "0", "--device", "1", "--type", "hdd", "--medium", "sdb.vdi"]
Stderr: VBoxManage: error: Could not find a controller named 'IDE Controller'>
Please fix this customization and try again.
Hi,
I can't give it a try right now, but I would expect to see an error: I've already had to update my starter kit at the beginning of November, to address the name of the IDE controller having changed. [1] The proper solution would be to get the name of the IDE controller by parsing the output of "VBoxManage showvminfo", instead of hard-coding it.
I've never looked at the reasons for the name change - is "IDE controller" what you get when using Packer, instead of just "IDE"?
Best regards, Laurențiu
[1] https://github.com/lpancescu/cloud-instance-starter-kit/commit/eb259d0574d80...
On Sat, Dec 3, 2016 at 8:11 PM, Marcin Dulak marcin.dulak@gmail.com wrote:
Hi,
does anyone get the above error for the attached Vagrantfile, with: OS X 10.11.6 Vagrant 1.9.0 VirtualBox 5.1.10 r112026 (Qt5.6.2)
Reported here: https://github.com/marcindulak/vagrant-mariadb- galera-tutorial-centos7/pull/1
$ BOX='puppetlabs/centos-7.2-64-puppet' VERSION='1.0.1' vagrant up # works $ BOX='centos/7' VERSION='1610.01' vagrant up # fails $ BOX='centos/7' VERSION='1505.01' vagrant up # fails
["storageattach", :id, "--storagectl", "IDE Controller", "--port", 0, "--device", 1, "--type", "hdd", "--medium", "sdb.vdi"]
The following error was experienced: #<Vagrant::Errors::VBoxManageError: There was an error while executing `VBoxManage`, a CLI used by Vagrantfor controlling VirtualBox. The command and stderr is shown below.
Command: ["storageattach", "51e7f61f-2d6f-43dc-916b-1d8dad0ea505", "--storagectl", "IDE Controller", "--port", "0", "--device", "1", "--type", "hdd", "--medium", "sdb.vdi"]
Stderr: VBoxManage: error: Could not find a controller named 'IDE Controller'>
Please fix this customization and try again.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hi,
it looks to me that the reason for 'IDE Controller' missing may be actually in the box.ovf file, ~/.vagrant.d/boxes/centos-VAGRANTSLASH-7/1610.01/virtualbox/box.ovf. Comparing the box.ovf file from puppetlabs/centos-7.2-64-puppet to centos/7 I see many namespaces are missing in the Envelope of the latter.
So I took the box.ovf from 1.0.1 puppetlabs/centos-7.2-64-puppet copied it over centos/7, and modified it (attached) to match the 1610.01 centos/7 one. This consisted of replacing the vmdk name and uuids (diff vs. the original puppetlabs ovf attached), and 'IDE Controller' is again available. I'm on Ubuntu 14.04: $ vagrant --version Vagrant 1.9.0 $ vboxmanage --version 5.1.10r112026
All this may be still due to a mystery about 'IDE Controller' that we don't understand, and I may just be lucky, but it is worth trying on more platforms.
Another hint that something may be wrong with centos/7 box.ovf is the fact that the boot order reported by the original centos/7 box, and the Vagrantfile after the "workaround" of replacing 'IDE Controller' -> 'IDE' does not correspond to the boot order in box.ovf:
vboxmanage showvminfo --machinereadable <uuid> | grep 'boot.=' boot1="floppy" boot2="dvd" boot3="disk" boot4="none"
Moreover, the xml file is supposed to be human-readable, the box.ovf from centos/7 is not - please fix this when generating the new xml file.
Marcin
On Sat, Dec 3, 2016 at 9:34 PM, Laurențiu Păncescu lpancescu@gmail.com wrote:
Hi,
I can't give it a try right now, but I would expect to see an error: I've already had to update my starter kit at the beginning of November, to address the name of the IDE controller having changed. [1] The proper solution would be to get the name of the IDE controller by parsing the output of "VBoxManage showvminfo", instead of hard-coding it.
I've never looked at the reasons for the name change - is "IDE controller" what you get when using Packer, instead of just "IDE"?
Best regards, Laurențiu
[1] https://github.com/lpancescu/cloud-instance-starter-kit/commit/ eb259d0574d80e0c18aadfaad320b77a3d89b052
On Sat, Dec 3, 2016 at 8:11 PM, Marcin Dulak marcin.dulak@gmail.com wrote:
Hi,
does anyone get the above error for the attached Vagrantfile, with: OS X 10.11.6 Vagrant 1.9.0 VirtualBox 5.1.10 r112026 (Qt5.6.2)
Reported here: https://github.com/marcindulak/vagrant-mariadb-galera- tutorial-centos7/pull/1
$ BOX='puppetlabs/centos-7.2-64-puppet' VERSION='1.0.1' vagrant up # works $ BOX='centos/7' VERSION='1610.01' vagrant up # fails $ BOX='centos/7' VERSION='1505.01' vagrant up # fails
["storageattach", :id, "--storagectl", "IDE Controller", "--port", 0, "--device", 1, "--type", "hdd", "--medium", "sdb.vdi"]
The following error was experienced: #<Vagrant::Errors::VBoxManageError: There was an error while executing `VBoxManage`, a CLI used by Vagrantfor controlling VirtualBox. The command and stderr is shown below.
Command: ["storageattach", "51e7f61f-2d6f-43dc-916b-1d8dad0ea505", "--storagectl", "IDE Controller", "--port", "0", "--device", "1", "--type", "hdd", "--medium", "sdb.vdi"]
Stderr: VBoxManage: error: Could not find a controller named 'IDE Controller'>
Please fix this customization and try again.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hello Marcin,
On 04/12/16 04:52, Marcin Dulak wrote:
it looks to me that the reason for 'IDE Controller' missing may be actually in the box.ovf file,
perhaps I wasn't clear enough in my previous reply: there is no guarantee that a Vagrant box will have an IDE controller named "IDE Controller", and there never was. There is no mention of IDE in the Vagrant documentation[1], and, if I may quote from the VirtualBox User Manual, chapter 5, section 5.1, the last paragraph[2]:
| In general, you should avoid IDE unless it is the only controller | supported by your guest. Whether you use SATA, SCSI or SAS does not | make any real difference.
Using SATA has concrete performance benefits, both in disk performance on the guest, as well as in CPU and memory usage on the host. I'm already using SATA instead of IDE for my own experimental Vagrant boxes for VirtualBox, and switching our official boxes away from IDE is something I'm considering for the future. Such boxes wouldn't have any IDE controller at all.
My advice would be to change your Vagrantfile to find the storage controller used by the VirtualBox VM (you can write normal Ruby code inside a Vagrantfile); if that's too complex, an alternative would be to add an additional storage controller with a name of your choosing and attach you disk image there.
Best regards, Laurențiu
[1] https://www.vagrantup.com/docs/virtualbox/boxes.html [2] https://www.virtualbox.org/manual/ch05.html#harddiskcontrollers
On Mon, Dec 5, 2016 at 11:29 AM, Laurentiu Pancescu lpancescu@gmail.com wrote:
Hello Marcin,
On 04/12/16 04:52, Marcin Dulak wrote:
it looks to me that the reason for 'IDE Controller' missing may be actually in the box.ovf file,
perhaps I wasn't clear enough in my previous reply: there is no guarantee that a Vagrant box will have an IDE controller named "IDE Controller", and there never was. There is no mention of IDE in the Vagrant documentation[1], and, if I may quote from the VirtualBox User Manual, chapter 5, section 5.1, the last paragraph[2]:
| In general, you should avoid IDE unless it is the only controller
| supported by your guest. Whether you use SATA, SCSI or SAS does not | make any real difference.
Just imagine how many people may be affected by 'IDE Controller' suddenly missing and applying the workaround by changing the name to 'IDE'. Over the years the name has changed several times in some setups https://github.com/xdissent/ievms/issues/204 and one may expect that sooner or later the 'IDE Controller' will reappear causing troubles again.
I'm saying that box.ovf provided by centos vagrant boxes may be possibly incorrect, as the configuration is not read. Please verify this. The box.ovf contains 'IDE Controller' - maybe correcting box.ovf is enough to bring the 'IDE Controller' back.
Using SATA has concrete performance benefits, both in disk performance on
the guest, as well as in CPU and memory usage on the host. I'm already using SATA instead of IDE for my own experimental Vagrant boxes for VirtualBox, and switching our official boxes away from IDE is something I'm considering for the future. Such boxes wouldn't have any IDE controller at all.
My advice would be to change your Vagrantfile to find the storage controller used by the VirtualBox VM (you can write normal Ruby code inside a Vagrantfile); if that's too complex, an alternative would be to add an additional storage controller with a name of your choosing and attach you disk image there.
adding a custom controller presupposes that there is no other controller of the same type already present, so for example one cannot add 'IDE Controller' if an 'IDE' of type ide is already present. Moreover testing for the presence of the controller is not elegant as it involves overriding vagrant methods: https://gist.github.com/leifg/4713995 and it would need to be worked out for all possible workflows like reloading the VM https://github.com/mitchellh/vagrant/issues/6682 with disks shareable between different VMs in a multi-machine environment.
Best regards,
Marcin
Best regards, Laurențiu
[1] https://www.vagrantup.com/docs/virtualbox/boxes.html [2] https://www.virtualbox.org/manual/ch05.html#harddiskcontrollers
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Mon, Dec 5, 2016 at 12:05 PM, Marcin Dulak marcin.dulak@gmail.com wrote:
Just imagine how many people may be affected by 'IDE Controller' suddenly missing and applying the workaround by changing the name to 'IDE'.
I'm saying that box.ovf provided by centos vagrant boxes may be possibly incorrect, as the configuration is not read. Please verify this. The box.ovf contains 'IDE Controller' - maybe correcting box.ovf is enough to bring the 'IDE Controller' back.
I noticed today that I see "IDE controller" again in VirtualBox, instead of just "IDE" like in November. This is exactly the same box, with the same .ovf file; the only change during this time is that I upgraded from VirtualBox 5.0.28 to 5.0.30. I remember having had issues with the Debian Vagrant images, which are exported from VirtualBox 5.1.x (the network cable was marked as not connected on 5.0.x, so Vagrant wasn't able to ssh in). I see "OVF: improve importing of VMs created by VirtualBox https://www.virtualbox.org/wiki/VirtualBox 5.1" in the changelog of VirtualBox 5.0.28 - perhaps this introduced a regression in parsing the OVF files and it was fixed in 5.0.30?
https://www.virtualbox.org/wiki/Changelog-5.0#v28
Best regards, Laurențiu
On Wed, Dec 14, 2016 at 8:23 PM, Laurențiu Păncescu lpancescu@gmail.com wrote:
On Mon, Dec 5, 2016 at 12:05 PM, Marcin Dulak marcin.dulak@gmail.com wrote:
Just imagine how many people may be affected by 'IDE Controller' suddenly missing and applying the workaround by changing the name to 'IDE'.
I'm saying that box.ovf provided by centos vagrant boxes may be possibly incorrect, as the configuration is not read. Please verify this. The box.ovf contains 'IDE Controller' - maybe correcting box.ovf is enough to bring the 'IDE Controller' back.
I noticed today that I see "IDE controller" again in VirtualBox, instead of just "IDE" like in November. This is exactly the same box, with the same .ovf file; the only change during this time is that I upgraded from VirtualBox 5.0.28 to 5.0.30. I remember having had issues with the Debian Vagrant images, which are exported from VirtualBox 5.1.x (the network cable was marked as not connected on 5.0.x, so Vagrant wasn't able to ssh in). I see "OVF: improve importing of VMs created by VirtualBox https://www.virtualbox.org/wiki/VirtualBox 5.1" in the changelog of VirtualBox 5.0.28 - perhaps this introduced a regression in parsing the OVF files and it was fixed in 5.0.30?
I'm still thinking there can be something in centos box.ovf that makes it vulnerable to such changes. Someone familiar with the specification should be able to comment on this. In the meantime I created an issue with vagrant: https://github.com/mitchellh/vagrant/issues/8105 Are you getting the correct boot order from centos/7 as described in the vagrant issue?
Best regards,
Marcin
Best regards, Laurențiu
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 15/12/16 00:18, Marcin Dulak wrote:
I'm still thinking there can be something in centos box.ovf that makes it vulnerable to such changes. Someone familiar with the specification should be able to comment on this. In the meantime I created an issue with vagrant: https://github.com/mitchellh/vagrant/issues/8105 Are you getting the correct boot order from centos/7 as described in the vagrant issue?
No, I get the default boot order: boot1="floppy" boot2="dvd" boot3="disk" boot4="none"
I see other settings imported correctly by VirtualBox (memory, cpus, storage controllers, network), and it doesn't display any error or warning if I import it manually:
$ VBoxManage import ~/.vagrant.d/boxes/centos-VAGRANTSLASH-7/1610.01/virtualbox/box.ovf 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Interpreting /Users/laur/.vagrant.d/boxes/centos-VAGRANTSLASH-7/1610.01/virtualbox/box.ovf... OK. Disks: vmdisk1 42949672960 -1 http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized centos-7-1-1.x86_64.vmdk -1 -1
Virtual system 0: 0: Suggested OS type: "RedHat_64" (change with "--vsys 0 --ostype <type>"; use "list ostypes" to list all possible values) 1: Suggested VM name "centos-7-1-1.x86_64" (change with "--vsys 0 --vmname <name>") 2: Number of CPUs: 1 (change with "--vsys 0 --cpus <n>") 3: Guest memory: 512 MB (change with "--vsys 0 --memory <MB>") 4: Network adapter: orig NAT, config 3, extra type=NAT 5: IDE controller, type PIIX4 (disable with "--vsys 0 --unit 5 --ignore") 6: IDE controller, type PIIX4 (disable with "--vsys 0 --unit 6 --ignore") 7: Hard disk image: source image=centos-7-1-1.x86_64.vmdk, target path=/Users/laur/VirtualBox VMs/centos-7-1-1.x86_64/centos-7-1-1.x86_64.vmdk, controller=5;channel=0 (change target path with "--vsys 0 --unit 7 --disk path"; disable with "--vsys 0 --unit 7 --ignore") 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Successfully imported the appliance.
The Debian images don't even bother to specify a boot order, I doubt it makes a difference in practice. But if you think it's important, you can file a bug report against Image Factory (imgfac.org) - such a change would have to be made upstream.
Best regards, Laurențiu
On Thu, Dec 15, 2016 at 11:26 AM, Laurentiu Pancescu lpancescu@gmail.com wrote:
On 15/12/16 00:18, Marcin Dulak wrote:
I'm still thinking there can be something in centos box.ovf that makes it vulnerable to such changes. Someone familiar with the specification should be able to comment on this. In the meantime I created an issue with vagrant: https://github.com/mitchellh/vagrant/issues/8105 Are you getting the correct boot order from centos/7 as described in the vagrant issue?
No, I get the default boot order: boot1="floppy" boot2="dvd" boot3="disk" boot4="none"
I see other settings imported correctly by VirtualBox (memory, cpus, storage controllers, network), and it doesn't display any error or warning if I import it manually:
$ VBoxManage import ~/.vagrant.d/boxes/centos-VAGR ANTSLASH-7/1610.01/virtualbox/box.ovf 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Interpreting /Users/laur/.vagrant.d/boxes/centos-VAGRANTSLASH-7/1610.01/v irtualbox/box.ovf... OK. Disks: vmdisk1 42949672960 -1 http://www.vmware.com/interfac es/specifications/vmdk.html#streamOptimized centos-7-1-1.x86_64.vmdk -1 -1
Virtual system 0: 0: Suggested OS type: "RedHat_64" (change with "--vsys 0 --ostype <type>"; use "list ostypes" to list all possible values) 1: Suggested VM name "centos-7-1-1.x86_64" (change with "--vsys 0 --vmname <name>") 2: Number of CPUs: 1 (change with "--vsys 0 --cpus <n>") 3: Guest memory: 512 MB (change with "--vsys 0 --memory <MB>") 4: Network adapter: orig NAT, config 3, extra type=NAT 5: IDE controller, type PIIX4 (disable with "--vsys 0 --unit 5 --ignore") 6: IDE controller, type PIIX4 (disable with "--vsys 0 --unit 6 --ignore") 7: Hard disk image: source image=centos-7-1-1.x86_64.vmdk, target path=/Users/laur/VirtualBox VMs/centos-7-1-1.x86_64/centos-7-1-1.x86_64.vmdk, controller=5;channel=0 (change target path with "--vsys 0 --unit 7 --disk path"; disable with "--vsys 0 --unit 7 --ignore") 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Successfully imported the appliance.
The Debian images don't even bother to specify a boot order, I doubt it makes a difference in practice. But if you think it's important, you can file a bug report against Image Factory (imgfac.org) - such a change would have to be made upstream.
https://github.com/redhat-imaging/imagefactory/issues/393
Best regards, Laurențiu _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 04/12/16 03:52, Marcin Dulak wrote:
Moreover, the xml file is supposed to be human-readable, the box.ovf from centos/7 is not - please fix this when generating the new xml file.
This is an artifact of the s/w used in this place - we build with Image Factory. Also, I dont think xml is really a good human-readable format, but I would recommend using an xml parser to pretty'fy it as needed.
Regards
-
Karanbir Singh -
Laurențiu Păncescu -
Marcin Dulak