This sounds like we're hitting the systemd's limit on machine name. However, my memory tells me we saw (and fixed) this bug before...

Yes, this is the same issue as with Bug 1282846.  Unfortunately, we cannot do anything about this in libvirt, apart from using UUID instead of a machine name.  Because that would add a lot of unnecessary complexity during libvirt upgrade, I would first like to know what's going to happen with the machined limitations.

@Michal: Could you update us on the machined progress once you know whether we're going to cancel some limitations (i.e. that machine name must be also valid hostname), so that we know how to proceed on this?  Thank you in advance.

(In reply to Jiri Denemark from comment #2)
> Andrew, there is no customer sensitive data in this bug report, would you
> mind making the bug public? If you need to add any confidential data, you
> can use private comments.

I would be thrilled to make it public - DONE!  :-)

(In reply to Martin Kletzander from comment #4)
> Yes, this is the same issue as with Bug 1282846.  Unfortunately, we cannot
> do anything about this in libvirt, apart from using UUID instead of a
> machine name.  Because that would add a lot of unnecessary complexity during
> libvirt upgrade, I would first like to know what's going to happen with the
> machined limitations.

It appears that bugzilla 1282846 is for allowing the use of non-ascii characters and doesn't have any impact on length.  As far as this issue in a prior bugzilla is concerned, I know it was reported in Fedora because the customer found bugzilla 1033369.  However, bugzilla 1033369 isn't fixed based on it's last updates and status.

It is easy to surmise that this is a simple change on the surface.  However, if this change is possible due to limitations deep within libvirt or because it requires exhaustive changes that can't be justified.  My one request is that if we turn this down then please provide details about why so that I can clearly communicate this back to my customer.  :-)

I believe Jiri meant the description of the bug as well as the bug.  This way people with similar problem will still not find this bug.


Even though Bug 1282846 is reported because of non-ASCII characters in the name, the root cause is the same.  Bug 1033369 isn't even filed for Fedora, but for upstream.  Anyway, this bug will be updated with any reason for such update attached.  As all other bugs are.

Anyway, for now I'm putting back the cancelled needinfo back on Michal.

See https://bugzilla.redhat.com/show_bug.cgi?id=1285720#c2

RHEV impacted (both non-ascii and length)
requesting a fix in 7.2.z

Reproduce this bug with libvirt-1.2.17-13.el7_2.2.x86_64

steps
1.Prepare a guest xml which guest name with 60-character name-length
# cat rhel72.xml 
<domain type='kvm'>
  <name>012345678901234567890123456789012345678901234567890123456789</name>
  <memory unit='KiB'>1048576</memory>

2.Define the guest with the xml

# virsh define rhel72.xml 
Domain 012345678901234567890123456789012345678901234567890123456789 defined from rhel72.xml

# virsh list --all
 Id    Name                           State
----------------------------------------------------
 -     012345678901234567890123456789012345678901234567890123456789 shut off


3.Start the guest, will fail to start it and get the following error

# virsh start 012345678901234567890123456789012345678901234567890123456789
error: Failed to start domain 012345678901234567890123456789012345678901234567890123456789
error: Invalid machine name


4.could start the guest which guest's name length less then 60-character

This limitation comes from the same part of the code as BZ 1282846, so I'm closing it as a duplicate.  I'm doing that now because I have a final confirmation about that, the way to fix it and the fix itself as well.

*** This bug has been marked as a duplicate of bug 1282846 ***

I'm reopening this BZ as this problem is deeper than the original one with name escaping.  However, the additional fix for this has been merged upstream as v1.3.2-1-ga89f05ba8df0:

commit a89f05ba8df095875f5ec8a9065a585af63a010b
Author: Martin Kletzander <mkletzan>
Date:   Fri Feb 26 09:15:55 2016 +0100

    qemu: Shorten per-domain directory names

However, that will not be back-ported due to the invasiveness/usefulness ratio of all the patches needed for this.

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Verify with build libvirt-1.3.3-1.el7.x86_64

Preparation:
1) Set set vnc_auto_unix_socket=1 in qemu.conf
2) # virsh list --all
 Id    Name                           State
----------------------------------------------------
 -     rhel7.2-1030                   shut off
 -     windows                        shut off
3) Set guest graphic type=vnc
# virsh edit rhel7.2-1030
<graphics type='vnc'/>
# virsh edit windows
<graphics type='vnc'/>


Scenario 1: Start a guest, check guest agent and vnc display
1. 
1) # virsh start rhel7.2-1030
# virsh list
 Id    Name                           State
----------------------------------------------------
 1     rhel7.2-1030                   running

2) # ps aux|grep rhel7.2-1030
...-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-rhel7.2-1030/monitor.sock,server,nowait
...-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-rhel7.2-1030/org.qemu.guest_agent.0,server,nowait
...-vnc unix:/var/lib/libvirt/qemu/domain-1-rhel7.2-1030/vnc.sock

The per-domain directory name is in format: domain-{domain-id}-{domain-name}

2. # virsh domtime rhel7.2-1030
Time: 1460448671

3. Connect to guest by virt-viewer:
# virt-viewer rhel7.2-1030


Scenario 2: Start another guest, check guest agent and vnc display again:
1. 1) # virsh start windows
# virsh list
 Id    Name                           State
----------------------------------------------------
 1     rhel7.2-1030                   running
 2     windows                        running

2) # ps aux|grep windows
...-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-windows/monitor.sock,server,nowait
...-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-2-window/org.qemu.guest_agent.0,server,nowait
...-vnc unix:/var/lib/libvirt/qemu/domain-2-windows/vnc.sock

2. # virsh domtime windows
Time: 1460420771

3. Connect to guest by virt-viewer:
# virt-viewer windows


Scenario 3: Shutdown and start rhel7.2-1030 again, domain id and per-domain directory name will change:
1.
# virsh shutdown rhel7.2-1030
# virsh start rhel7.2-1030
# virsh list
 Id    Name                           State
----------------------------------------------------
 2     windows                        running
 3     rhel7.2-1030                   running

2. # ps aux|grep rhel7.2-1030
...-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-rhel7.2-1030/monitor.sock,server,nowait
...-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-3-rhel7.2-1030/org.qemu.guest_agent.0,server,nowait
...-vnc unix:/var/lib/libvirt/qemu/domain-3-rhel7.2-1030/vnc.sock

3. # virsh domtime rhel7.2-1030
Time: 1460449825

4. Connect to guest by virt-viewer:
# virt-viewer rhel7.2-1030


Scenario 4: Domain managedsave/restore:
1. When setting vnc_auto_unix_socket = 1, managedsave succeed, but restore failed:
# virsh managedsave rhel7.2-1030
# virsh start rhel7.2-1030
error: Failed to start domain rhel7.2-1030
error: internal error: process exited while connecting to monitor: 2016-04-12T08:35:53.536685Z qemu-kvm: -vnc unix:/var/lib/libvirt/qemu/domain-4-rhel7.2-1030/vnc.sock: Failed to start VNC server: Failed to bind socket to /var/lib/libvirt/qemu/domain-4-rhel7.2-1030/vnc.sock: No such file or directory
(See Bug 1326270 - Migration failed when setting vnc_auto_unix_socket = 1)

2. When I don't set vnc_auto_unix_socket, managedsave/restore succefully.
# virsh managedsave rhel7.2-1030
# virsh start rhel7.2-1030

Scenario 5: Test with a domain with a 248-character name-length
1.# virsh define /tmp/rhel7.2-1030.xml
Domain 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 defined from /tmp/rhel7.2-1030.xml

2.# virsh start 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

3.# virsh list
 Id    Name                           State
----------------------------------------------------
 29    1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 running

4.# ps aux|grep qemu-kvm
...-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-29-11111111111111111111/monitor.sock,server,nowait
...-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-29-11111111111111111111/org.qemu.guest_agent.0,server,nowait
...-vnc unix:/var/lib/libvirt/qemu/domain-29-11111111111111111111/vnc.sock

The per-domain directory name is shorten to domain-29-11111111111111111111

The cgroup directory name is also shorten:
# ls /sys/fs/cgroup/systemd/machine.slice/machine-qemu\\x2d3\\x2d111111111111111111111111111111111111111111111111111111111.scope/
cgroup.clone_children  cgroup.event_control  cgroup.procs  notify_on_release  tasks


5.Check guest agent:
# virsh domtime 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
Time: 1460512496

6.Connect to guest by virt-viewer:
# virt-viewer 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

7.Check qemu log, guest log is written correctly:
# cat /var/log/libvirt/qemu/1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111.log

8.Do save/restore:
# virsh managedsave 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
# virsh start 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
error: Failed to start domain 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
error: internal error: process exited while connecting to monitor: 2016-04-13T02:24:07.450142Z qemu-kvm: -vnc unix:/var/lib/libvirt/qemu/domain-29-11111111111111111111/vnc.sock: Failed to start VNC server: Failed to bind socket to /var/lib/libvirt/qemu/domain-29-11111111111111111111/vnc.sock: No such file or directory


When don't set vnc_auto_unix_socket, managedsave/restore succefully.
# virsh managedsave 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
# virsh start 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111


9.Crash guest:
1) Guest xml setting:
# virsh dumpxml 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
  <on_crash>coredump-restart</on_crash>
...
  <devices>
    <panic model='isa'/>

In guest:
# echo c >/proc/sysrq-trigger

In host:
# virsh list
 Id    Name                           State
----------------------------------------------------
 2     1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 crashed

Guest doesn't reboot, and no dump file is created.
# ll /var/lib/libvirt/qemu/dump/
total 0

Check libvirtd.log, it's because dump file name is too long:
2016-04-13 02:40:05.909+0000: 24745: debug : qemuDomainObjBeginJobInternal:1779 : Starting async job: dump (vm=0x7f8450213fe0 name=1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111, current job=none async=none)
2016-04-13 02:40:05.909+0000: 24745: debug : qemuDomainObjBeginJobInternal:1828 : Started async job: dump (vm=0x7f8450213fe0 name=1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111)
2016-04-13 02:40:05.910+0000: 24745: debug : virFileIsSharedFSType:3217 : Check if path /var/lib/libvirt/qemu/dump/1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111-2016-04-13-10:40:05 with FS magic 1481003842 is shared
2016-04-13 02:40:05.910+0000: 24745: error : qemuOpenFileAs:3090 : Failed to create file '/var/lib/libvirt/qemu/dump/1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111-2016-04-13-10:40:05': File name too long
2016-04-13 02:40:05.910+0000: 24745: debug : qemuDomainObjEndAsyncJob:1991 : Stopping async job: dump (vm=0x7f8450213fe0 name=1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111)

Scenario 6: Test with a domain with a 249-character name-length
# virsh define /tmp/longname.xml
error: Failed to define domain from /tmp/longname.xml
error: cannot create file '/etc/libvirt/qemu/11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111.xml.new': File name too long

# virsh create /tmp/longname.xml
error: Failed to create domain from /tmp/longname.xml
error: cannot create file '/var/run/libvirt/qemu/11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111.xml.new': File name too long

Please have a look at
1) comment 20: step 9: crash a guest with 248-chars name-length
dump file created failed because file name is too long

2) comment 21: start a guest with 249-chars name-length
guest start failed because file name is too long.

(In reply to JinFangge from comment #22)
I'll have a look at that.  Did this work before rhel7?

(In reply to Martin Kletzander from comment #23)
> (In reply to JinFangge from comment #22)
> I'll have a look at that.  Did this work before rhel7?

On rhel6, 
1) This one doesn't exist, because guest can't start up unfortunately
comment 20: step 9: crash a guest with 248-chars name-length
dump file created failed because file name is too long 

# virsh start 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
error: Failed to start domain 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
error: internal error Monitor path /var/lib/libvirt/qemu/1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111.monitor too big for destination


2) This one also exists on rhel6:
comment 21: start a guest with 249-chars name-length
guest start failed because file name is too long.

Fix proposed upstream:

https://www.redhat.com/archives/libvir-list/2016-April/msg01694.html

Fixed upstream with v1.3.4-rc1-3-gd294f6b0dff7:
commit d294f6b0dff7df254e9e0e8e27ce00f1dcc9271e
Author: Martin Kletzander <mkletzan>
Date:   Tue Apr 26 09:44:18 2016 +0200

    Shorten domain name for automatic coredump

(In reply to JinFangge from comment #22)
Just to make it clear:

 1) this is the one fixed with the commit mentioned in comment #26.  However, as you might see from the error messsage, if we count that, it would mean that the longest name that startable domain could have on rhel6 was around 78 characters (just guessing, I'm too lazy to do the actual math and test it).  That means there will be no regression with (1) anyway.  But we should rather fix it if someone created such domain later on.

 2) this did not work ever, so there will be no problem when migrating to newer versions because there won't be a domain like that

Retest the scenarios in comment 19 ~ 21 on build libvirt-1.3.4-1.el7.x86_64, all passed.

For the issue in comment 22,
1) crash a guest with 248-chars name-length, dump file is created successfully and guest restarts as expected.

2) Test a domain with a 249-character name-length, guest defines/creates failed. This is expected.

I'm sorry but I just found another problem:
When generating domain dump file by watchdog, the file name is still too long.

Steps:
1.Prepare a guest with 248-character name-length and watchdog device:
virsh # dumpxml 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
...
    <watchdog model='i6300esb' action='dump'>
      <alias name='watchdog0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/>
    </watchdog>
...

2.In guest:
#echo 1>/dev/watchdog

Wait 30s, check dump file
# ll /var/lib/libvirt/qemu/dump/
(no dump file is generated)

3.There is error log in libvirtd.log:
2016-05-05 15:20:37.466+0000: 3440: error : qemuOpenFileAs:3076 : Failed to create file '/var/lib/libvirt/qemu/dump/1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111-1462461637': File name too long
2016-05-05 15:20:37.466+0000: 3440: error : processWatchdogEvent:3946 : operation failed: Dump failed

Please file a new bug with problem description from comment 29. It should be fixed as well. Thanks.

*** Bug 1335542 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2577.html