Description of problem: I was hoping to use virt-v2v-in-place to get virtio drivers installed into a windows VM, rather than doing it manually. I semi-manually imported it from vmware into libvirt using qemu-img and virt-install, because virt-v2v couldn't identify the OS on the disk. I've done this on about 65 VMs. Something like 20% had this issue (inspection could not detect the source guest). I don't know what made that 20% different. In any case, because I didn't use virt-v2v to do the conversion from vmware, the virtio drivers did not get installed, which is why I'm running virt-v2v-in-place. The VM is registered with libvirt with a qcow2 image for the disk. It boots, so things aren't totally screwed up. If I run virt-v2v-in-place as myself, I get this error: virt-v2v-in-place vmname ... mnbdkit: file[1]: error: open: /dev/dm-1: Permission denied I assume this is expected behavior and I have to run as root. So I try: sudo virt-v2v-in-place vmname ... virt-v2v-in-place: error: libguestfs error: passt exited with status 1 Digging deeper into this using strace, I think this problem is stemming from: [pid 309845] geteuid() = 0 [pid 309845] mkdir("/tmp/libguestfsyIUHch", 0700) = 0 [pid 309845] chmod("/tmp/libguestfsyIUHch", 0755) = 0 [pid 309845] bind(3, {sa_family=AF_UNIX, sun_path="/tmp/libguestfsyIUHch/guestfsd.sock"}, 110) = 0 [pid 309871] execve("/usr/bin/passt.avx2", ["passt", "--one-off", "--socket", "/tmp/libguestfsyIUHch/passt.sock", "--pid", "/tmp/libguestfsyIUHch/passt1.pid", "--address", "redacted", "--netmask", "16", "--mac-addr", "redacted", "--gateway", "redacted"], 0x7ffcb400e7b0 /* 19 vars */) = 0 [pid 309871] geteuid() = 0 [pid 309871] openat(AT_FDCWD, "/proc/self/uid_map", O_RDONLY|O_CLOEXEC) = 5 [pid 309871] setuid(65534) = 0 [pid 309871] connect(7, {sa_family=AF_UNIX, sun_path="/tmp/libguestfsyIUHch/passt.sock"}, 110) = -1 ENOENT (No such file or directory) [pid 309871] unlink("/tmp/libguestfsyIUHch/passt.sock") = -1 ENOENT (No such file or directory) [pid 309871] bind(6, {sa_family=AF_UNIX, sun_path="/tmp/libguestfsyIUHch/passt.sock"}, 110) = -1 EACCES (Permission denied) UNIX domain socket bound at /tmp/libguestfsyIUHch/passt.sock kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/tmp/libguestfsyIUHch/passt. [pid 309871] write(2, "\n", 1 <unfinished ...> [pid 309871] openat(AT_FDCWD, "/tmp/libguestfsyIUHch/passt1.pid", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0600) = -1 EACCES (Permission denied) Note the setuid call that switches away from root... after creating the temp dir as root. passt is switching users to someone who does not have permission to write to the temp directory created by the parent process. My machine does not have a user 65534. Version-Release number of selected component (if applicable): $ virt-v2v-in-place --version virt-v2v-in-place 2.4.0 $ passt --version passt unknown version $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 24.04 LTS Release: 24.04 Codename: noble Installed using apt-get on ubuntu24.04. This is pretty much a fresh install. How reproducible: 100% I am suspicious this would happen for any libvirt VM on this host based on how early it happens. Also happens using -i libvirtxml. Steps to Reproduce: 1. sudo virt-v2v-in-place vmname Actual results: virt-v2v-in-place: error: libguestfs error: passt exited with status 1 Expected results: exit code 0 Additional info: Using -i disk seems to avoid using passt and triggering the problem. However, after getting past this passt problem, I hit the same problem virt-v2v originally did: inspection could not detect the source guest so looks like I'll be installing the virtio drivers from inside the guest.
I suspect this could be the same issue as: https://issues.redhat.com/browse/RHEL-36045
(In reply to David Vitek from comment #0) > $ passt --version > passt unknown version Weird, I'll need to look into this. I maintain the Debian package, which is automatically synchronised and built for Ubuntu, but I don't know why this happens (on Ubuntu). Meanwhile, could you please share the output of 'apt-cache policy passt', so that we know what the actual version is? The problem you described should be fixed by https://passt.top/passt/commit/?id=c9b24134656925e53fea3cde0b33ab143dcd84af, so I suspect that the version you have installed at the moment doesn't contain the fix.
(In reply to Stefano Brivio from comment #3) > (In reply to David Vitek from comment #0) > > $ passt --version > > passt unknown version > > Weird, I'll need to look into this. I maintain the Debian package, which is > automatically synchronised and built for Ubuntu, but I don't know why this > happens (on Ubuntu). This was fixed by https://salsa.debian.org/sbrivio/passt/-/commit/e2a0b460ac19345b622f0b6263473be8b8775907, but Ubuntu 24.04 doesn't have the fix yet (24.10 does). > Meanwhile, could you please share the output of 'apt-cache policy passt', so > that we know what the actual version is? > > The problem you described should be fixed by > https://passt.top/passt/commit/?id=c9b24134656925e53fea3cde0b33ab143dcd84af, > so I suspect that the version you have installed at the moment doesn't > contain the fix. Same here: Ubuntu 24.04 has passt-0.0~git20240220.1e6f92b, which doesn't include the fix, while Ubuntu 24.10 ships passt-0.0~git20240624.1ee2eca, which is fixed. It's not at all clear to me how updates are picked for Ubuntu 24.04 (you should probably report this issue on Launchpad). Meanwhile, would it be an option for you to install passt-0.0~git20240624.1ee2eca (https://packages.ubuntu.com/oracular/passt)?
Yeah I have the same version you suspect: $ apt-cache policy passt passt: Installed: 0.0~git20240220.1e6f92b-1 Candidate: 0.0~git20240220.1e6f92b-1 Version table: *** 0.0~git20240220.1e6f92b-1 500 500 http://us.archive.ubuntu.com/ubuntu noble/universe amd64 Packages 100 /var/lib/dpkg/status Given that I was already able to work around the issue, I don't particularly need the update right now. However, I can try it if you are particularly interested in confirming it works. Feel free to close the ticket.
(In reply to David Vitek from comment #7) > Yeah I have the same version you suspect: > > $ apt-cache policy passt > passt: > Installed: 0.0~git20240220.1e6f92b-1 > Candidate: 0.0~git20240220.1e6f92b-1 > Version table: > *** 0.0~git20240220.1e6f92b-1 500 > 500 http://us.archive.ubuntu.com/ubuntu noble/universe amd64 Packages > 100 /var/lib/dpkg/status Thanks for checking. > Given that I was already able to work around the issue, I don't particularly > need the update right now. However, I can try it if you are particularly > interested in confirming it works. Not so much, the issue is very well defined. And anyway it can only be fixed with a newer version of passt (or a backport) on Ubuntu 24.04, so the issue should be filed against Ubuntu, in case. > Feel free to close the ticket. Rich, I would close this if you agree.
I have closed -> currentrelease as it seems this should be fixed in Ubuntu 24.04 per comment 6. If the reporter has time it would be good to verify this is really the case.
(In reply to Richard W.M. Jones from comment #9) > I have closed -> currentrelease as it seems this should be fixed in Ubuntu 24.04 24.10 (CURRENTRELEASE applies as well).