Re: NFS with nearby host, VM clients?
Much thanks. Any of these would (will) be just fine. I have at least one question. ssh port forwarding would be the easiest, it was one way I tried, but I'm missing something. In your example: > ssh -R 10809:nbd-server:10809 vm ...is that to say that 10809 is the only port we need to handle? Or, is it just an example showing one of the necessary ports? NFS+RPC is one of my holdups; 10809, Linux Network Block Devices, is in /etc/services on some, not all, of my Linux hosts, so, please educate me: does that process fix the "RPC problem"? Thanks. On Wed, Apr 20, 2022 at 9:47 AM Richard W.M. Jones wrote: > On Mon, Apr 18, 2022 at 11:22:07PM -0500, Michael Jinks wrote: > > I have a laptop, running VMM, with a handful of VM's. Next to that, I > have a > > pile of disks running on ZFS, and I'd like to give the VM's network > access > > there, for running backups or whatever. > > > > The holdup is that the laptop (pop-OS if that matters -- so Ubuntu, so > Debian) > > automatically prohibits any outside network traffic to the VM's. > > Self-contained outward traffic from the VM is fine, like ssh; but the > outside > > host can't see in to any VM, so, for instance, when the VM tries to > NFS-mount > > to the outside, the rpc connection back will fail. > > > > In the past, my way of allowing something like this was to make a new > virtual > > network running on the host, visible for the VM's and reachable by the > outside > > service, but I haven't been able to find how to do that in a modern VMM > setup. > > I can find, in the GUI: > > > > QEMU/KVM - Connection Details -> Virtual Networks: "Create a > > new virtual network"... > > > > ...but everything I've tried has failed in one way or another. Maybe I > just > > don't know how to set that up? > > I used this relatively recently. It's still a lot more painful to set > up than it really needs to be however ... > > > https://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29 > > Another option is just port forwarding. Pretty sure you can set this > up from virt-manager, but if not you can definitely do it through > editing the libvirt XML: > > https://libvirt.org/formatdomain.html#channel > > virsh edit is described here: > > https://www.redhat.com/sysadmin/virsh-subcommands > > Another option would be attaching a remote disk to the guest. Again, > not sure if this can be done in virt-manager, but it's certainly > possible from libvirt XML: > > https://libvirt.org/formatdomain.html#hard-drives-floppy-disks-cdroms > > > > > > > > > > Another, even simpler option is a reverse SSH tunnel, ie something > like this on the host: > > ssh -R 10809:nbd-server:10809 vm > > That will export the NBD port on nbd-server:10809 into the VM, so you > would be able to access an NBD server from inside the VM. > > Rich. > > > I understand the security concerns, and won't have a problem flatting > that > > down. > > > > If I'm just not looking in the right docs, please point me in the > > right direction. > > > > Or, if I'm going about this some unwise way, please educate me. > > > > Thanks. > > > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW > >
Re: NFS with nearby host, VM clients?
On Mon, Apr 18, 2022 at 11:22:07PM -0500, Michael Jinks wrote: > I have a laptop, running VMM, with a handful of VM's. Next to that, I have a > pile of disks running on ZFS, and I'd like to give the VM's network access > there, for running backups or whatever. > > The holdup is that the laptop (pop-OS if that matters -- so Ubuntu, so Debian) > automatically prohibits any outside network traffic to the VM's. > Self-contained outward traffic from the VM is fine, like ssh; but the outside > host can't see in to any VM, so, for instance, when the VM tries to NFS-mount > to the outside, the rpc connection back will fail. > > In the past, my way of allowing something like this was to make a new virtual > network running on the host, visible for the VM's and reachable by the outside > service, but I haven't been able to find how to do that in a modern VMM > setup. > I can find, in the GUI: > > QEMU/KVM - Connection Details -> Virtual Networks: "Create a > new virtual network"... > > ...but everything I've tried has failed in one way or another. Maybe I just > don't know how to set that up? I used this relatively recently. It's still a lot more painful to set up than it really needs to be however ... https://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29 Another option is just port forwarding. Pretty sure you can set this up from virt-manager, but if not you can definitely do it through editing the libvirt XML: https://libvirt.org/formatdomain.html#channel virsh edit is described here: https://www.redhat.com/sysadmin/virsh-subcommands Another option would be attaching a remote disk to the guest. Again, not sure if this can be done in virt-manager, but it's certainly possible from libvirt XML: https://libvirt.org/formatdomain.html#hard-drives-floppy-disks-cdroms Another, even simpler option is a reverse SSH tunnel, ie something like this on the host: ssh -R 10809:nbd-server:10809 vm That will export the NBD port on nbd-server:10809 into the VM, so you would be able to access an NBD server from inside the VM. Rich. > I understand the security concerns, and won't have a problem flatting that > down. > > If I'm just not looking in the right docs, please point me in the > right direction. > > Or, if I'm going about this some unwise way, please educate me. > > Thanks. > -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
Re: Xen dom0 support for virt-what seems broken
On Tue, Oct 19, 2021 at 03:55:39AM +0200, Daniele Palumbo wrote: > Hi, > > First, i'm new to this list. > Therefore, hi everyone once again. > > I was upgrading on a Gentoo server virt-what from 1.18 to 1.21. > Suddenly, facter reported that > is_virtual = true. > > I've tracked this down to: > v1.18: > xen-lipi-1 ~ # /usr/libexec/virt-what-cpuid-helper > > xen-lipi-1 ~ # virt-what > xen > xen-dom0 > xen-lipi-1 ~ # > > v1.21: > xen-lipi-4 ~ # /usr/libexec/virt-what-cpuid-helper > XenVMMXenVMM > xen-lipi-4 ~ # virt-what > xen > xen-hvm > xen-lipi-4 ~ # > > This seems anyhow to be a change between v1.20 and v1.21 in > virt-what-cpuid-helper.c: > [...] > +static int > +known_signature (const char *sig) > [... > +strcmp (sig, "XenVMMXenVMM") == 0 || > [...] > > If we go back to virt-what.in: > [...] > # Check for Xen. > > if [ "$cpuid" = "XenVMMXenVMM" ] && > ! echo "$dmi" | grep -q 'No SMBIOS nor DMI entry point found, sorry'; then > echo xen; echo xen-hvm > skip_qemu_kvm=true > [...] > > Therefore the output will always be > """ > xen > xen-hvm > """ > > Which seems to not contain xen-dom0, so i would say that the problem is in > virt-what. > If i'm wrong, and the problem is in facter, i would happily report a but > there. (I don't read this list regularly, best to CC me ...) Can you see if virt-what 1.22 still exhibits the bug? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
Re: no release tarball
On Wed, Apr 20, 2022 at 09:33:03AM -0400, Cole Robinson wrote: > On 4/19/22 1:25 PM, Henrik Riomar wrote: > > Hi, > > > > Looks like the v1.22 release was never uploaded: > > https://people.redhat.com/~rjones/virt-what/files/ > > > > Can you look into this? > > > > ccing rjones incase he missed this is about virt-what Sorry about this everyone. It is true that I have not yet uploaded the new tarball, and that's because of some internal network issue at Red Hat which is taking time to resolve. In the meantime I have temporarily placed the tarball here: http://oirase.annexia.org/tmp/virt-what-1.22.tar.gz http://oirase.annexia.org/tmp/virt-what-1.22.tar.gz.sig You can check the detached signature using the keyring from https://download.libguestfs.org/ (or my public key which should be the same). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
Re: no release tarball
On 4/19/22 1:25 PM, Henrik Riomar wrote: > Hi, > > Looks like the v1.22 release was never uploaded: > https://people.redhat.com/~rjones/virt-what/files/ > > Can you look into this? > ccing rjones incase he missed this is about virt-what - Cole
Re: Add support for enabling Secure Encrypted Virtualization in the GUI
On Wed, Apr 20, 2022 at 09:11:27AM -0400, Cole Robinson wrote: > On 4/19/22 1:21 PM, Daniel P. Berrangé wrote: > > On Tue, Apr 19, 2022 at 12:05:29PM -0400, Cole Robinson wrote: > >> On 4/4/22 11:49 AM, Charles Arnold wrote: > >>> > >>> > >>> On 4/4/22 6:50 AM, Daniel P. Berrangé wrote: > On Fri, Apr 01, 2022 at 12:13:17PM -0600, Charles Arnold wrote: > > From d700e8cee7cd525c0022b5a9a440f64c4ab149f0 Mon Sep 17 00:00:00 2001 > > From: Charles Arnold > > Date: Fri, 1 Apr 2022 12:01:21 -0600 > > Subject: [PATCH 1/1] Add support for enabling Secure Encrypted > > Virtualization > > in the GUI > > > > Add an "Enable Launch Security" checkbox on the Details memory tab. > > Do the minimal configuration required for libvirt to enable this feature > > on compatible hardware. > > > Don't we need to turn on the 'iommu' option for all virtio devices > too, and disable PXE on any NICs ? > > https://libvirt.org/kbase/launch_security_sev.html#virtio > > >>> > >>> I used to enumerate through the virtio devices in an old version of this > >>> patch > >>> for virt-manager and enable iommu but it really wasn't reasonable for > >>> virt-manager to track which virtio devices needed iommu enabled. > >>> Additionally, > >>> libvirt will sometimes add a device when a VM is created. This patch > >>> leans on libvirt to do the right thing when sev is enabled similar to what > >>> happens when launch security is specified on the virt-install command > >>> line. > >>> > >> > >> Yeah, I would still like to see libvirt do this unless there's a good > >> reason why it can't. From my July 2020 mail > >> https://listman.redhat.com/archives/virt-tools-list/2020-July/017087.html > >> > >>> if sev > >>> launchSecurity _requires_ every virtio device to have iommu='on' then > >>> libvirt should be setting that itself. It doesn't need to hardcode it > >>> into the XML, it can set it at VM startup time. If the user set an > >>> explicit value in the XML then honor that but otherwise fill it in at > >>> runtime when it is required. Trying to deal with this in an app where we > >>> want to advertise turning the config off is basically an impossible > >>> problem to know if we are going to undo any explicit user config or not. > >> > >> danpb does this sound reasonable? If so I can work on this. > > > > Something automagic sounds ok > > > >> Also, anyone know if TDX and SNP will require virtio iommu setting as well? > > > > I expect SNP will, but no idea about TDX. > > > > So apparently qemu 6.0.0+ already does this for us: > https://gitlab.com/qemu-project/qemu/-/commit/9f88a7a3df > > Which is strange because some of my sev testing definitely failed with > an iommu sounding error in the guest kernel until I enabled iommu on > virtio-blk, but I can't reproduce now. Maybe I was using an older qemu, > I think the host was fedora 34 at the time Or you had new QEMU, but the guest was fixed on the older machine type perhaps With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: Add support for enabling Secure Encrypted Virtualization in the GUI
On 4/19/22 1:21 PM, Daniel P. Berrangé wrote: > On Tue, Apr 19, 2022 at 12:05:29PM -0400, Cole Robinson wrote: >> On 4/4/22 11:49 AM, Charles Arnold wrote: >>> >>> >>> On 4/4/22 6:50 AM, Daniel P. Berrangé wrote: On Fri, Apr 01, 2022 at 12:13:17PM -0600, Charles Arnold wrote: > From d700e8cee7cd525c0022b5a9a440f64c4ab149f0 Mon Sep 17 00:00:00 2001 > From: Charles Arnold > Date: Fri, 1 Apr 2022 12:01:21 -0600 > Subject: [PATCH 1/1] Add support for enabling Secure Encrypted > Virtualization > in the GUI > > Add an "Enable Launch Security" checkbox on the Details memory tab. > Do the minimal configuration required for libvirt to enable this feature > on compatible hardware. > Don't we need to turn on the 'iommu' option for all virtio devices too, and disable PXE on any NICs ? https://libvirt.org/kbase/launch_security_sev.html#virtio >>> >>> I used to enumerate through the virtio devices in an old version of this >>> patch >>> for virt-manager and enable iommu but it really wasn't reasonable for >>> virt-manager to track which virtio devices needed iommu enabled. >>> Additionally, >>> libvirt will sometimes add a device when a VM is created. This patch >>> leans on libvirt to do the right thing when sev is enabled similar to what >>> happens when launch security is specified on the virt-install command line. >>> >> >> Yeah, I would still like to see libvirt do this unless there's a good >> reason why it can't. From my July 2020 mail >> https://listman.redhat.com/archives/virt-tools-list/2020-July/017087.html >> >>> if sev >>> launchSecurity _requires_ every virtio device to have iommu='on' then >>> libvirt should be setting that itself. It doesn't need to hardcode it >>> into the XML, it can set it at VM startup time. If the user set an >>> explicit value in the XML then honor that but otherwise fill it in at >>> runtime when it is required. Trying to deal with this in an app where we >>> want to advertise turning the config off is basically an impossible >>> problem to know if we are going to undo any explicit user config or not. >> >> danpb does this sound reasonable? If so I can work on this. > > Something automagic sounds ok > >> Also, anyone know if TDX and SNP will require virtio iommu setting as well? > > I expect SNP will, but no idea about TDX. > So apparently qemu 6.0.0+ already does this for us: https://gitlab.com/qemu-project/qemu/-/commit/9f88a7a3df Which is strange because some of my sev testing definitely failed with an iommu sounding error in the guest kernel until I enabled iommu on virtio-blk, but I can't reproduce now. Maybe I was using an older qemu, I think the host was fedora 34 at the time I'll send a patch for libvirt docs I'll give this patch another look too Thanks, Cole
