BIG-IQ :: Add Hard Disk to VE
Ok, my Google-fu is lacking today. More coffee needed perhaps. But for the life of me, I cannot figure out how to add another disk (virtual hard drive) to my BIG-IQ VE. I don't want to expand the current disk... which is what I am finding all of the articles pertain to (and which I already know how to do). My desire is to add another HD (via HD2) to the VE. Any ideas on how to accomplish this? root@(big-iq)(cfg-sync Standalone)(Active)(/Common)(tmos) show sys hardware Sys::Hardware Chassis Information Chassis Name Chassis Type Maximum MAC Count 1 Registration Key - Hardware Version Information Name HD1 Type physical-disk Model Virtual disk Parameters -- -- Manufacturer VMware SerialNumber VMware-sda Size 95.00G Firmware Version 1.0 Media Type HDD Name HD2 Type physical-disk Model Virtual disk Parameters -- -- Manufacturer VMware SerialNumber VMware-sdb Size 95.00G Firmware Version 1.0 Media Type HDD It seems that the VE can see the drive... but I can't install to it: root@(big-iq)(cfg-sync Standalone)(Active)(/Common)(tmos) install sys software image BIG-IQ-6.1.0-0.0.1224.iso create-volume volume HD2.1 root@(big-iq)(cfg-sync Standalone)(Active)(/Common)(tmos) root@(big-iq)(cfg-sync Standalone)(Active)(/Common)(tmos) show sys software status ----------------------------------------------------------------------------------- Sys::Software Status Volume Product Version Build Active Status ----------------------------------------------------------------------------------- HD1.1 BIG-IQ 6.0.0 0.0.1674 yes complete HD2.1 BIG-IQ 6.1.0 0.0.1224 no failed (Can't find requested disk HD2.) I assume I am missing a step here. Thanks in advance! -R
Issue: Drive Mapping Over Split Tunnel VPN
Although this issue pops up from time to time (cannot map drives over vpn), we got a lot of complaints after upgrading from v13.1.3.6 to v13.1.4.1 (apm client v7185 to v7198). After uninstalling the v7198 client and then installing v7185 affected users can generally map their drives afterward. Although I'm testing the v7213 apm client as a replacement, I'd like to look at ways to reduce if not eliminate this wonky dns behavior altogether. What F5 tech support's seen in the client vpn diag file and which I've seen in a client Wireshark capture (looking at TCP 139 & 445 and UDP 137), is the client's trying to use its local DNS rather than that supplied by VPN to resolve the hostname for drive mapping. Of course, it's going to fail. Has anyone else had this issue? Some end users have trouble while others don't which makes me wonder if there's something on the client side that needs to be corrected. Thanks! Notes: The metric for the vpn interface is "1" whereas the local ethernet connection is "25."VPN: Drive mapping issue (v12 and v13)
I've received some user complaints regarding the inability to map a drive over VPN. When I test using a Win 7 laptop over DSL I can map the drive and see the subfolder beneath it, but cannot open that subfolder to get to anything inside of it (sub-subfolders you might say). When I try opening the folder there's a pause and then an error pop-up window that says the folder's not accessible and, "The network path was not found." This happens using the VPN on both v13.1.1 (build 0.0.4) and v12.1.3.6 (build 0.0.3, point release 6) F5s. However, when I connect to my lab VPN v14.0.0.2 (build 0.0.2 point release 2) it works fine. The VPN vserver and network access configs match between the v13 and v14 builds, but the lease pool is different between the v14 and v12/v13 VPNs. Until I move the lab VPN to its own VE F5 (it's sharing with other apps now) I cannot add that prod lease pool network to test it. Has anyone dealt with this before? Any ideas? Thanks!