Tag: vmware

Posted on

VMWare: Connect a USB Device to a VM in ESXi

Connect a USB Device to a VM in ESXi

This article describes how to connect a USB device to a vm in ESXi – for example a storage device, camera, USB handset etc. etc. Whilst previously not possible, since ESXi 5.0 this is now reality, much to the relief of many, many people!

1. Add a VM USB Controller

Firstly, your VM needs to have a USB controller; this is added as standard to most new virtual machines but if one is not present then we need to add it – open your VM settings and click the “Add” button:

Choose “USB Controller” and click “Next”; when prompted for the controller type, choose “EHCI+UHCI” for best compatibility or “xHCI” for USB 3.0 support. Note: xHCI USB 3.0 is only supported with Linux VMs currently – see this documentation for further details.

Once complete, you should see something akin to the following in your VM properties:

Excellent! Now let’s add a USB device to our VM:

2. Add a USB Device to the VM

Insert a USB device into one of the ports on your ESXi host. For this example I have used a Sandisk storage device. Open your VM machine properties and once again, click on “Add Hardware.” This time, choose “USB Device”: if your device has been correctly recognised by your ESXi host then it will show up on the next screen:

     —–>      

Click “Next,” “Finish” and lastly “OK” to complete the reconfiguration of the VM. Congratulations! Your USB device is now added.

3. Mount the Storage Device (*nix Only)

If you have just added a storage device to a Windows VM then you should see it pop up in explorer shortly. If you are on Linux / Unix / FreeBSD etc then you will need to mount your drive. Firstly we will need to find out what ID it has been assigned by the operating system – the easiest way to do this is to check the last entries in “dmesg” after adding the device:


[1546647.937025] usb 1-1: new high-speed USB device number 10 using ehci_hcd
[1546648.363146] usb 1-1: New USB device found, idVendor=0781, idProduct=5408
[1546648.363152] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1546648.363157] usb 1-1: Product: U3 Titanium
[1546648.363160] usb 1-1: Manufacturer: SanDisk Corporation
[1546648.363164] usb 1-1: SerialNumber: 000015E96A63058A
[1546648.364943] scsi11 : usb-storage 1-1:1.0
[1546649.369282] scsi 11:0:0:0: Direct-Access SanDisk U3 Titanium 3.21 PQ: 0 ANSI: 2
[1546649.373306] scsi 11:0:0:1: CD-ROM SanDisk U3 Titanium 3.21 PQ: 0 ANSI: 2
[1546649.374503] sd 11:0:0:0: Attached scsi generic sg5 type 0
[1546649.399562] sd 11:0:0:0: [sde] 8015505 512-byte logical blocks: (4.10 GB/3.82 GiB)
[1546649.403475] sr1: scsi3-mmc drive: 8x/40x writer xa/form2 cdda tray
[1546649.403817] sr 11:0:0:1: Attached scsi CD-ROM sr1
[1546649.404505] sr 11:0:0:1: Attached scsi generic sg6 type 5
[1546649.417867] sd 11:0:0:0: [sde] Write Protect is off
[1546649.417873] sd 11:0:0:0: [sde] Mode Sense: 03 00 00 00
[1546649.422634] sd 11:0:0:0: [sde] No Caching mode page present
[1546649.422800] sd 11:0:0:0: [sde] Assuming drive cache: write through
[1546649.451967] sd 11:0:0:0: [sde] No Caching mode page present
[1546649.452074] sd 11:0:0:0: [sde] Assuming drive cache: write through
[1546649.480289] sde: sde1
[1546649.506074] sd 11:0:0:0: [sde] No Caching mode page present
[1546649.506184] sd 11:0:0:0: [sde] Assuming drive cache: write through
[1546649.506332] sd 11:0:0:0: [sde] Attached SCSI removable disk

The most relevant part is the line reading “[1546649.480289] sde: sde1” – this tells us that the disk has been assigned the descriptor “sde” and the single partition on it “sde1“.

From here we can do a standard *nix mount command and access it normally – in this example I am mounting the newly added sde1 device to a pre-existing directory “/mnt/usb”:

root@merlin:~# mount /dev/sde1 /mnt/usb

We can check the operation has been successful by issuing the “mount” command on its own

root@merlin:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
...
...
...
/dev/sde1 on /mnt/usb type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,shortname=mixed,errors=remount-ro)

Job done! If this has been of interest to you, check out some of the other articles in the VMWare category!

Related posts:

Posted on

f5 VE on ESXi: “The requested media for interface 1.1 is invalid.”

This article addresses the following error: “The requested media for interface 1.1 is invalid” when using the f5 virtual edition on ESXi.

Once possible reason for this error is mentioned under “Known Issues” in the release notes for 11.x e.g. : http://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-ve-11-4-0.print.html

The entry reads as follows:

ID 352856 “If an SCF is migrated between BIG-IP VE running on non-similar hypervisor software, a validation error may prevent configuration loading. Loading the configuration … BIGpipe interface creation error: 01070318:3: “”The requested media for interface 1.1 is invalid.”” When this condition is encountered on BIG-IP Virtual Edition, configuration may be fixed for import by removing the entire line that contains “”media fixed”” statements for each interface.”

If however, like me, you cannot find the “media fixed” anywhere in your bigip_base.conf file then it is most likely to be an issue with the vmxnet3 network adapters that are deployed by default.

My management adapter, also vmxnet3, came up fine but the other 1.1, 1.2 and 1.3 interfaces remained uninitialised and any attempts to edit just threw the error above.

My solution was to change the adapter types in the .vmx file for the virtual machine:

1. Shut down the machine2. SSH / console into your ESXi host and change directory to /vmfs/volumes/<datastore_name>/<vm_directory>

 

 

 

 

 

3. Use the “vi” command to edit the <your_vm>.vmx file and change the “vmxnet3” entries to “e1000.” Note: you can generally leave the first interface (management) as vmxnet3.

 

 

 

 

 

 

 

 

 

 

4. Save the file and start up your machine – you should now be able to initialise and edit your interfaces under “Network” -> “Interfaces”

Job done, let me know if this works / doesn’t work for you!

Related posts:

Posted on

VMWare: How to Change the ESXi System Time and HW Clock on the CLI

This article details how to change the ESXi system time and HW clock on your ESXi hypervisor machine via the CLI.

Ideally we want to use NTP to set the system time but if your clock is too far out from the actual time then this will fail and you may see something like this in the syslog file:
ntpd[263140]: synchronized to <46.249.47.127>, stratum 1
ntpd[263140]: time correction of <54423> seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
[info 'ha-eventmgr'] Event 91 : NTP daemon stopped. Time correction 1206 > 1000 seconds. Manually set the time and restart ntpd.
The situation was that my VMs were synchronising their time to the ESXi host’s on every reboot, meaning that some important secure system services (in Windows 2008 in particular) were not starting. There isn’t the facility to do this on the DCUI (Direct Console User Interface – the yellow and black screen) so here’s the gen on how to achieve this using the command line.

My first endeavours were using the “date” command, as I’m used to doing in Linux, unfortunately these were met with the error:

~ # date 100410112014
date: can't set date: Function not implemented
Sat Oct  4 10:11:00 UTC 2014

OK, it’s being pernickety so lets use the “-s” flag to SET the time:

~ # date -s 041010112014
date: Setting date not supported; use <esxcli system time set>

Now we’re getting somewhere. The command takes the following parameters:

Usage: esxcli system time set [cmd options]
Description:
set                   Set the system clock time. Any missing parameters will default to the current time
Cmd options:
-d|--day=<long>       Day
-H|--hour=<long>      Hour
-m|--min=<long>       Minute
-M|--month=<long>     Month
-s|--sec=<long>       Second
-y|--year=<long>      Year

So, to set the system time to 10th April 2014, 10:18 (am):
~ # esxcli system time set -d 10 -H 10 -m 18 -M 04 -y 2014

Also, make sure that we also set the hardware clock time as the system time will revert to this on a reboot:

~ # esxcli hardware clock set -d 10 -H 10 -m 18 -M 04 -y 2014     <- sets the hardware clock to 10th April 2014, 10:18 (am)

To check the hardware and system time we can use the following commands:

esxcli hardware clock get
esxcli system time get

Job done! Now move on to setting the time automatically using NTP.

Related posts:

Exit mobile version
%%footer%%