So, I’m trying to install an instance of OpenSuSE 13.1 through virt-install.
Now, I’ve done this before, but every so often I have this problem: when building the repos (particularly the main repo) the VM just hangs and won’t continue.
I’ve had this happen when using both the official repos and using a mirror from Argonne National Labs. Any idea on what is causing this or how to fix it? I don’t know what other information I can provide as the VM doesn’t give me any additional info nor does the console of Dom0.
Dom0 is a rather vanilla install, so I’m very doubtful that there is a problem there, not to mention that I just finished installing CentOS 5.X without any problems.
By the way,
dom0:
uname -a:
Linux server 3.11.10-21-xen #1 SMP Mon Jul 21 15:28:46 UTC 2014 (9a9565d) x86_64 x86_64 x86_64 GNU/Linux
cat /etc/*release:
NAME=openSUSE
VERSION="13.1 (Bottle)"
VERSION_ID="13.1"
PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:13.1"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"
openSUSE 13.1 (x86_64)
VERSION = 13.1
CODENAME = Bottle
# /etc/SuSE-release is deprecated and will be removed in the future, use /etc/os-release instead
cat /proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 2
cpu MHz : 2800.432
cache size : 2048 KB
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall lm constant_tsc nopl pni cid cx16 hypervisor lahf_lm
bogomips : 5679.72
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 2
cpu MHz : 2800.432
cache size : 2048 KB
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall lm constant_tsc nopl pni cid cx16 hypervisor lahf_lm
bogomips : 5679.72
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
I’m not familiar with how you’re using the word “repo.”
When you first use the word, are you describing designating a storage location for your Guest images,
and
later I think you are more properly describing your Xen installation sources?
Ordinarily, a “repo” (repository) is a designation source for <installation>, not more general storage used for things like your Guest files. There might be a grey area exception to these definitions, if your Guest images are deployed as templates to spin up Guests on demand.
If those are also your definitions, my apologies.
And, that is why I don’t understand what you may be describing when you say you are “building repos”
With Virt Install (and vm manager) you designate one or more storage locations and then create individual Guests in a storage location, and this ordinarily can’t affect a Guest hanging once successfully started (ie it either starts or doesn’t).
The first question that arises is how you have set up your domU (since you are using Xen, is it xend/libvirtd or libvirtd/libxl?). Since xend/libvirtd is cumbersome at best and more often than not the cause of real headaches, you are best advised to run the entire thing as libvirtd/libxl.
Furthermore, what do your domU config files look like (XML format please)? Maybe they provide a hint on what’s going wrong - I had the very same problems when attempting to set up a domU with virt-install, etc. so I eventually refrained from using those (or better yet, merely to generate an XML skeleton which I could tweak to get it working properly) and configured my domUs manually.
However, that your domU refuses to install properly (is it a fully virtualized or a paravirtualized guest?) is strange, indeed. What installation scheme are you using?
When I say building repos, I’m refering to the specific step during an OpenSuSE install (regardless if it is a VM or not). This occurs during the “System Probing” screen, at the “Initialize Software Manger” step, and right after the package descriptions are downloaded.
I’ll try and clear that up in the original post. Sorry about that!
OK, I assume that point “building repos” is building the local package repository which is where all downloaded packages from configured remote repos are downloaded.
This can appear to hang when may just be taking a very long time if you’re doing a network install… something like over half a gig of packages have to be downloaded before you can even start to write the files for your OS.
As we approach the release of 13.2, the original DVD files are very old but that would be one way to avoid the appearance of the system hanging (which may or may not be happening depending on your network connection). So, the options…
Download and install using the DVD. Advantage… You will continuously be able to monitor and verify your installation progress. Also, maximizes chances your initial Guest build will be successful (won’t be affected by network issues). Disadvantage - Because the build will be using very old files, it’s highly recommended you run “zypper up” immediately to download almost the entire distro’s files all over again so your system is fully patched and brought up to current packages.
Install using a Network install of some type (can be the official Network Install or something else like from a LiveCD). Advantage - Instead of downloading and installing old files, only the most recent are dlownloaded and used, minimizing excess downloading and saving steps. Disadvantage - Network issues can cause your build/Install to fail.
So, your choice… Personally I’d almost always opt for stable and certain over speed, though…
And, in your situation your problems are likely related to virtualization although it’s useful to know.
After a few hours, I’m going to call it dead\hung.
I’m now using another mirror (one from kernel.org) and the process took less than a second. I don’t believe it is about location or bandwidth, as Argonne is close to me and I’d be willing to be that kernel.org’s servers get hit a lot more.
Is there a way to view more messages\get access to a debug console?
That configuration should help. I’m going to construct a test case on my box from it today and see what’s happening and when (I’m particularly interested in the logs produced by libvirtd and libxl - they should give any pointers as to what is going wrong here). Btw.: At what point does the installation process actually get stuck? While rebooting the very first time?
From what I take from the config, you have selected a network install. By installation scheme I was effectively referring to the installation source (ISO image, network, NFS partition, etc.)
The following line leads to some questions, though: disk= ‘file:/images/vm1/disk0.raw,xvda,w’, ]
Normally the image directory would be /var/lib/libvirt/images - does the directory you specified here exist? And what is the size of the disk image?
It appears as if the VM doesn’t have enough space to write anything to the disk image, thereby causing it to hang.
Btw: You should also have a look into the log files (found at /var/log/libvirt and /var/log/xen) for any information what might be going wrong.
Ordinarily STDOUT (what you see on the console screen) should be sufficient.
Yes, if it’s not progressing over a minute or two, I’m sure it’s hung.
As you’ve discovered, geographical proximity is no guarantee it’s the best mirror. Other factors you can and can’t see are the capacity/loading of the server and network latency. The latter you can measure by running “traceroute” to each prospective mirror or less informatively, ping. In fact, in “the old days” when there was less Internet backbone bandwidth, I’d often select a mirror calculated to be in the middle of the night on another continent over one close by. That might still be best practice for some places.