VMs not reflected in virt-manager

Bug #1569472 reported by Steven Hardy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo-quickstart
Expired
Undecided
Unassigned

Bug Description

When running the quickstart.sh on my local (centos7) box, the resulting VMs are not reflected in virt-manager, which is confusing if you're coming from instack-virt-setup (where they are).

It's even more confusing if you misread the README and accidentally do this:

  sudo ./quickstart.sh localhost

What happens is the VMs *are* visible in virt-manager, only it fails to boot the undercloud due to permissions caused by putting the undercloud image in /root due to the sudo.

When you then re-run without the sudo, the VMs remain in virt-manager, but never boot, which from a new-user perspective is going to be a source of confusion I think.

At the least I think we need an addition to the "Virtual environment setup complete" notes output when the VMs have been launched, because if I've say run the quickstart.sh as "shardy" they are completely invisible which is magical and confusing until you understand what's going on.

Revision history for this message
Steven Hardy (shardy) wrote :

So, to clarify here's what I did:

Cloned tripleo-quickstart
cd tripleo-quickstart
sudo ./quickstart.sh --install-deps
sudo ./quickstart.sh localhost

Note I forgot to remove the "sudo" in the second call (this is correct in the README but could probably use emphasis as I'm assuming others may make a similar error).

What then happens is it dowloads and caches the images in /root/oooq_cache, adds the VMs (which are visible in virt-manager) then fails with a permissions error trying to boot the VM from the image in /root

Re-running without sudo works fine, but it's then non-obvious (for an ex instack-virt-setup user) where the VMs are.

Note all steps were performed via my user "shardy" account, which is setup to allow sudo access.

Revision history for this message
Steven Hardy (shardy) wrote :

So maybe this is further confused by trying to run things as a non-stack user, my virt-host box has a "shardy" user, not a stack user, and quickstart didn't create a stack user AFAICS:

$ ssh -i $HOME/.quickstart/id_rsa_virt_host stack@localhost
Warning: Identity file /home/shardy/.quickstart/id_rsa_virt_host not accessible: No such file or directory.
stack@localhost's password:

[shardy@localhost ~]$ ls .quickstart/
bin include ssh.config.ansible
hosts instackenv.json tripleo-quickstart
id_rsa_undercloud lib undercloud.qcow2
id_rsa_undercloud.pub lib64 undercloud-resized.qcow2
id_rsa_virt_power pip-selfcheck.json
id_rsa_virt_power.pub pool
[shardy@localhost ~]$ sudo su - stack
su: user stack does not exist
[shardy@localhost ~]$ virsh list
 Id Name State
----------------------------------------------------

However:

$ sudo virsh list --all
 Id Name State
----------------------------------------------------
 - compute_0 shut off
 - control_0 shut off
 - undercloud shut off

These are the bad nodes from the wrong run of quickstart with sudo I think.

Somewhere, there is an undercloud running (I have no idea how to see it via virsh though):

[shardy@localhost ~]$ arp -a
? (192.168.1.91) at <incomplete> on eno1
gateway (192.168.1.1) at e8:37:7a:ad:32:0b [ether] on eno1
? (192.168.122.57) at <incomplete> on virbr0
? (192.168.23.33) at 00:0c:d5:c0:03:89 [ether] on brext

[shardy@localhost ~]$ ssh -F $HOME/.quickstart/ssh.config.ansible undercloud
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Warning: Permanently added 'undercloud' (ECDSA) to the list of known hosts.
Last login: Tue Apr 12 17:02:20 2016 from 192.168.23.1
[stack@undercloud ~]$ /sbin/ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.0.2.1 netmask 255.255.255.0 broadcast 192.0.2.255
        inet6 fe80::20c:d5ff:fec0:38b prefixlen 64 scopeid 0x20<link>
        ether 00:0c:d5:c0:03:8b txqueuelen 0 (Ethernet)
        RX packets 6 bytes 468 (468.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 12 bytes 816 (816.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.168.23.33 netmask 255.255.255.0 broadcast 192.168.23.255
        inet6 fe80::20c:d5ff:fec0:389 prefixlen 64 scopeid 0x20<link>
        ether 00:0c:d5:c0:03:89 txqueuelen 1000 (Ethernet)
        RX packets 610011 bytes 1135824652 (1.0 GiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 388921 bytes 36618763 (34.9 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Clearly I need to learn more about how quickstart is driving virsh, but I personally would much prefer it to just put the VMs where I can see them as a normal user.

Revision history for this message
Steven Hardy (shardy) wrote :

So, some further info as I attempt to figure this out:

- XDG_RUNTIME_DIR isn't set in bashrc (because I used localhost so we don't use the remote provision roles?)
- The VM is running as shardy, not stack, but I can't see it even after setting XDG_RUNTIME_DIR

$ sudo ps aux | grep libvirt | grep undercloud
shardy 16619 19.7 38.2 13209228 12483676 ? Sl Apr12 230:19 /usr/libexec/qemu-kvm -name undercloud -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 12288 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid b463d07d-067f-4e92-ba01-c01137770ab9 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/shardy/.config/libvirt/qemu/lib/domain-undercloud/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot menu=off,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device ahci,id=sata0,bus=pci.0,addr=0x5 -drive file=/home/shardy/.quickstart/pool/undercloud.qcow2,if=none,id=drive-sata0-0-0,format=qcow2 -device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -netdev tap,fd=21,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:0c:d5:c0:03:89,bus=pci.0,addr=0x3 -netdev tap,fd=22,id=hostnet1 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=00:0c:d5:c0:03:8b,bus=pci.0,addr=0x4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on
[shardy@localhost ~]$ virsh list
 Id Name State
----------------------------------------------------

[shardy@localhost ~]$ cat ~/.bashrc
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
 . /etc/bashrc
fi

# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=

# User specific aliases and functions
export LIBVIRT_DEFAULT_URI="qemu:///system"
[shardy@localhost ~]$ vim ~/.bashrc # Here I copied the provision/remote/tasks/main.yml XDG_RUNTIME_DIR stuff
[shardy@localhost ~]$ . ~/.bashrc
[shardy@localhost ~]$ virsh list
 Id Name State
----------------------------------------------------

[shardy@localhost ~]$ echo $XDG_RUNTIME_DIR
/run/user/1000

Revision history for this message
John Trowbridge (trown) wrote :

@shardy I can't reproduce this with current quickstart. Is this possibly fixed already?

Changed in tripleo-quickstart:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for tripleo-quickstart because there has been no activity for 60 days.]

Changed in tripleo-quickstart:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.