Remote-Viewer

Why can’t I seem to remember that I seem to need remote-viewer for two-headed VM’s? URL format: spice://host:port — for me that means localhost:5900. Need coffee…

The Qemu adventure continues

The PPA didn’t do so well on my notebook — or at least with my Windows Guest VM. It now reboots in a continuous loop. I can start it with the qemu that I previously compiled, but not with the PPA version. May try installing a Linux guest and see if it works with the one out of the PPA. That is really the only type of guest I had tried with the PPA version… Ah well, I am getting to be an old hand at installing Ubuntu… Worst case is I get to do that again.

Taking the plunge and adding a ppa for QEMU 2.1 and its cohorts…

Because I’m basically a pretty lazy admin (and the repository looks really attractive), I’m going to go ahead and add the following to my /etc/apt/sources.list on my notebook for further testing with a Windows guest.

deb http://ppa.launchpad.net/jacob/virtualisation/ubuntu trusty main
deb-src http://ppa.launchpad.net/jacob/virtualisation/ubuntu trusty main

This is the one I mentioned in an earlier post. It is maintained by Jacob Zimmermann who appears to know what he’s doing. Which definitely puts him well ahead of me…

This looks like what I will be getting with this…

The following packages were automatically installed and are no longer required:
libgtk-vnc-1.0-0 python-appindicator python-gtk-vnc
Use ‘apt-get autoremove’ to remove them.
The following packages will be REMOVED:
qemu-keymaps
The following NEW packages will be installed:
gir1.2-gtk-vnc-2.0 gir1.2-libvirt-glib-1.0 gir1.2-spice-client-glib-2.0
gir1.2-spice-client-gtk-3.0 libvirt-glib-1.0-0 python-ipaddr qemu qemu-user
qemu-user-binfmt
The following packages will be upgraded:
libcgmanager0 libcgmanager0:i386 libvirt-bin libvirt0 python-libvirt
qemu-system qemu-system-arm qemu-system-common qemu-system-mips
qemu-system-misc qemu-system-ppc qemu-system-sparc qemu-system-x86
qemu-utils virt-manager virtinst
16 upgraded, 9 newly installed, 1 to remove and 0 not upgraded.
Need to get 32.4 MB of archives.
After this operation, 70.9 MB of additional disk space will be used.

KVM/QEMU USB 3.0 Passthrough Update

Installed onto a sacrificial lamb machine…

Created a linux guest (both host and guest are Ubuntu 14.04 trusty)

using

-device nec-usb-xhci,id=xhci \
-device usb-host,bus=xhci.0,vendorid=0x13fe,productid=0x5500

seemed to work with a custom compiled qemu on the Linux Guest

I found a virtualization ppa that I also tested at https://launchpad.net/~jacob/+archive/ubuntu/virtualisation
It is credited to Jacob Zimmermann, but I’m not sure if this is a personal project of his (or something more official). I added it on my test system and things worked well (including virtual manager). Not sure I’m comfortably relying on it for anything production wise, but it was darned handy for testing! (So thank you Jacob Zimmermann whoever you are!)

Since I am sure I had tried this recipe with my previous Windows 7 guest, I am going back to revisit it and see if I can make it work with different Windows drivers. Maybe I’ve been fighting an issue on the client side rather than with qemu…

Qemu 2.1 USB 3.0 PassThrough Fails (Hall of Shame) Ubuntu 14.04 Windows 7 Guest

I guess I just need to suck it up and setup a Linux guest to see what (if any) parameters work and to rule out driver issues on the guest…

Windows 7 guest drivers from here: http://www.driverscape.com/manufacturers/renesas/usb  (NEC 3.0 Controller)

Using Ubuntu 14.04 with a custom complied qemu 2.1 with all the defaults (except PREFIX=/opt/qemu)

With this (uncommented part),

I get:

qemu-system-x86_64: hw/usb/hcd-xhci.c:896: xhci_events_update: Assertion `intr->er_full’ failed.
Aborted (core dumped)

also from dmesg:

[16948.896976] usb 4-4: reset SuperSpeed USB device number 10 using xhci_hcd
[16948.914304] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88023580f600

Tail end of qemu invocation shell script (showing previous ideas).

-device nec-usb-xhci,id=xhci,bus=pci.0,addr=0x14.0 \
-device usb-host,bus=xhci.0,vendorid=0x13fe,productid=0x5100
#-device usb-host,bus=xhci.0,hostbus=4,hostport=10
#-device usb-host,bus=xhci.0,vendorid=0x13fe,productid=0x5100
#below changes everytime I remove/reinsert drive
#-device usb-host,bus=xhci.0,hostbus=3,hostport=11
#below failed with core dump usb_handle_packet assertion failed
#-device usb-host,vendorid=0x13fe,productid=0x5100

#vfio-bind 0000:00:14.0
#-device vfio-pci,host=14:00.0,bus=pcie.0
#-device usb-storage,bus=xhci.4,port=2
#-device usb-host,vendorid=0x0480,productid=0x200

-device nec-usb-xhci,id=xhci,bus=pci.0,addr=0x14.0 \
-device usb-host,bus=xhci.0,vendorid=0x13fe,productid=0x5100
#-device usb-host,bus=xhci.0,hostbus=4,hostport=10
#-device usb-host,bus=xhci.0,vendorid=0x13fe,productid=0x5100
#below changes everytime I remove/reinsert drive
#-device usb-host,bus=xhci.0,hostbus=3,hostport=11
#below failed with core dump usb_handle_packet assertion failed
#-device usb-host,vendorid=0x13fe,productid=0x5100

#vfio-bind 0000:00:14.0
#-device vfio-pci,host=14:00.0,bus=pcie.0
#-device usb-storage,bus=xhci.4,port=2
#-device usb-host,vendorid=0x0480,productid=0x200

Next steps, maybe I should try this with a Linux guest to test the parameters and rule out driver issues?

Virtual Box UUID grr….

VBoxManage internalcommands sethduuid imagefile.vdi

OpenVPN on AWS

So far I am impressed with OpenVPN AS on AWS with Windows clients.  I haven’t tested beyond the two test users — so how well it scales is yet to be seen.

I am having some trouble getting a Linux host (Ubuntu 14.04) to function properly.  I’m not seeing errors, but the connection doesn’t appear to be working.  That appears to be high on my “ToDo” list for today.

Google Drive on Linux

google-drive-ocamlfuse -label acc1 gdrive.acc1

To umount:

fusermount -u gdrive.acc1

Restart network on Ubuntu (bridge network)

sudo ifdown br0 && sudo ifup br0

Clear Remmina SSL Cert Cache

Note to self: Self-Signed SSL Certs for RDP will auto-renew and cause Remmina to stop talking to your hosts.  Not very talkative about why.

The solutions is to nuke the ~/.freerdp/kndown_hosts file…