What happens if I run 2 goroutines to modify a VM and destroy the same VM using the libvirt-go package on the same instance?

php Xiaobian Yuzai The problem you mentioned involves using the libvirt-go package to destroy the virtual machine at the same time on the same instance. In this case, two goroutines may modify the virtual machine at the same time, which may lead to unpredictable results. Since goroutines cannot guarantee the order of execution when executed concurrently, it may lead to race conditions or data conflicts, which may lead to virtual machine destruction failure, data corruption, or other abnormalities. To avoid this situation, you can ensure that only one goroutine can modify the virtual machine at a time by using a mutex lock or other concurrency control mechanism. This can ensure the atomicity and consistency of operations and avoid unnecessary problems.

Question content

As we all know, libvirt is thread-safe. However, running two goroutines simultaneously that act on the same resource (such as modifying and deleting a virtual machine) leaves it in an ambiguous state. How does libvirt decide the execution order of goroutines?

This is the code I tried:

package main

import (
    "fmt"

    "github.com/libvirt/libvirt-go"
)

func main() {
    conn, err := libvirt.NewConnect("qemu:///system")
    if err != nil {
        fmt.Printf("Failed to connect to libvirt: %v\n", err)
        return
    }
    defer conn.Close()

    // Create a new VM
    domainXML := `
        <domain type='kvm'>
            <name>myvm</name>
            <memory unit='KiB'>1048576</memory>
            <vcpu placement='static'>1</vcpu>
            <os>
                <type arch='x86_64' machine='pc-i440fx-2.9'>hvm</type>
                <boot dev='hd'/>
            </os>
            <devices>
                <disk type='file' device='disk'>
                    <driver name='qemu' type='qcow2'/>
                    <source file='path/to/disk'/>
                    <target dev='vda' bus='virtio'/>
                    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
                </disk>
            </devices>
        </domain>`

    dom, err := createVM(conn, domainXML)
    if err != nil {
        fmt.Printf("Failed to create VM: %v\n", err)
        return
    }

    go modifyVMMemory(dom, 2*1024*1024) // 2 GiB

    go deleteVM(dom)

}

func createVM(conn *libvirt.Connect, domainXML string) (*libvirt.Domain, error) {
    dom, err := conn.DomainCreateXML(domainXML, 0)
    if err != nil {
        return nil, err
    }
    return dom, nil
}

func modifyVMMemory(dom *libvirt.Domain, newMemory uint64) error {
    err := dom.SetMaxMemory(newMemory)
    if err != nil {
        return err
    }
    fmt.Print("Modified VM")
    return nil
}

func deleteVM(dom *libvirt.Domain) error {
    err := dom.Destroy()
    if err != nil {
        return err
    }

    err = dom.Undefine()
    if err != nil {
        return err
    }

    fmt.Print("Deleted VM")

    return nil
}

The procedure completed successfully so the domain is destroyed and can be recreated But running it again results in the following error:

virError(Code=9, Domain=20, Message='operation failed: domain 'myvm' already exists with uuid 32c25acb-a4c5-4bfd-b2f5-f07b3d9b8eea')

Solution

Thread safety simply means that the code will not suffer from memory corruption issues when multiple threads use the same connection at the same time.

The semantic behavior you will get is still undefined.

The

libvirt QEMU/KVM driver uses an RPC layer between client applications and the libvirtd (or virtqemud) daemon. So first you have non-determinism, where the Goroutine runs first. When the libvirt-go-module API calls the C ibvirt.so library via CGo, they will be locked to the native operating system thread, which will then be used in libvirt. so synchronizes internally to decide which one sends its RPC message first on the network. In the libvirtd daemon process, there are also many threads, and RPC messages are theoretically processed by FIFO. However, libvirtd's internal API logic will still compete for locks, so when communicating with QEMU/ More uncertainty is added when interacting. Basically, your SetMaxMemory and Destroy API calls can be run in either order. If you need guaranteed ordering, you need to serialize them in your application so that Destroy is only called after ​​SetMaxMemory

is completed

Finally IIUC your Go code is not robust because the main() method spawns two goroutines but does not wait for either of them to complete. IOW, the Go process will most likely exit before either goroutine has fully run. This is probably why you get the error message about the VM already existing - the deleteVM goroutine never runs before the process exits.

The above is the detailed content of What happens if I run 2 goroutines to modify a VM and destroy the same VM using the libvirt-go package on the same instance?. For more information, please follow other related articles on the PHP Chinese website!