Virtualization Megathread V2: VMs inside VMs

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > Virtualization Megathread V2: VMs inside VMs

Harik: Sep 9, 2001; From the hard streets of Moscow
First dog to touch the stars; Plaster Town Cop

I've got an oddball question regarding vmware - I'm playing with it on a test box that's an AMD instead of my normal intel, and it's not enabling hardware-virtualization for some reason.

model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv

I thought that svm was the gen-1 AMD hardware acceleration, but vmware insists my only option is binary translation.

It's not a huge deal, as my i5 workstation runs HVT no problem, but I do want to know what the minimum AMD cpu is for vmware HVT - Xen will run on that processor just fine.

# ¿ Dec 7, 2012 21:56

Adbot: ADBOT LOVES YOU

# ¿ May 19, 2024 23:35

Harik: Sep 9, 2001; From the hard streets of Moscow
First dog to touch the stars; Plaster Town Cop

Corvettefisher posted:

IS AMD-V, Virtualization enabled in the bios? What stepping is the CPU?

Here is something that might help you
https://www.virtualbox.org/ticket/1933

You might want to update that CPU for VM work, but you probably already know that.

Ok, I won't be able to use this particular box, it's F2 stepping with the known virtualization bug, and no BIOS update to fix it.

Thanks! That was exactly what I needed to know.

# ¿ Dec 12, 2012 23:09

Harik: Sep 9, 2001; From the hard streets of Moscow
First dog to touch the stars; Plaster Town Cop

I was talking about this in the GPU thread, but it probably belongs here instead.

Trying out GPU-passthrough to downsize the number of machines I have. Currently I have an always-on linux box that's my desktop/development station and runs some services for my home (PLEX transcode, etc). Sitting next to it, hibernating 99.9% of the time is a box just for gaming.

Setup is Qemu/KVM on an i5-4590 (non-k) with VT-d enabled. GPU passes through fine, but the USB is all sorts of hosed up.

code:

qemu-system-x86_64 -enable-kvm -cpu host -m 4G -M pc \
	-boot menu=on \
	-smp sockets=1,cores=4,threads=1 \
	-vga none \
	-device vfio-pci,host=05:00.0,multifunction=on,x-vga=on,romfile=Sapphire.R9270X.2048.131105_2.rom,addr=0x4.0x0\
	-device vfio-pci,host=05:00.1,addr=0x4.0x1 \
	-device virtio-scsi-pci,id=scsi0,addr=0x6 \
	-netdev tap,id=hostnet1,helper=/usr/lib/qemu/qemu-bridge-helper \
        -device virtio-net,netdev=hostnet1,id=net1,mac=52:54:00:33:b4:11,addr=0x08 \
	-drive file=/dev/disk/by-id/ata-Samsung_SSD_840_EVO_500GB_S1DHNSAFB18314H,format=raw,if=none,id=scsi0-0 \
	-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=scsi0-0,bootindex=1 \
	-soundhw hda \
	-readconfig /usr/share/doc/qemu-system-common/ich9-ehci-uhci.cfg \
	-device usb-host,vendorid=0x0a81,productid=0x0205 \
	-device usb-host,vendorid=0x046d,productid=0xc531 \
	-device usb-host,vendorid=0x041e,productid=0x4088 \
	"$@"

Those USB devices are:
Bus 001 Device 002: ID 046d:c531 Logitech, Inc. C-U0007 [Unifying Receiver]
Bus 001 Device 007: ID 041e:4088 Creative Technology, Ltd Live! Cam Chat HD [VF0700]
Bus 001 Device 009: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter

The webcam works, but the mouse & keyboard both show up in device manager as yellow triangles.

Bootup on qemu is silent, but the host kernel gets upset about USB shennagins:

code:

Aug  6 15:18:41 wolf kernel: [99117.237215] usb 1-12: reset low-speed USB device number 9 using xhci_hcd
Aug  6 15:18:42 wolf kernel: [99117.658195] usb 1-9: reset full-speed USB device number 2 using xhci_hcd
Aug  6 15:18:43 wolf kernel: [99119.108144] usb 1-12: reset low-speed USB device number 9 using xhci_hcd
Aug  6 15:18:43 wolf kernel: [99119.529164] usb 1-9: reset full-speed USB device number 2 using xhci_hcd
Aug  6 15:18:44 wolf kernel: [99119.946134] usb 1-12: reset low-speed USB device number 9 using xhci_hcd
Aug  6 15:18:44 wolf kernel: [99120.367090] usb 1-9: reset full-speed USB device number 2 using xhci_hcd
Aug  6 15:18:44 wolf kernel: [99120.605028] usb 1-11.3: reset high-speed USB device number 7 using xhci_hcd
Aug  6 15:18:46 wolf kernel: [99122.404975] usb 1-11.3: reset high-speed USB device number 7 using xhci_hcd
Aug  6 15:18:47 wolf kernel: [99122.736959] usb 1-12: reset low-speed USB device number 9 using xhci_hcd
...

Any ideas? All I can find is people asking for help in how to bind devices, it's apparently "just working" once they bind them.

I tried putting in a PCI USB card to pass through directly, but it gives me poo poo no matter which slot I put it in. It's in it's own IOMMU group, but the interrupt is shared and refuses to honor remapping.

# ¿ Aug 6, 2016 20:29

Harik: Sep 9, 2001; From the hard streets of Moscow
First dog to touch the stars; Plaster Town Cop

The USB turned out to be a combination of things: Windows being windows and making GBS threads up the DriverStore (copied new usb* from install.wim to fix it) and the PS2/USB adapter being a piece of junk.

Unfortunately, even after all that I only got "near native" performance on benchmarks and some games. Others were running at unplayable levels of FPS for some reason. I'm going to attribute it to the only-partial VT-d support on H97 (IOMMU, no IRQ remap, maybe other limitations?) and try it again when I get better hardware.

I tried the obvious fixes: CPU pinning per-thread, hugepages instead of 4k memory maps, every driver possible to virtio, moved the sound from emulated to running through the HDMI. DPC Latency was pretty horrific comapared to a raw machine - raw was max ~150us, qemu was minimum 1500us, spiking up to 20k or more. If that's applying to draw commands than the difference is probably big-batch vs small-batch game engines.

Harik fucked around with this message at 16:09 on Aug 7, 2016

# ¿ Aug 7, 2016 15:50

Harik: Sep 9, 2001; From the hard streets of Moscow
First dog to touch the stars; Plaster Town Cop

I was looking at those refurb board/CPU/RAM combos earlier and had a question:

2x E5-2670 SR0H8
Shouldn't be used for virtual machine applications.

Is that an errata with the H8 stepping? The KX doesn't say anything about not using for VM, but it's the same processor.

It would explain why it's nearly $100 cheaper, if it's a known problem with that revision. I'm looking into upgrading some hardware that's vastly underpowered for it's workload.

Edit: Damnit, I figured it out. It's not H8 stepping, that's the model number for C1 stepping. KX is C2, and yes it fixes a serious bug with VT-d. I didn't think H8 sounded like an intel revision code.

Harik fucked around with this message at 18:37 on Dec 18, 2016

# ¿ Dec 18, 2016 00:39

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > Virtualization Megathread V2: VMs inside VMs