|
DevNull posted:Don't worry, it will take VMware 6 months to release it
|
#
?
Mar 18, 2016 19:00
|
|
|
|
| # ? May 8, 2024 05:59 |
|
|
DevNull posted:I just sent this to the engineer in charge of the client. I'm not sure if he is still working on it, or handing it off to someone else. It brings up an interesting problem though. You could give that feedback pretty directly when it was a Fling because the engineers could comment directly on the Fling page. Now that it is a supported product, that kind of goes away and is replace with a ton of bureaucracy. I probably would have sent it up the ladder if I was more of a VMware guy, but I'm a KVM guy these days. I'm just glad to have something cross-platform for the free ESXi. Either way, big ups for effort. There was a thing back in the fling days where I couldn't start or stop VMs and I had to SSH in to the host and use command line to do things, but that seems to have been addressed as well. At least it made me learn more about esxcli, so that's a good thing, especially with my VCP6 exam coming up. As it stands, the current state of the console window thing isn't too bad because the window-in-window thing works pretty well. HPL fucked around with this message at 19:04 on Mar 18, 2016 |
|
#
?
Mar 18, 2016 19:02
|
|
|
Vulture Culture posted:Haha, I remember when I found a VMFS bug in 4.0 related to non-contiguous extents, identified the exact regression, identified the last known working version, identified where in their code the problem was, and it still took them 8 months to push out a fix in an official release At least with that there is the excuse that they need to run a bunch of regression testing, and we don't ship updates to ESX super often. The host client should actually be able to pretty quickly. They could probably push out an updated vib once a month or so. Even if there is a bug, it won't take out a datastore and a bunch of VMs.
|
|
#
?
Mar 18, 2016 19:11
|
|
|
HPL posted:I probably would have sent it up the ladder if I was more of a VMware guy, but I'm a KVM guy these days. I'm just glad to have something cross-platform for the free ESXi. Either way, big ups for effort. There was a thing back in the fling days where I couldn't start or stop VMs and I had to SSH in to the host and use command line to do things, but that seems to have been addressed as well. At least it made me learn more about esxcli, so that's a good thing, especially with my VCP6 exam coming up. Never not report bugs. Even if you're not a very active user, filing bugs (or RFEs) still forces them to eventually be acknowledged, and people in product management can say "hey, people want this" or "this is a problem". Even if you're just an end user and not a strategic partner or big customer, having lots of bugs filed (even if they're closed as duplicates) or whatever gets attention and raises the priority.
|
|
#
?
Mar 18, 2016 19:19
|
|
|
evol262 posted:Never not report bugs. Even if you're not a very active user, filing bugs (or RFEs) still forces them to eventually be acknowledged, and people in product management can say "hey, people want this" or "this is a problem". On the other hand, the crazy idea posted here and discussed further down-thread: https://forums.somethingawful.com/showthread.php?threadid=2803713&userid=0&perpage=40&pagenumber=865#post457560701
|
|
#
?
Mar 18, 2016 19:29
|
|
|
Thermopyle posted:On the other hand, the crazy idea posted here and discussed further down-thread: https://forums.somethingawful.com/showthread.php?threadid=2803713&userid=0&perpage=40&pagenumber=865#post457560701  "Only developers can do anything to my project!" Thanks, github culture. What happens when a legitimate user of your project has a problem/request but has no idea how to even start writing tests or feature branches?This is fine for hobby projects, I guess, maybe. Probably not in my opinion. It's completely retarded for anything even remotely professional, though. e: I should have read further. evol262 fucked around with this message at 19:39 on Mar 18, 2016 |
|
#
?
Mar 18, 2016 19:36
|
|
|
^^ this. This whole devops poo poo is getting out of hand.
|
|
#
?
Mar 18, 2016 19:38
|
|
|
I guess I never report bugs because 99.99999% of the time the problem is because of something stupid I'm doing. And then when I have an idea for a feature, it turns out it's already there, I just didn't know how to get to it.
|
|
#
?
Mar 19, 2016 00:40
|
|
|
HPL posted:turns out it's already there, I just didn't know how to get to it. This should also be reported as a "bug" so we can make our stuff easier to use.
|
|
#
?
Mar 19, 2016 01:26
|
|
|
Is there a way to change the default timeout value for the new esxi html5 client?
|
|
#
?
Mar 20, 2016 04:13
|
|
|
Vulture Culture posted:Haha, I remember when I found a VMFS bug in 4.0 related to non-contiguous extents, identified the exact regression, identified the last known working version, identified where in their code the problem was, and it still took them 8 months to push out a fix in an official release You might be so late in the release cycle for an update that the bugfix can't be included in it, making it slip for the next update, which is a few months out. But maybe the fix is also quite non-trivial, so it needs to be in a major Update release (given testing, host base installation considerations, etc) which happens to be planned for release even more months out. I'm not entirely sure what the best approach is anymore. Not have bugs, I guess. :P
|
|
#
?
Mar 20, 2016 09:29
|
|
|
Kachunkachunk posted:It can be frustrating, but sometimes this is how release vehicle schedules work out.
|
|
#
?
Mar 20, 2016 16:51
|
|
|
Vulture Culture posted:Yeah, I understand why it happens, the turnaround cycles on commercial software are just really frustrating to someone coming from an OSS mindset where the solution would have otherwise been "apply five-line patch file, rebuild package, upload to internal repository" and then push the fix upstream when you get around to it The thing is that how can you be 100% sure that the patch won't screw up something else? And what if it affects something currently in development? I mean I totally get where you're coming from, but there's a lot of risk and money riding on every patch release. With free software, there's always the whole "caveat emptor" factor happening.
|
|
#
?
Mar 20, 2016 17:05
|
|
|
HPL posted:The thing is that how can you be 100% sure that the patch won't screw up something else? And what if it affects something currently in development? I mean I totally get where you're coming from, but there's a lot of risk and money riding on every patch release. With free software, there's always the whole "caveat emptor" factor happening. 
|
|
#
?
Mar 20, 2016 18:02
|
|
|
HPL posted:The thing is that how can you be 100% sure that the patch won't screw up something else? And what if it affects something currently in development? I mean I totally get where you're coming from, but there's a lot of risk and money riding on every patch release. With free software, there's always the whole "caveat emptor" factor happening. The answer to this is to have comprehensive unit and functional tests covering as much of the project as possible. It doesn't push the risk to zero, but it sure does make it way less likely to break something without being aware of it.
|
|
#
?
Mar 20, 2016 18:51
|
|
|
cliffy posted:The answer to this is to have comprehensive unit and functional tests covering as much of the project as possible. It doesn't push the risk to zero, but it sure does make it way less likely to break something without being aware of it. And then there's prioritization. A bug that affects a small percentage of users a small percentage of time probably isn't worth the hassle of of hotfix or whatever. On the flip side, look how fast things move when there's something major like Drown.
|
|
#
?
Mar 20, 2016 19:09
|
|
|
HPL posted:And then there's prioritization. A bug that affects a small percentage of users a small percentage of time probably isn't worth the hassle of of hotfix or whatever. On the flip side, look how fast things move when there's something major like Drown. Things actually move at about the same pace. It's just that CVEs get embargoed, so it looks really fast once it's public, but the actual discovery/investigation/patch/review/test/release cycle takes at least a week. It's only when embargoes are broken with a public, easy, high-impact proof of concept that things get hectic. Patches accepted upstream which you backport or cherry pick yourself are pretty reliable, especially since downstream is often a rebase or straight clone of upstream. A small bug which affects a small portion of users but doesn't merit a hotfix/async release still gets the normal amount of scrutiny from QE for verification, and culling patches from verified fixed issues upstream is very likely to work reliably. "Caveat emptor" is a "this is community-supported" thing, not a "we release broken code" thing, since broken code upstream invariably leads to regressions/broken code downstream, where paying customers subsidize development work on upstream.
|
|
#
?
Mar 20, 2016 19:38
|
|
|
I just figured out there's a Windows QXL driver on the virtio Windows ISO. What a difference. Now video performance is smoother and mouse response is way, way better.
|
|
#
?
Mar 21, 2016 18:57
|
|
|
HPL posted:I just figured out there's a Windows QXL driver on the virtio Windows ISO. What a difference. Now video performance is smoother and mouse response is way, way better. I just use RDP.........
|
|
#
?
Mar 21, 2016 19:44
|
|
|
Mr Shiny Pants posted:I just use RDP......... This is for using a VM on a local host machine. SPICE kicks the crap out of RDP in that regard. Also, this seems to be a day of discovery for me. How come I never noticed the "Redirect USB device" menu item in virt-manager before?
|
|
#
?
Mar 22, 2016 00:22
|
|
|
I came across a script from a guy that can switch the graphics driver of the primary device during runtime, including unbinding and rebinding the VTs. I'd figure that if you can go between nvidia and nouveau, it might be possible to bind vfio-pci and use the primary adapter with passthrough. If anyone wants to try to recycle this (gonna take a while until I get a second SSD to run Linux), efifb needs to be compiled as module, tho: https://gist.github.com/davispuh/84674924dff1db3e7844 --edit: I sent that to the guy on reddit I had a chat with about that a while ago and let me hanging with the results, he replied to be that he got it working in a similar fashion a while ago. So I guess if you want to occasionally game but not disgrace your harddrive/SSD physically with Windows, this is an option that works without the need of two GPUs. Combat Pretzel fucked around with this message at 15:08 on Mar 22, 2016 |
|
#
?
Mar 22, 2016 06:28
|
|
|
Just as a heads-up, upgrading ESXi to 6.0u2 broke the USB passthrough I had to a printer. I couldn't re-add it with the HTML client. The option to add a USB device isn't even in the HTML client. You can add a hub, but not a device. Had to hold my nose and use the Windows vSphere Client. So if anyone is in the same boat, there you go.
|
|
#
?
Mar 23, 2016 04:53
|
|
|
USB pass-through... printer? 
|
|
#
?
Mar 23, 2016 05:25
|
|
|
Internet Explorer posted:USB pass-through... printer? I know, I know. I've tried just about everything to get this stupid Canon printer to be available over the network and this is pretty much the best I could do short of dedicating an actual computer to it. It has driven me up the wall and I can't wait to get rid of it.
|
|
#
?
Mar 23, 2016 05:30
|
|
|
Anyone use hv_vendor_id with qemu? I have version 2.5.0 built from source and installed, confirmed the property exists in the source I compiled from, but I can't seem to get the command line to accept it. Also confirmed qemu-system-x86_64 version is 2.5.0. Relevant command-line: code:code:
|
|
#
?
Mar 23, 2016 05:41
|
|
|
hv-vendor-id and not hv_vendor_id for some reason. Probably going to be fixed at some point.
|
|
#
?
Mar 23, 2016 14:20
|
|
|
Combat Pretzel posted:hv-vendor-id and not hv_vendor_id for some reason. Probably going to be fixed at some point. Tried this too, got the same result.
|
|
#
?
Mar 23, 2016 14:29
|
|
|
I went ahead and hacked the vendor ID in qemu's source, which shows up if I inspect the binary with strings. Seems to have worked because my card no longer refuses to start in the guest with code 43.
|
|
#
?
Mar 23, 2016 14:33
|
|
|
Also, a big gently caress you to NVIDIA for making this so difficult.
|
|
#
?
Mar 23, 2016 14:36
|
|
|
Now I'm not even so sure about hv-vendor-id being in 2.5.0. Back then, I went pretty quickly to 4.5-rc and qemu-git for moar powah!!!
|
|
#
?
Mar 23, 2016 14:59
|
|
|
Combat Pretzel posted:Now I'm not even so sure about hv-vendor-id being in 2.5.0. Back then, I went pretty quickly to 4.5-rc and qemu-git for moar powah!!! Yeah I'm thinking about just living on the edge, but it certainly appears to be in 2.5.0: https://github.com/qemu/qemu/blob/v2.5.0/target-i386/kvm.c#L554
|
|
#
?
Mar 23, 2016 15:03
|
|
|
It seems as though the NVIDIA driver is finicky about checking enlightenments on startup, or maybe there is some legitimate problem there. I haven't totally narrowed it down, but its one of code:
|
|
#
?
Mar 24, 2016 02:13
|
|
|
Ah, hv_spinlocks is enough to send into a bluescreen loop after a second reboot. Maybe I should start a VGA passthrough thread instead of spamming this one?
|
|
#
?
Mar 24, 2016 02:16
|
|
|
You using i440 machine type or the Q35 one? Also, do you use OVMF UEFI?
|
|
#
?
Mar 24, 2016 04:02
|
|
|
Combat Pretzel posted:You using i440 machine type or the Q35 one? Also, do you use OVMF UEFI? q35 and yes using OVMF UEFI. Although I don't think I have a UEFI vars file attached to this VM.
|
|
#
?
Mar 24, 2016 04:09
|
|
|
You don't need vars attached. It's just that vfio is much nicer than the old way. Set KVM to hidden. Disable all the enlightenments. Should be good.
|
|
#
?
Mar 24, 2016 06:06
|
|
|
Certainly strange that you've got these issues. My Windows 10 VM ran just fine and rebooted without going BSOD. That was with qemu-git and the rc's of Linux 4.5. CPU was a Haswell-E on an ASRock X99, and the graphics cars was a GTX 780 as secondary. The relevant parameters of mine were these: quote:-machine type=q35,accel=kvm,kernel_irqchip=on \ --edit: Now thinking about it, check your kernel log for KVM complaining about unknown MSRs and crashing the Windows VM. I heard that those can be an issue. If that's the case, one of the HV parameters listed above seems to fix it, according to people on /r/vfio, for whatever reason. Alternatively, create a conf file in modprobe.d and put options kvm ignore_msrs=1 into it. If you ditch the HV enlightenments, try running some graphics benchmark app to see how much of a difference it makes. People keep saying it's considerable. Combat Pretzel fucked around with this message at 07:00 on Mar 24, 2016 |
|
#
?
Mar 24, 2016 06:55
|
|
|
Combat Pretzel posted:Certainly strange that you've got these issues. My Windows 10 VM ran just fine and rebooted without going BSOD. That was with qemu-git and the rc's of Linux 4.5. CPU was a Haswell-E on an ASRock X99, and the graphics cars was a GTX 780 as secondary. Benchmarked with Unigine Heaven 4.0. Settings are DX11, 1080p, 8xAA, quality ultra, tessellation extreme. Hardware is 5280k @ 4Ghz, 980ti stock settings. With enlightenments (I think, I ran this a week or two ago when I had enlightenments enabled with no issues): Score: 2136 Without (-cpu host, kvm=off only): Score: 2128 Enlightenments don't seem to matter, at least not for this benchmark.
|
|
#
?
Mar 25, 2016 22:34
|
|
|
When you deploy from OVF via url in the vmware web client does vcenter grab the remote bits directly, or do they go through your local machine first?
|
|
#
?
Mar 28, 2016 20:10
|
|
|
|
| # ? May 8, 2024 05:59 |
|
|
https://labs.vmware.com/flings/vsphere-html5-web-client
|
|
#
?
Mar 28, 2016 20:52
|
|
