Enable snapshots for VM with vUSB/USB passthrough

[ghost]

Currently an attempt to snapshot a VM with USB-passthrough fails. Probably a Xen issue, but it would be very useful if it could be worked around somehow.

The error is "Error: VM_HAS_VUSBS"

[marcelmah]

As far as I know VMware has the same problem.

Would be nice to see this 'fixed' if at all possible.

[LegsAJimbo]

Same issue here, commenting to show interest.

[marcelmah]

As far as I know VMware has the same problem.

Would be nice to see this 'fixed' if at all possible.

I chose ESXi for my home 'lab' and I have one VM with multiple USB devices. I use Veeam to backup my VM's at the VM level (so no agent installed) and it says successful every time.

[Fohdeesha]

Bumping the issue to show interest, it's very odd that VDI snapshots are possible with entire PCI devices passed through to VMs, but not when a single USB device is. I can't find any technical reasons or explanations anywhere from citrix

[olivierlambert]

We should ask upstream about this (XAPI devs, or Xenops/xen)

[simonk83]

I'd also really like this

[ghost]

I would also like to see this resolved, as we wanted to move from our old backup system to a more reliable! system offered by XO. USB pass through has been an issue with Citrix and has not really been enhanced by xcp-ng. We need accurate temporal and spatial information for our purposes.

[IanMajor12]

Adding that this is important to support Home Automation projects that have dongles to be able to talk to other devices

[simonk83]

Exactly why I want it too :)

On Sun, Oct 10, 2021 at 5:35 PM IanMajor12 @.***> wrote:

Adding that this is important to support Home Automation projects that have dongles to be able to talk to other devices

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/xcp-ng/xcp/issues/164#issuecomment-939416442, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD6SKHLWDDULIOEXRO5BM3UGEXZJANCNFSM4HD2FG3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[olivierlambert]

Hi,

Thanks for your feedback. However, we have very few requests for this, and because we have a ton of other more "urgent" stuff to work on, it's something we'd love to have help on it (ie external contributors).

We could do a kind of estimation of the load (and then the resources/money needed for that), but clearly right now it's not on top priorities…

Believe me, I'd love to have available people working on it, but so far, despite doubling the team size this year, we are still far of being capable tackling this request while we have to do all the rest. Also money doesn't grow on trees, and as long as XCP-ng is not profitable, we'll prioritize features from -reasonably big- enterprise users.

But again: as a fully open source project (unlike Citrix), we strongly encourage people to contribute :+1:

[simonk83]

Yep understood mate. If I knew what I was doing I'd look into it myself, but I certainly do not know what I'm doing in this case unfortunately :D

On Sun, Oct 10, 2021 at 5:55 PM Olivier Lambert @.***> wrote:

Hi,

Thanks for your feedback. However, we have very few requests for this, and because we have a ton of other more "urgent" stuff to work on, it's something we'd love to have help on it (ie external contributors).

We could do a kind of estimation of the load (and then the resources/money needed for that), but clearly right now it's not on top priorities…

Believe me, I'd love to have available people working on it, but so far, despite doubling the team size this year, we are still far of being capable tackling this request while we have to do all the rest. Also money doesn't grow on trees, and as long as XCP-ng is not profitable, we'll prioritize features from -reasonably big- enterprise users.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/xcp-ng/xcp/issues/164#issuecomment-939418581, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD6SKFP4PV5LK45WTB73OLUGE2FRANCNFSM4HD2FG3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[ghost]

Our attempt at resolving this would be to purchase a Raspberry Pi or other small system, use the Pi as the collector and pass the data via the network to the vm. Modifying the hypervisor to do this will result in all your good work being trashed on an upgrade/update (that is why we have to modify our usb files and reinstate the shell scripts for backups, passthru etc to get operational). Our issue is simple as we only have one device, the GPS, but if it was not feasible, the Pi option with additional code to pass the data across the network in real time would be the way to go.

[olivierlambert]

We are open to any contribution upstream (so this will be "default" and will be preserved during upgrade) :smiley:

[ghost]

We think of the hyperviser as a server (in the old days all servers were individual computers) and as such to remain totally autonomous from the internet (the weakest link) two things are vital.

1. UPS, we use NUT appears to be working ok.
2. GPS, as we have suffered in the past from the loss of ntp.

Our GPS 'solution' requires us to boot hypervisor, shutdown the vm, enable passthru, noting the usb id can change, not sure why as it is always in the same socket) then reboot the vm, bit of a nuisance.

Upgrades require the usb system file to be re modified as it resets to the 'default' We have raised this issue regarding configuration preservation over upgrades/updates/reboots in the past and to be honest don't expect it to be resolved, we have a Plan B in place for temporal data (ntp).

[IanMajor12]

@olivierlambert, I completely understand the prioritization.

@aimdev I can see that USB storage would get messy. I still remember having to "park" hard drives, and the modern version of that is Eject USBs.

Was just hoping that some device types could be exempt from the restriction - like CDC adapters, Wireless, etc. the class of device exists in the /etc file, so maybe this is a step closer to being able to snapshot.

Really, I just want bragging rights over the ProxMox community (where this is possible to back up). So much happier back on XCP-NG and XOA - things just work and work well without having to scour obscure posts.

The XCP-NG and XOA teams are incredible at what they have and will continue to deliver.

[ghost]

@IanMajor12 USB devices can be used, there was a discussion some time ago on how to so this. The problem is the way it has to be achieved., either by a script (ideally run prior to the VM's startup), the manner I described (script or using xen-center) bearing in mind all 'unapproved' alterations dissapear on version upgrade (and maybe at other times)

[Trufax]

Iam also interested in this. Maybe a workaround could be to enable XO shutdown the VM to unmount USB devices do a Snapshot and mount them again (maybe via the Job feature?).

[olivierlambert]

@Trufax there's already an offline snapshot feature in XO.

Anyway, the best solution is already merged in XAPI for next XCP-ng release (8.3?), allowing XO to just snapshot VM disks of our choice, without snapshotting the VM (solving your problem)

[Trufax]

Oh wow even better. Cant wait for 8.3 than =) Great work!