Re: stats : active memory / disk latency

2024-05-21 Thread Michal Prívozník
On 5/12/24 05:15, Peter Quiring wrote:
> Two stats that VMWare offers that I can't seem to find in libvirt is
> "active" memory and disk latency.
> 
> Any idea how I could extract these stats?
> 
> libvirt offers memory stats such as maximum, current, unused, usable,
> etc. but these are all 100% or 0% of what the VM has available.
> Looking for an "active" value.  /proc/memstat has similar stats within

I believe you meant /proc/meminfo, right?

> a Linux VM but need to get from libvirt.

Yeah, it should be trivial to add.

> 
> Disk latency is also sometimes critical information.

I'm not sure where to get disk latency info from or whether it belongs
under memory stats APIs at all.

Michal


Re: Guests: Unable to get IP address

2024-05-21 Thread Michal Prívozník
On 5/17/24 09:56, Arun Mani J via Users wrote:
> Hey all.
> I'm exploring virt-manager, libvirt etc. I downloaded Debian 12 KDE ISO
> and when launched using virt-manager, it does not seem to connect to
> network. |nmcli|​ says it has failed to get an IP address.
> However, if I run the same ISO inside GNOME Boxes, then it is able to
> connect to network.
> I checked the XML configuration of both and found this:
> ```xml
>     
>       
>       
>        function="0x0"/>
>     

This is so called SLIRP. In this case it's QEMU who assigns IP
addresses. It's not really host visible networking, i.e. host does not
"see" packets between guest and the host. QEMU process sends packets on
the guest's behalf.

> ```
> However, the one created via virt-manager has this:
> ```xml
> 
>   
>   
>   
>    function="0x0"/>
> 
> ```

This uses a bridge created by libvirt and then libvirt spawned dnsmasq
to do DHCP. I'd check whether dnsmasq process is running and whether
there's  section in the 'default' network XML:

https://libvirt.org/formatnetwork.html#nat-based-network

Also, make sure you don't have any (aggressive) firewall rules set which
would prevent guest from talking to dnsmasq.

> What I'm not able to understand is, why does the |user|​ mode networking
> work fine but not |network|​ mode?
> My ultimate goal is to set up |routed|​ configuration, so one can
> directly SSH into the guests.

Routed mode is a bit tricky to set up as you have to manually configure
routing table.

Michal


Re: cpu vmx migration issue

2024-05-21 Thread Jiri Denemark
Hi.

On Mon, May 20, 2024 at 21:04:59 +0800, d tbsky wrote:
> Hi:
> I update our RHEL9 system to RHEL 9.4, which brings libvirt 10.0.
> I try to calculate  the cpu baseline for our two-node cluster with
> command "virsh domcapabilities" then "virsh hypervisor-cpu-baseline
> --migratable".  the result has many cpu features begin with "vmx".
> 
> the test cluster has cpu "intel E3-1280 V3" and "intel I3-9100F".
> when I try live migrate vm, it failed and told me "guest CPU doesn't
> match specification: missing features:
> vmx-apicv-register,vmx-apicv-vid,vmx-posted-intr".

Interesting, hypervisor-cpu-baseline is supposed to provide an
intersection of both CPU models. I wonder whether we have a bug
somewhere, could you share the host-model definition from virsh
domcapabilities from both hosts? The easiest way is running

$ virsh domcapabilities | xmllint --xpath '//cpu/mode[@name="host-model"]' -

> at another cluster with cpu " Intel i5-2520M" and "Intel
> i7-9750H"  the migration works fine for the calculated cpu result.
> although there are still many "vmx" cpu features in the result.
> 
> if I delete all these vmx features, then migration works fine for
> both cluster, like old days.
> 
> I wonder what's the benefit to expose these vmx features to guest
> if I don't do any nested virtualization.

Well, they were always exposed by QEMU, libvirt just added support for
them and thus they are visible in the XMLs as well.

> is it ok the drop all these vmx cpu features for a guest?
> thanks a lot for help!

Sure, unless you specifically need some of them, you can drop them. They
will be added to the XML anyway during VM startup.

Jirka


Re: Guests: Unable to get IP address

2024-05-21 Thread Michal Prívozník
Please keep the list on CC so that others can benefit from the
conversation too.

On 5/21/24 14:34, Arun Mani J wrote:
> Thanks for the reply!
> 
> I recreated the NAT network using the guide from 
> https://wiki.libvirt.org/Networking.html.
> 
> The configuration now reads as:
> 
>   default
>   33376669-6292-44c9-b26b-9d2ee69826a7
>   
> 
>   
> 
>   
>   
>   
>   
> 
>   
> 
>   
> 
> 
> There is a dhcp section but still I'm not able to get my guest working.
> 
> I have dnsmasq-base package installed in my host. However I'm not sure how to 
> see if that is running. Like I opened Systems Monitor and can't find any 
> process with that name.
> 
> So may be that's the problem?

Well, have you restarted the network? You need the 'virsh net-destroy
default && virsh net-start default' combo to restart it. After that you
should see dnsmasq process, e.g. via 'ps axf | grep dnsmasq'.

Michal


How to live migrate with copy-storage-inc and zfs snapshot replication?

2024-05-21 Thread Dan Vatca via Users
Hello everybody,

I am trying to understand how I can create a setup with two libvirt + kvm +
zfs systems, in which I can:
1. Create a domain on sys-a, with storage space on a zfs filesystem. This
filesystem stores the qcow2 image, any qcow2 disk snapshots, memory dumps
and domain XML definition.
2. Take consistent ZFS snapshots every 15 minutes, and sync them to sys-b.
The snapshots will be replicated using syncoid. These will be using scripts
to quiesce the VM.
3. Given that most of the disk is synced (at most 15 minutes ago), what are
the things I need to ensure (libvirt snapshots, memory snapshot, etc), so
that I can do a live migration while copying just the incremental changes
since the last snapshot I already transferred?

I was trying to use virsh migrate —copy-storage-inc, however I could not
find any working example that would copy just the incremental changes. I
could find the theory of the snapshot backing chain, however
—copy-storage-inc complains that it cannot replicate while there are
snapshots present. (error: Requested operation is not valid: cannot migrate
domain with 1 snapshots).

I this scenario possible?

Dan Vatca


Re: Guests: Unable to get IP address

2024-05-21 Thread Arun Mani J via Users


Sorry I thought I clicked Reply instead of Reply All.

So I restarted my laptop, ran virsh net-destroy
default && virsh net-start default. Then created a new VM out of Debian 12 KDE 
Live ISO (to avoid any trailing configurations).

Still the issue persists. nmcli in the guest says enp1s0: disconnected.

But ps axf | grep dnsmasq gives this:
4341 pts/0S+ 0:00  |   \_ grep --color=auto dnsmasq
   3995 ?S  0:00 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
   3996 ?S  0:00  \_ /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper

What am I missing :(

Thanks you

On Tuesday, May 21st, 2024 at 6:51 PM, Michal Prívozník  
wrote:

> Please keep the list on CC so that others can benefit from the
> conversation too.
> 
> On 5/21/24 14:34, Arun Mani J wrote:
> 
> > Thanks for the reply!
> > 
> > I recreated the NAT network using the guide from 
> > https://wiki.libvirt.org/Networking.html.
> > 
> > The configuration now reads as:
> > 
> > default
> > 33376669-6292-44c9-b26b-9d2ee69826a7
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > There is a dhcp section but still I'm not able to get my guest working.
> > 
> > I have dnsmasq-base package installed in my host. However I'm not sure how 
> > to see if that is running. Like I opened Systems Monitor and can't find any 
> > process with that name.
> > 
> > So may be that's the problem?
> 
> 
> Well, have you restarted the network? You need the 'virsh net-destroy
> default && virsh net-start default' combo to restart it. After that you
> should see dnsmasq process, e.g. via 'ps axf | grep dnsmasq'.
> 
> Michal


Re: How to live migrate with copy-storage-inc and zfs snapshot replication?

2024-05-21 Thread Peter Krempa
On Tue, May 21, 2024 at 09:22:44 +0300, Dan Vatca via Users wrote:
> Hello everybody,
> 
> I am trying to understand how I can create a setup with two libvirt + kvm +
> zfs systems, in which I can:
> 1. Create a domain on sys-a, with storage space on a zfs filesystem. This
> filesystem stores the qcow2 image, any qcow2 disk snapshots, memory dumps
> and domain XML definition.
> 2. Take consistent ZFS snapshots every 15 minutes, and sync them to sys-b.
> The snapshots will be replicated using syncoid. These will be using scripts
> to quiesce the VM.
> 3. Given that most of the disk is synced (at most 15 minutes ago), what are
> the things I need to ensure (libvirt snapshots, memory snapshot, etc), so
> that I can do a live migration while copying just the incremental changes
> since the last snapshot I already transferred?
> 
> I was trying to use virsh migrate —copy-storage-inc, however I could not
> find any working example that would copy just the incremental changes. I
> could find the theory of the snapshot backing chain, however

Was this theory involving creation of an external snapshot (new qcow2
overlay), then ensuring that the original image is replicated to the
other host and then using migration with incremental copy?

If yes, the theory is correct, but requires creating the snapshot,
without actual snapshot metadata (just creating the qcow2 overlay).

This is done via 'virsh snapshot-create --no-metadata'. This does
everything to do the snapshot, but doesn't actually record it in the
list of snapshots ...

Alternatively you can delete the sanpshot metadata if you have them
already around (virsh snapshot-delete --metadata).

> —copy-storage-inc complains that it cannot replicate while there are
> snapshots present. (error: Requested operation is not valid: cannot migrate
> domain with 1 snapshots).

... bypassing this check. Now this check has some history behind it, the
gist being that libvirt doesn't actually copy the metadata over, so any
snapshots are unusable on the destination.

Additionally when using  --copy-storage-all the disk image chain is
flattened, thus snapshots are not preserved.

Reallistically libvirt should reconsider this check, which is more than
10 years old, as it in certain cases it'd make sense to migrate the VM
even without preserving snapshot state. Or in cases of shared storage
replicating the snapshot metadata would certainly improve usability.