In the process of prepping my test environment so I can upgrade from vSphere 6.1 to 6.5, one of the prerequisites is to first upgrade your VDP appliances to version 6.1.3 (6.1.3 is the only version of VDP that supports vSphere 6.5). In my environment I’ll be upgrading VDP from 6.1.2 to 6.1.3.
After downloading the ISO, changing my disks to dependant, creating a snapshot, and attaching the ISO to the VM. My VDP appliances would not recognize the ISO image, showing the dreaded: “To upgrade your VDP appliance, place connect a valid upgrade ISO image to the appliance.”.
I tried a few things, including trying the old “patch” that was issues for 6.1 when it couldn’t detect, unfortunately it didn’t help. I also tried to manually mount the virtual CD-Rom to the mountpoint but had no luck. The mountpoint /mnt/auto/cdrom is locked by the autofs service. If you try to modify these files (such as delete, create, etc…), you’ll encounter a bunch of errors and have no luck (permission denied, file and/or directory doesn’t exist, etc…).
Essentially the autofs service was not auto-mounting the virtual CD drive to the mount point.
To fix this:
- SSH in to the VDP appliance
- Run command “sudo su” to run commands as root
- Use vi to edit the auto.mnt file using command: “vi /etc/auto.mnt”
- At the end of the first line in the file, you will see “/dev/cdrom” (without quotation), change this to “/dev/sr0” (again, without quotation)
- Save the file (after editing the text, Ctrl+c, then type “:w” and enter which writes the file, then type “:q” then enter to quit vi.
- Reload the autofs config using command: “/etc/init.d/autofs reload”
- At the shell, run “mount” to show the active mountpoints, you’ll notice the ISO is now mounted after a few seconds.
- You can now initiate the upgrade. Start it.
- At 71%, autofs updates via a RPM, and the changes you made to the config are cleared. IMMEDIATELY edit the /etc/auto.mnt file again, change “/dev/cdrom” to “/dev/sr0” and save the file, and issue the command “/etc/init.d/autofs reload”. Do this as fast as possible.
- You’re good to go, the install will continue and take some time. The web interface will fail, and become unresponsive. Simply wait, and the vDP appliance will eventually shut down (in my case it took over 30 minutes after the web interface failed to reconnect, in a high performance environment for the vDP VM to shut down).
And done! Leave a comment!
[…] A note on a problem I dealt with during the upgrade process for vDP to version 6.1.3 (appliance does not detect mounted ISO image) can be found here: http://www.stephenwagner.com/?p=1107 […]
Good afternoon
I researched this problem and saw that as of version 6.1, to update the VDP, a new deploy is necessary
I’m doing this right now
Hi Rodrigo,
Yes, some versions require a complete new install to upgrade to 6.1. However this problem in the post is a problem when upgrading from 6.1.2 to 6.1.3.
Two separate problems, but thank you for the post as I’m sure numerous others are experiencing what you are.
Cheers,
Stephen
Good afternoon
The problem I referred to is exactly the migration from VDP 6.1.2 to 6.1.3.
A new installation is required to succeed
Hi Rodrigo,
Using the above steps in my post, you can upgrade and do not require a new installation.
I did not require a new installation, and was able to upgrade my appliance.
Hello.
Thank you for your help.
It happened exactly as reported by you in the post above.
Resolved, update executed successfully
Thanks again.
Hello, many thanks, but I suggest to create a link /dev/cdrom -> /dev/sr0 instead of edit that file.
This does not require to edit the file “quickly” at 71%, so the process will be more confortable 🙂
Hi Matthew,
Did you try or verify if the linking worked?
I was in a hurry to get my vDP appliance running, so I can’t remember if I tried that or not. I do remember though that the permissions on the mnt folder were odd (I think due to the automount service), I can’t remember if they opened up once the service was stopped.
It would be great to know if that worked though, as it may help out if this occurs in future upgrades.
Cheers
Thank your for sharing this GREAT write-up for the vDP in-place upgrade process.
The process is exactly as described, especially step 9 @ 71% part!
Thanks again Stephen.
Thank you , very helpful information,
Matthew suggestion works for us.
Good One!
Thanks for the tip!!!
Thanks for the hint. It got me on track to a more elegant solution to getting the auto mount back to work:
The issue with the missing CDR is actually in the udev configuration:
/etc/udev/rules.d/70-persistent-cd.rules
It assigns the wrong SCSI ID to /dev/cdrom
root@vdp1:~/#: cat /etc/udev/rules.d/70-persistent-cd.rules
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.
# VMware_IDE_CDR00 (pci-0000:00:07.1-scsi-4:0:0:0)
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-4:0:0:0″, SYMLINK+=”cdrom”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-4:0:0:0″, SYMLINK+=”cdrw”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-4:0:0:0″, SYMLINK+=”dvd”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-4:0:0:0″, SYMLINK+=”dvdrw”, ENV{GENERATED}=”1″
# VMware_IDE_CDR00 (pci-0000:00:07.1-scsi-1:0:0:0)
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-1:0:0:0″, SYMLINK+=”cdrom1″, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-1:0:0:0″, SYMLINK+=”cdrw1″, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-1:0:0:0″, SYMLINK+=”dvd1″, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-1:0:0:0″, SYMLINK+=”dvdrw1″, ENV{GENERATED}=”1″
You can simply get this fixed with
# rm /etc/udev/rules.d/70-persistent-cd.rules
# reboot
This will detect your CDR upon reboot and re-generate the file with the correct content.
root@vdp1:~/#: cat /etc/udev/rules.d/70-persistent-cd.rules
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.
# VMware_IDE_CDR00 (pci-0000:00:07.1-scsi-1:0:0:0)
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-1:0:0:0″, SYMLINK+=”cdrom”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-1:0:0:0″, SYMLINK+=”cdrw”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-1:0:0:0″, SYMLINK+=”dvd”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:07.1-scsi-1:0:0:0″, SYMLINK+=”dvdrw”, ENV{GENERATED}=”1″
The only thing I noticed: when auto mount is in effect you won’t be able to disconnect the ISO image while the appliance is running. Just shutdown the VDP appliance after the update, disconnect the ISO and boot it up again.
Stefan
Btw: this worked for me updating 6.1.3 to 6.1.4
# rm /etc/udev/rules.d/70-persistent-cd.rules
# reboot
Thanks for the solution, fixed issue while 6.1.4 to 6.1.5 upgrade
Thanks for the solution, fixed issue while 6.1.3 to 6.1.6 upgrade