Hello,
I'm new in this forum. I installed Clonezilla in my company and I want to clone 12 PCs at same time.
Butn when I start the drbl service in restore mode I can't clone 2 or more PCs. I can only clone 1 PC. And after cloning the PC I must stop and restart again the drbl service to be able to clone PC again.
Could you help me how to configure the drbl service for that I can clone many PC at same time ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reading your problem I guess you are using DRBL Live: http://clonezilla.org/clonezilla-SE/
Reading the linked page it looks like DRBL Live is best used if you want to clone one PC and restore it to many. If you want to be able to clone multiple PC's at the same time you will have to install and configure DRBL on a GNU/Linux system. The page links to an installation doc: http://drbl.org/installation/
Another option might be to use bootable USB sticks with Clonezilla Live installed to boot your clients and use shared storage to store the images (you have the option to configure the clients network using DHCP or manual and point the client to a network share using NFS, Samba or SSH). We use a combination of both methods (USB sticks and DRBL server), since not all of our clients are able to boot from the DRBL server using PXE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank for your reply.
For my case, I installed and configured the DRBL service including tftp, dhcp, pxe support on Debian.
And to clone the clients, I boot them vie NIC supporting PXE. And the clone works smoothly if it's one PC but when I boot other PC at the same time, the transfert bitrate decrease continuously and after 2 or 3 minutes the clone process stuck.
So according you, I should not use DRBL for cloning more PCs or there is a wrong configuration ?
PS : Sorry for my poor English :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, you should use DRBL as you have installed and configured it. It was just from your initial description of your problem that I thought you where using DRBL Live, which works a bit different then DRBL. But I have to admit that I still don't understand what you mean by "when I start the drbl service in restore mode". I never have to put my drbl service in any mode. I can just create and restore images at the same time.
I have seen the issue you describe in your last post before, but mostely with some older HP tablets which only had a 100Mbit/s NIC. So instead of using the onboard NIC I used an USB-to-Ethernet converter. Even though the tablets only had USB 2.0 ports this seemed to work better (although not always). Those converters didn't have PXE support, though, so I booted the tablets using a Clonezilla Live USB stick. It's also possible that a newer version of Clonezilla Live solved the problem. I'm not sure anymore, since it's been a while since I had this problem and these days we don't have those tablets anymore. You could try to use some Clonezilla Live testing or alternative testing versions to boot your clients with to see if it solves your problem. They will most likely have a newer kernel, which could support your NICs better.
Does your server at least have a 1Gbit/s NIC? And you do use a 1Gbit/s switch and not a simple HUB to connect the clients to the server? Because it sounds a bit like your cloning network is getting congested when using more clients at once. What speed do the NICs of your clients have?
Last edit: Arthur Tromp 2017-09-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About the client, we have a DELL Optiplex 3040 which bultin with 1 GbE NIC. And my server is the same.
The server has only 1 NIC and I use the virtual interface for Clonezilla.
We have too GbE Switchs.
To give your more detail about my configuration, this is it :
- drblpush.conf
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# Network Interface for CORP LAN
auto eth0
iface eth0 inet static
address 10.260.10.1
netmask 255.255.255.192
gateway 10.260.10.126
# Virtual Interface for Clonezilla
auto eth0:0
iface eth0:0 inet static
address 192.168.1.1
netmask 255.255.255.0
I never used virtual interfaces with Clonezilla myself. Personally I would reconfigure eth0 with just the Clonezilla IP address (192.168.1.1) and only connect a switch for imaging to that port, just to see if the virtual networking is causing an issue. So completely isolate the server and your clients from the rest of the network. But of course I don't know if that is possible for you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Arthur,
I tried this option :
udp_sender_extra_opt_default="--max-bitrate 150m"
but it does not work.
I will try your recommandation to not use Virtual interface.
If I will do that, my drblpush.conf seems be like this :
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# Network Interface for Clonezilla
auto eth0
iface eth0 inet static
address 10.260.10.1
netmask 255.255.255.192
gateway 10.260.10.126
Could you confirm my configuration ?
Which command should I execute to apply the new configuration ?
Thank you in advance
Last edit: Laha TOMMY 2017-09-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't be concerned with the content of your drblpush.conf. That file is only used when you re-run the drblpush script again. It just seeds the drblpush script with the default answers, which will be the answers you gave when you run drblpush last time. We are not going to re-run drblpush.
Just change your /etc/network/interfaces file to the following:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# Virtual Interface for Clonezilla
auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
And restart the networking:
/etc/init.d/networking restart
You can check the new network configuration with the following command:
ifconfig
You should only see a lo (local loopback) and eth0 interface with IP address 192.168.1.1. You don't need to apply anything else, as far as I know.
Connect the network port to a single, isolated switch and use that switch to connect your clients to your Clonezilla server. Then start imaging several clients to see if performance has improved. If it hasn't, virtual networking wasn't the issue and you can change back your /etc/network/interfaces to how it was and restart the networking again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So apparently the virtual network interface wasn't the issue. I understand that you boot your clients using PXE. Have you ever tried to boot them using a bootable USB stick installed with Clonezilla Live: http://clonezilla.org/downloads.php
And try different versions (stable, alternative stable, testing, alternative testing). Clonezilla Live is updated very frequently, so will normally have a newer kernel with better hardware support then DRBL. Maybe a newer kernel works better with your client hardware. Please let me know if you have difficulty restoring an image using a USB stick.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I update the clonezilla.
Before, I clone the entier disk and I thought that is the source why the cloning process stuck.
So, I clone only the system partition and I got this message on system log :
Sep 27 14:58:39 MGCANTCLNZ01 udpcast[22495]: dropped client #0 because of timeout
Sep 27 14:58:39 MGCANTCLNZ01 udpcast[22495]: Disconnecting #0 (192.168.12.13)
Could you tell me what this means ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see those kind of messages in my system log, so it is very well possible that these disconnects are causing the slow-down. Also because udpcast is used for the multicast part of Clonezilla. Not sure how to solve it, though. There are some variables in the /etc/drbl/drbl-ocs.conf configuration file regarding udp and multicasting, so you might try to experiment with them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'm new in this forum. I installed Clonezilla in my company and I want to clone 12 PCs at same time.
Butn when I start the drbl service in restore mode I can't clone 2 or more PCs. I can only clone 1 PC. And after cloning the PC I must stop and restart again the drbl service to be able to clone PC again.
Could you help me how to configure the drbl service for that I can clone many PC at same time ?
Reading your problem I guess you are using DRBL Live: http://clonezilla.org/clonezilla-SE/
Reading the linked page it looks like DRBL Live is best used if you want to clone one PC and restore it to many. If you want to be able to clone multiple PC's at the same time you will have to install and configure DRBL on a GNU/Linux system. The page links to an installation doc: http://drbl.org/installation/
Another option might be to use bootable USB sticks with Clonezilla Live installed to boot your clients and use shared storage to store the images (you have the option to configure the clients network using DHCP or manual and point the client to a network share using NFS, Samba or SSH). We use a combination of both methods (USB sticks and DRBL server), since not all of our clients are able to boot from the DRBL server using PXE.
Thank for your reply.
For my case, I installed and configured the DRBL service including tftp, dhcp, pxe support on Debian.
And to clone the clients, I boot them vie NIC supporting PXE. And the clone works smoothly if it's one PC but when I boot other PC at the same time, the transfert bitrate decrease continuously and after 2 or 3 minutes the clone process stuck.
So according you, I should not use DRBL for cloning more PCs or there is a wrong configuration ?
PS : Sorry for my poor English :)
No, you should use DRBL as you have installed and configured it. It was just from your initial description of your problem that I thought you where using DRBL Live, which works a bit different then DRBL. But I have to admit that I still don't understand what you mean by "when I start the drbl service in restore mode". I never have to put my drbl service in any mode. I can just create and restore images at the same time.
I have seen the issue you describe in your last post before, but mostely with some older HP tablets which only had a 100Mbit/s NIC. So instead of using the onboard NIC I used an USB-to-Ethernet converter. Even though the tablets only had USB 2.0 ports this seemed to work better (although not always). Those converters didn't have PXE support, though, so I booted the tablets using a Clonezilla Live USB stick. It's also possible that a newer version of Clonezilla Live solved the problem. I'm not sure anymore, since it's been a while since I had this problem and these days we don't have those tablets anymore. You could try to use some Clonezilla Live testing or alternative testing versions to boot your clients with to see if it solves your problem. They will most likely have a newer kernel, which could support your NICs better.
Does your server at least have a 1Gbit/s NIC? And you do use a 1Gbit/s switch and not a simple HUB to connect the clients to the server? Because it sounds a bit like your cloning network is getting congested when using more clients at once. What speed do the NICs of your clients have?
Last edit: Arthur Tromp 2017-09-13
Hi Arthur,
About the client, we have a DELL Optiplex 3040 which bultin with 1 GbE NIC. And my server is the same.
The server has only 1 NIC and I use the virtual interface for Clonezilla.
We have too GbE Switchs.
To give your more detail about my configuration, this is it :
- drblpush.conf
I hope that this could give you more information describing my infrastructure.
I noticed that there is a FAQ which looks to describe this problem: http://drbl.org/faq/fine-print.php?path=./2_System/67_multicast_slow.faq#67_multicast_slow.faq and scroll all the way down the page. Maybe you can find something usefull.
I never used virtual interfaces with Clonezilla myself. Personally I would reconfigure eth0 with just the Clonezilla IP address (192.168.1.1) and only connect a switch for imaging to that port, just to see if the virtual networking is causing an issue. So completely isolate the server and your clients from the rest of the network. But of course I don't know if that is possible for you.
Hi Arthur,
I tried this option :
udp_sender_extra_opt_default="--max-bitrate 150m"
but it does not work.
I will try your recommandation to not use Virtual interface.
If I will do that, my drblpush.conf seems be like this :
And /etc/network/interfaces will be like this :
Could you confirm my configuration ?
Which command should I execute to apply the new configuration ?
Thank you in advance
Last edit: Laha TOMMY 2017-09-18
Don't be concerned with the content of your drblpush.conf. That file is only used when you re-run the drblpush script again. It just seeds the drblpush script with the default answers, which will be the answers you gave when you run drblpush last time. We are not going to re-run drblpush.
Just change your /etc/network/interfaces file to the following:
And restart the networking:
You can check the new network configuration with the following command:
You should only see a lo (local loopback) and eth0 interface with IP address 192.168.1.1. You don't need to apply anything else, as far as I know.
Connect the network port to a single, isolated switch and use that switch to connect your clients to your Clonezilla server. Then start imaging several clients to see if performance has improved. If it hasn't, virtual networking wasn't the issue and you can change back your /etc/network/interfaces to how it was and restart the networking again.
I followed you recommendation and I still got the same issue.
This is a screenshot when it was stuck :
https://ibb.co/hoCFik
But I saw that the transfert rate was very high than before. You see in this picture at 1% I got 3.5GB/min of transfert rate
Last edit: Laha TOMMY 2017-09-20
So apparently the virtual network interface wasn't the issue. I understand that you boot your clients using PXE. Have you ever tried to boot them using a bootable USB stick installed with Clonezilla Live: http://clonezilla.org/downloads.php
And try different versions (stable, alternative stable, testing, alternative testing). Clonezilla Live is updated very frequently, so will normally have a newer kernel with better hardware support then DRBL. Maybe a newer kernel works better with your client hardware. Please let me know if you have difficulty restoring an image using a USB stick.
Hi,
I update the clonezilla.
Before, I clone the entier disk and I thought that is the source why the cloning process stuck.
So, I clone only the system partition and I got this message on system log :
Could you tell me what this means ?
I don't see those kind of messages in my system log, so it is very well possible that these disconnects are causing the slow-down. Also because udpcast is used for the multicast part of Clonezilla. Not sure how to solve it, though. There are some variables in the /etc/drbl/drbl-ocs.conf configuration file regarding udp and multicasting, so you might try to experiment with them.
Now, I fixed the issue by using unicast.
So I will try to find out how to fix it by using multicast.
BTW, thank for your help Arthur
You're welcome, Tommy. Glad to hear you found a workaround.